Vyznam dual core

[jan555]

Ty jsi řekl: "A jen tak mimochodem - on existuje nějaký desktopový SC procesor, který je v single-threadu výkonný jako C2D a je přitom 2x levnější?"

Ano, to máš skutečně pravdu - je mojí chybou, že mám tendenci od diskuze o ceně sklouzávat k technickému stavu věci, v tomhle případě typicky k výkonu per MHz a že podobné cenové rozdíly nepovažuji za zajímavé pro kohokoliv, koho zajímá výkon a nikoliv pouze pořizovací cena (kdybychom vyjadřovali value/money po typickou dobu vlastnictví procesoru, dobrali bychom se možná jiného výsledku). V tom případě mám ovšem problém s tím, že pokud je řeč o pořizovací ceně a výkonu, tak nebudeš brát ohled na OC, protože pokud chce někdo výkon, tak ho buď zaplatí, nebo nechce/nemůže a nižší model obvykle taktuje. A běžně nataktovaný E6300 (nebo E4300) prostě rozštípe cokoliv od AMD, jakkoliv nataktované s běžným chlazením a to v jakékoliv aplikaci.

S tím, že by bylo C2D předražené, je možné souhlasit pouze za specifických předpokladů, kterými např. jsou (a jejich kombinace):
- low-cost počítač (stále se stáčí řeč na low-end C2D, už o třídu výš nemá AMD šanci ani v kritériu pořizovací ceny vs. single-thread výkon)
- provoz výhradně na defaultním taktu
- nevyužití (ani v střednědobém horizontu) druhého jádra (dnes je zjevně nemálo uživatelům druhý core k ničemu, k čemu jim ale bude SC procesor a jakou bude mít cenu v okamžiku, kdy jakákoliv z common aplikací, nebo pro něj klíčových aplikací, DC podporovat bude?)
- pouze příležitostné využívání více náročnějších aplikací najednou (viz předchozí bod)

Tak a teď otevřeme oči a rozhlédneme se po 4u po tomto typickém uživateli ... Kolik bude těch, na které se vztahují už jen výše uvedené body s výjimkou prvního? Ani jeden? Ano, mám tendenci k činění jednoduchých závěrů - low-end A64 je vhodný pro ty, pro které je daleko nejdůležitějším kritériem pořizovací cena, pro ty, kteří vůbec netaktují a pro kombinaci příslušníků těchto dvou skupin. Pro drtivou většinu ostatních je dnes nikoliv obecně DC procesor, ale konkrétně C2D tou správnou volbou.

A že i lehce nataktované low-end C2D nesmaže úplně rozdíl v pořizovací hodnotě vs. výkonu v nějakém benchmarku oproti A64? Koho to bude zajímat, když bude měsíce, rok či dokonce let víc jeho počítač rychlejší a práce komfortnější? A mimochodem to, o kolik bude v takové situaci C2D rychlejší oproti A64 se může v budoucnu zřejmě jen zlepšit.

Dál v téhle diskuzi pokračovat teď nebudu, strávil jsem tím víc času, než bych kdy chtěl.

[frelichl]

Tak a teď otevřeme oči a rozhlédneme se po 4u po tomto typickém uživateli ...

Tohle bych vypíchnul, je rozdíl bavit se o běžném uživateli a běžném uživateli tady na fóru.

To se tady ostatně táhne už pěkných pár stránek, eagle se na to dívá z pohledu BFU, popř. z firemního pohledu, zatímco většina ostatních vidí svůj pohled - tj. ten, že si stejně procesor přetaktují a tím se dost významě změní cena/výkon poměr sledovaných procesorů.

[DeeKay]

Kdyz uz se teda budeme bavit z pohledu uzivatele tohodle fora, nutno pak podotknout ze jakakoliv pi*ovina za spoustu penez ma cenu, protoze slouzi k poradnemu nahoneni ega a to je to k cemu tu ma naslapany HW vetsina lidi... howgh

(ti co louskaji kody nebo delaji v Catii apod prominou)

[THX]

Už několik let nejsou podstatně dražší.

tak napr.
Xeon MP 7140M 3.4 GHz 2x 1MB+16 MB $1980 vs $200 PD 945 2x2
Xeon MP 7130M 3.2 GHz 2x 1MB+8 MB $1391 vs $190 PD 940 2x2
Xeon MP 7120M 3 GHz 2x 1MB+4 MB $1117 vs $160 za P-D 930 3ghz 2x2MB

Ta cache navyse v servrovej verzii mi pride dost draha.

Tak znovu, už asi po desáté, polopaticky - stojí víc, ale přináší nějaký výkon navíc a nějakou úsporu času. Je na tobě, zda ta úspora času stojí za dodatečné peníze. Protože mně dual-core oproti single-core prakticky žádný výkon navíc nepřinese, nemůže mi přinést ani úsporu času, proto benefity z něj jsou nulové, a tedy i cenové navýšení musí být nulové. Chápeš to už nebo to budu vysvětlovat ještě 20x ?

uznavam, a uz davno som uznal, ze ak ten procesor nevyuzijes, tak nema zmysel ho kupovat, nemusis to opakovat 20x - co ale neznamena, ze ho niekto iny dokaze dost dobre vyuzit - o to tu ide.

Máš problémy s čísly nebo v čem je problém? P4 za současnou cenu nemá co nabídnout, protože je při stejném výkonu jako A64 podstatně dražší. Ten procesor je za aktuální cenu nevýhodný. Až zlevní, tak třeba výhodný bude. Na mých příspěvcích se tím nic nemění.

az zlevni, tak soucasna cena bude v tej dobe uplne ina...
Ja sa ti tu nesnazim vyvratit, ze prave teraz (30.12) je athlon64 lacnejsi, ja len oponujem tvrdeniu "DC je 2x drahsie" tym, ze som ti nasiel dva protipriklady, kedy toto tvoje tvrdenie neplati.

WinAMP = vytížení téměř nula
P2P klient = nevím jak DC++, ale mnohem pokročilejší eMule zatěžuje zcela minimálně
zvukovka = to ti určitě ušetří hodně moc, když aplikace obvykle moc nezvučí a ve hrách je limitem grafická karta

Takže těch tvých 1.3x je leda tak utopie. Ještě bych tak byl ochoten připustit 1.1x, i když i to je velmi nadsazené.

Lenze ta hra celkom vytazi zvukovku (v 3d rezime) a ta procak, este k tomu pridaj 4 kanaly od winampu v 2d rezime a sem tam do toho nejaky ten teamspeak (=dalsi kanal). To sa ti pravdepodobne nebude v task managerovi ukazovat ako cas spotrebovany aplikaciou, ale ako kernel-time (spotrebovany prepoctami drivera v kernel rezime). Rovnako u DCcka akakolvek praca s diskom = kernel time (niektore menej inteligentne DC zapisuju okamzite kazdy jeden kusocek suboru). Este ti toho na pozadi moze kludne bezat viac (mne napr. FTP). A pridaj si k tomu, ze driver grafiky bude tiez vyuzivat to druhe jadro. No a este si zober take veci ako prerusenia, schleduler, dalsie kernelovske veci.

A to jsi sebral kde? Víš, co to je etalon?

to som zobral z pentia-d. Napisal si DC, tak DC - to je aj pentium-D. Ak si chcel, mal si napisat - u athlona64 ktory je podla mna etalonom, je cena DC procesora rovnakej frekvencie a dvojnasobnej celkovej cache 2x vacsia (co uz tiez neplati, napr. 3200+ vs x2 3800+ je uz len o 66% drahsi). Napisal si "DC je 2x drahsie". Ja som zobral ceny DC procesorov.
Odmietam sa dalej bavit o cenach, to tu potom mozeme kazdy mesiac updatnut ceny procakov a viest zase diskusiu ci teraz uz sa to oplati, alebo este nie.

Tyhle kategorie mě nezajímají, protože mají ubohý poměr price/performance. Opravdu si nebudu kupovat E6600 za 9 litrů, když má jen o necelých 30 % vyšší frekvenci než E6300, přičemž stojí o 70 % víc (o srovnání s A64 nemluvě).

a nemyslis, ze tento thread je az prilis o tebe? A mna zase praveze zaujimaju.

Protože jsou to nesmysly. Mixuješ do porovnání nevýhodné procesory.

ja by som skor povedal, ze ty si si nasiel taku kombinaciu SC a DC procesorov, ktore porovnavas, aby to vyslo co najhorsie v neprospech DC. Teda nevyhodne ako pre koho... (ano, pre tvoje porovnania kde chces ukazat ze to stoji 2x viac je to fakt nevyhodne).

Super. Takže když se mě někdo bude ptát, jestli má upgradovat svůj tři roky starý počítat, tak mu můžu s klidem říct, že bez přetaktování žádné velké zvýšení výkonu čekat nemá? To je teda vývoj! Radši bych mu poradil, aby jel s přítelkyní na dovolenou, protože když výrobci CPU neposkytují efekty navíc, tak taky nemají dostat prachy.

To teda je vyvoj. Sam vies ze sc vykon hore velmi nepojde. A tak mu povedz pravdu, ze bez OC to predsa nie je ono - a teda nech ide radsej na tu dovolenku, ak nechce taktovat...

To jistě... ale přineslo by to víc výkonu než ten slavný dual-core.

pre koho ako..., myslim ze s istotou to tvrdit nemozes

Dobrá:
1) sériově - Panák č. 1 se pohybuje, nic tam není, OK, přesunul se na novou pozici. Panák č. 2 se pohybuje, naráží na panáka č.1, vzniká kolize, je nutné jí řešit.
2) paralelně - Panák č. 1 se pohybuje, nic tam není, přesunuje se na novou pozici. Panák č. 2 se pohybuje, nic tam není (panák č. 1 ještě nedorazil), přesunuje se na novou pozici. V dalším kole se zjišťuje, že panák č. 1 se srazil s panákem č. 2, už dávno pronikli do sebe, kolize nebyla vyřešena, došlo k chybě v programu (panáci jsou v sobě, přičemž to tak být nikdy nemá, nemůžou do sebe difúzovat).

Popisal si ako by to fungovalo bez zamkov, ale 2.) panak c1 sa pohybuje, nic tam nie je - zamkne si tu poziciu kam sa ma pohnut, panak c2 ked sa tam chce pohnut zisti, ze uz tam niekto je - kolize a jej riesenie.

To už jsem tady taky probíral, zase nečteš nebo se nesnažíš pochopit. Tak tedy znovu (už poněkolikáté).

1) To, že mají panáci ve scéně pravděpodobnost srážky s jiným panákem 5 %, neznamená, že 95 panáků je v pohodě a 5 panáků je potřeba řešit.
2) Pokud nepoužiješ sekvenční průchod, vystavuješ se problémům, které jsem popsal výše. Hrál jsi někdy turn-based hru v režimu simultárních pohybů? Víš, jaké problémy tam vznikají? Tak přesně to tě čeká, když to budeš dělat paralelně.

1.) Kde tvrdim, ze to tak je? Nikde sa tam navyse nepise, ze pravdepodobnost kolizie je 5%
2.) riesenie som ti popisal vyssie....

Ta věta nepopisuje řešení závislostí, ona jen říká, že závislosti existují jen v omezeném počtu případů, což není pravda.

No tak toto je dobre . Ty proste tvrdis, ze ta veta je nepravdiva. Programatori z valve si to zmerali a vyslo im tolko a tolko a ty si sa proste rozhodol, ze skratka nie a ze to nie je pravda. No tazko sa potom s tebou diskutuje. (btw. ta veta nehovori nic o zavislostiach).

R/W lock ti nevyřeší závislosti.

Víš, co tahle věta znamená? Že thready 95 % času zpracovávají instrukce a k tomu si čtou data, přičemž jen 5 % času zapisují výsledky do sdílené paměti. To neříká nic o tom, jak jsou vyřešeny závislosti, kdy thread 1 musí zpracovávat data, které mu musí dodat thread 0. Jistě, pokud se to bude dělat paralelně se zastaralými daty, problémy se objeví jen v malém počtu případů. Ale právě kvůli tomu, že se ty problémy projeví (panáci do sebe difúzují), je to prasárna, která by se ti při single-threaded verzi nestala.

Lenze - ak su tie data zavisle - tak nemozno paralelizovat. Nikde tam nemas napisane ze to nejak osalili alebo co. Dokonca tam nikde nemas napisane nic o zavislosti dat. Iba, ze zistili ze po rozlozeni do threadov sa tieto blokuju iba v malo pripadoch - a tak je vykonnostny prinos paralelizacie velky.
A btw. panaci ti do seba a stien difuzuju aj teraz, pretoze fyzikalny model panaka je omnoho jednoduchsi ako renrerovany.
Mas este nejake argumenty na podporu svojej "teorie prasenia" ?

Pripada mi to, ze dost casto odchadzas od veci a az na cenu (ktora sa neustale meni) ti dosli takmer vsetky argumenty v neprospech DC.

[jan555]

Kdyz uz se teda budeme bavit z pohledu uzivatele tohodle fora, nutno pak podotknout ze jakakoliv pi*ovina za spoustu penez ma cenu, protoze slouzi k poradnemu nahoneni ega a to je to k cemu tu ma naslapany HW vetsina lidi... howgh

(ti co louskaji kody nebo delaji v Catii apod prominou)

True a když se budeme bavit z pohledu toho, co správně zmínil frelichl, tak BFU nezkoumá benchmarky, nebo si z nich nevytváří vlastní pohled, případně ho vůbec nezajímá, co má v počítači a korporátovi v klasickém slova smyslu (resp. jeho zaměstnanci) to může být úplně jedno, protože sám politiku společnosti neovlivní a nákupčí se řídí jinými pravidly.

Vždyť to ale bylo řečeno - uživatel specificky odborně zaměřeného diskuzního fóra by měl být schopen vytvořit si vlastní názor, pro drtivou většinu ostatních je tahle diskuze nepoužitelná, nebo dokonce zcestná ...

[Darth Maul]

Kdyz uz se teda budeme bavit z pohledu uzivatele tohodle fora, nutno pak podotknout ze jakakoliv pi*ovina za spoustu penez ma cenu, protoze slouzi k poradnemu nahoneni ega a to je to k cemu tu ma naslapany HW vetsina lidi... howgh
(ti co louskaji kody nebo delaji v Catii apod prominou)

Kdyz se budeme bavit treba o autech z pohledu cloveka z automobiloveho fora, nutno pak podotknout, ze jakakoliv pi*ovina za spoustu penez ma cenu, protoze slouzi k poradnemu nahoneni ega a to je to k cemu tam ma naslapanou karu vetsina lidi... howgh
(ti co jezdi okruhy nebo rallye apod. prominou)

Dee, proboha, vzdyt tohle je konicek jako kazdy jiny a shazovat ho jen proto, ze zrovna Tobe nic nerika, prece neni vubec objektivni. Uznej sam, ze by se Ti po Praze nechtelo jezdit v tom Eaglem zminovanem trivalci, i kdyz vzhledem k dopravnim omezenim zadne zihadlo na kolech objektivne nevyuzijes a tudiz je dle jeho rovnice nesmyslne ho kupovat...

[Petrik]

Ty si vazne, ale skutecne vazne myslis, ze valve vypusti herni engine, ktery bude v 5% kolizi produkovat chybne vysledky? Tys asi nidky v zivote nevidel nic od valve, ze? Navic si myslim, ze problem s tema zamkama je v tom textu vysvetlen celkem srozumitelne.

Ted k tem kolizim panaku:
1)pri te seriove operaci to vypada tak, ze panak cislo jedna se nekam presune...pak jdes na druheho panaka a zjistis, ze jeho pohyb koliduje s pohybem prvniho a musis uz vypocitany pohyb panaka 1 opravit a tu kolizi nejak vyresit.
2)pri paralelni operaci to je hodne podobne, az na to, ze muzes mnohem drive zjistis, ze nastala kolize. Napriklad neni problem uz behem pocitani pohybu panaka nekam hazet jeho aktualni polohu a porovnavat ji (opet paralelne) s polohou ostatnich panaku. Jakmile zjistis, ze nastava kolize, muzes ji zacit resit okamzite a nemusis zahazovat uz vypocitany pohyb prvniho panaka.

Pripada ti to uz dostatecne fundovane? Ja myslim, ze to je celkem elegantni reseni, nemyslis? Netvrdim, ze to je nejlepsi reseni, vymyslel jsem ho ted behem psani, takze verim, ze kdyz na to ma cely team spoustu casu, ze to dokaze vyresit jeste mnohem lepe...

Víš, co tahle věta znamená? Že thready 95 % času zpracovávají instrukce a k tomu si čtou data, přičemž jen 5 % času zapisují výsledky do sdílené paměti. To neříká nic o tom, jak jsou vyřešeny závislosti, kdy thread 1 musí zpracovávat data, které mu musí dodat thread 0. Jistě, pokud se to bude dělat paralelně se zastaralými daty, problémy se objeví jen v malém počtu případů. Ale právě kvůli tomu, že se ty problémy projeví (panáci do sebe difúzují), je to prasárna, která by se ti při single-threaded verzi nestala.

Eagle, ze ty ses zase nekouknul na nazev tohoto fora... samozrejmne ze nas tu zajima predevsim vykon po pretaktovani.

Dokazovat výhodnost procesoru pomocí přetaktování mi přijde lehce zvrácené. Důležité je porovnání na default, protože podle něj se odvíjí prodejní ceny. A bohužel C2D je předražené a to hodně.

[DeeKay]

Maule ted si me vrcholne rozesmal
Proc vzdy funguje to porekadlo o potrefene huse?

Samozrejme, ze to cos napsal o automobilovym foru plati bezezbytku (mozna jeste vic). Stejne jako to co sem napsal ja.
Jenze my tu zaprve nejsme na automobilovem foru. Az se na automobilovym foru bude probirat vyznam V8 na jizdu do prace taxi tam o tom muzeme pohovorit

A jelikoz se tu probira VYZNAM dualcore...

...tak to beru tak, ze jediny s cim ty argumentujes v tomhle tvym prispevku je teda to, ze je pro tebe konicek mit co nejnadupanejsi PC? OK, ja to chapu, ale pak to jen potvrzuje moje slova a to ze si o beres osobne a zes narozdil od ostatnich nepochopil na co sem tim reagoval a co tim bylo mysleno je ciste tvuj osobni problem.

A v trivalci bych klido po praze jezdil, vono muj ctyrvalec za zenitem, kterym po praze jezdim, vzhledem k tomu co vsechno v tom aute vozim ma uz dynamiku podobnou

[Eagle]

text

Sláva, konečně jsme se k něčemu dobrali. Ale teď jedna otázka na zamyšlení - kdo na tom bude lépe?
1) Ten, kdo si teď koupí drahý dual-core a bude s ním žít tři roky.
2) Ten, kdo si teď koupí levný procesor a pak ho třeba za rok vymění za v té době levný dual-core.

Kdybych teď koupil Celeron D za 1500, tak ho za půl roku můžu vyměnit za E4300 za 3000, přičemž to je stále méně než E6300 dnes za 5200. A ještě mi pak zbude ten Celeron, který budu moct prodat. A situace za rok? To už budou 45nm modely s větší cache, čili opět výhoda. Mimo to tímto postupným upgrade dostaneš novější revize procesorů s méně bugy a i lepšími možnostmi přetaktování.

Xeon MP 7140M

Víš, on Xeon MP je určený pro 4-way desky, a proto má takovou cenu. Zjisti si ceny Opteronů 2xx a klasických Xeonů. Tak odlišné od desktopu nebudou.

az zlevni, tak soucasna cena bude v tej dobe uplne ina...

Proto máme u příspěvků datum. Taky asi víme, že když tady někdo říká, že dá druhému 486ku zadarmo, že to nenapsal v roce 1990.

len oponujem tvrdeniu "DC je 2x drahsie" tym, ze som ti nasiel dva protipriklady

Omyl, ty jsi žádné dva protipříklady nenašel. Ty jsi prostě jen srovnal jeden z nejvýhodnějších dual-core (C2D) s jedním z nejméně výhodných single-core (P4) a vymyslel si účelové překroucené tvrzení.

Lenze ta hra...

To už mi nějak nápadně připomíná toho, jehož jméno se nevyslovuje, který také je schopen programovat, surfovat po webu, kompilovat, dívat se na HDTV film, psát dokument ve Wordu a hrát počítačovou hru v jeden jediný okamžik.

a nemyslis, ze tento thread je az prilis o tebe? A mna zase praveze zaujimaju.

Tak si připrav peněženku. Já půjdu radši investovat přebytečnou cash do dluhopisových fondů.

ja by som skor povedal, ze ty si si nasiel taku kombinaciu SC a DC procesorov, ktore porovnavas, aby to vyslo co najhorsie v neprospech DC. Teda nevyhodne ako pre koho... (ano, pre tvoje porovnania kde chces ukazat ze to stoji 2x viac je to fakt nevyhodne).

Takže ty když bys měl někomu koupit single-core, půjdeš do obchodu a vezmeš P4ku, i když poskytuje horší výkon než A64 a stojí o hodně víc? Vybral jsem to, co je v SC výhodné (tj. A64) a k němu vybral dual-core se stejným single-threaded výkonem.

Popisal si ako by to fungovalo bez zamkov, ale 2.) panak c1 sa pohybuje, nic tam nie je - zamkne si tu poziciu kam sa ma pohnut, panak c2 ked sa tam chce pohnut zisti, ze uz tam niekto je - kolize a jej riesenie.

To, co říkáš, je nesmysl, protože zamknout si pozici znamená, že už tam ten panák je (je veden v nějaké lokaci a pak se tam vyrenderuje). Jenže tady mluvíme o něčem jiném. Máš thread, který potřebuje spočítat posun panáka (fyziku - tj. jak daleko, zda z něčeho nespadne atp.). Tenhle thread si načte info o okolních věcech ze sdílené RAM, včetně pozic okolních panáků. Provádí výpočet a když zapisuje výslednou pozici svého panáka... ejhle, už tam nějaký jiný panák je. Chápeš? K problému dojde v důsledku toho, že při paralelním zpracování se scéna změní v době, kdy thread počítá s původními daty. V single-threaded zpracování se ti něco takového nikdy stát nemůže, protože threadu nic za běhu výpočtu změnit sdílenou RAM nemůže.

Dee, proboha, vzdyt tohle je konicek jako kazdy jiny a shazovat ho jen proto, ze zrovna Tobe nic nerika, prece neni vubec objektivni. Uznej sam, ze by se Ti po Praze nechtelo jezdit v tom Eaglem zminovanem trivalci, i kdyz vzhledem k dopravnim omezenim zadne zihadlo na kolech objektivne nevyuzijes a tudiz je dle jeho rovnice nesmyslne ho kupovat...

Pak máš říct, že sis C2D koupil pro radost, ne proto, že to bylo výhodné.

[Eagle]

Ted k tem kolizim panaku:
1)pri te seriove operaci to vypada tak, ze panak cislo jedna se nekam presune...pak jdes na druheho panaka a zjistis, ze jeho pohyb koliduje s pohybem prvniho a musis uz vypocitany pohyb panaka 1 opravit a tu kolizi nejak vyresit.
2)pri paralelni operaci to je hodne podobne, az na to, ze muzes mnohem drive zjistis, ze nastala kolize. Napriklad neni problem uz behem pocitani pohybu panaka nekam hazet jeho aktualni polohu a porovnavat ji (opet paralelne) s polohou ostatnich panaku. Jakmile zjistis, ze nastava kolize, muzes ji zacit resit okamzite a nemusis zahazovat uz vypocitany pohyb prvniho panaka.

Pripada ti to uz dostatecne fundovane? Ja myslim, ze to je celkem elegantni reseni, nemyslis?

Myslím, že to je hloupost, protože ty musíš počítat pohyby snímek od snímku, jinak totiž nebudeš mít žádnou interaktivitu s jednáním uživatele. A nemůžeš někam ukládat aktuální polohu, protože ta je jen jedna. Výpočet neudělá nic jiného, než že vezme aktuální polohu, spočítá pár výpočtů fyziky a vyplivne polohu v dalším snímku. Pokud se v průběhu výpočtu změní vstupní parametry výpočtu, máš problém.

jinak ad1) To by se samozřejmě vyřešilo tak, že panák č. 2 by se zastavil a panák č. 1 by byl na své původní pozici.

[swarm]

1)pri te seriove operaci to vypada tak, ze panak cislo jedna se nekam presune...pak jdes na druheho panaka a zjistis, ze jeho pohyb koliduje s pohybem prvniho a musis uz vypocitany pohyb panaka 1 opravit a tu kolizi nejak vyresit.

Proč bys měl řešit pozici panáka 1? Vždyť tam bylo místo, tak neni důvod tam toho panáka nenechat. Vsériové fyzice to funguje takhle; dejme tomu, ze máme dva panáky a ty jdou proti sobě až se srazí
- U prvního panáka se zjistí, jestli je před ním místo; je tam, takže se tam posune
- U druhého panáka se zjistí, jestli je před ním místo; ne, není - stojí tam první panák, takže druhý panák zůstane stát
- U prvního panáka se zjistí, jestli je před ním místo; ne, není - stojí tam druhý panák.

Co z toho plyne? Vyhrává ten, na kterého došla dřív řada při aktualizaci pozice . Btw teoreticky se to dá ošetřit těma zónama. Pokud je fyzika hodně složitá, tak si před výpočtem jednotlivých panáků udělám kolem nich nějaké pomocné neviditelné boxy (velikostí úměrné rychlosti pohybu) nebo koule (neni nic jednoduššího než počítat vzdálenost dvou bodů) a kontroluju, které boxy se s kterýma prolínaj. Vyjde mi, že třeba scénu s 5ti panáky v jednom bytě můžu rozložit na tři zóny. Můžu si tak paralelně vytvořit 3 klasické sériové výpočty.
Dejme tomu, že pak zabere výpočet teoreticky na dovu jadrech 3/5 času, na tříjádru 2/5 (a na všech vyšších už zase jen 2/5).

Taky jde určitě vymyslet lepší řešení...

[Fox!MURDER]

<J/K>
A vubec ... dete s tim uz dopr****

Ja mam dual-core, stal spoustu penez, ale mam takhle
|--------------------------------->
|--------------------------------->
dlouhy e-penisy a mam dva!


Kdezto Eagle ma e-penis jen
|-----> takhle kratky a jen jeden... HEC!


</J/K>

Ja mam proste pocit ze to POHODLI(+25%), ten VYKON (+30% v prumeru) a ten E-PENIS (+100%) mi za 120% ceny stalo. (dobre, tohle je odhad 3200+ vs. E6300). A tezko bych to dosahl necim jinym.

Nekdo si DC koupi jen kvuli pohodli, nekdo jen kvuli vykonu, nekdo jen kvuli e-penisu a nekdo diky marketingovy masazi. Ale to, proc si ho ten ci onen clovek koupi, ci nekoupi, je jeho vec. A stejne tak, jako neexistuje absolutne prumernej uzivatel, neexistuje ani absolutni pravda o tom, jestli se to vyplati, nebo nevyplati. A uz vubec nemuze bejt ta pravda subjektivniho charakteru Eaglova typu 'JA nejlip vim co VY chcete, jak pocitac pouzivate a co VY budete chtit za tisic let'.

Vsichni tu placaji pate pres devate (pocitaje nejen Eagla, ale i me, Maula, Petrika, THX a dalsi, sry kluci ale tohle uz je jen nesmyslnej posthunt). Tocime se furt dokolecka, omilame furt to samy a vubec se nikam nedobereme, protoze nikdo neustoupi ze SVY pravdy. Sakra vykasleme se uz na dohady o tom, jestli je to dobra koupe pro vsechny, nebo ne. Vratte se na zem a misto vymejsleni, jak to zaonacit, aby to vypadalo dobre pro jednu stranu, nebo pro druhou stranu, se pokuste prijit na to, k cemu by nam to mohlo bejt dobry a jak z toho vytezit co nejvic. (o to se pokud vim overclockeri vzdycky snazili)

Je fajn, ze mame tolik energie, ale vyuzijme ji nejak konstruktivneji, co Vy na to?

Grrrrrr ....

[Petrik]

Vsechno, co jsem napsal, jsem myslel v ramci jednoho framu. Aktualni polohou jsem myslel polohu, kterou prave vypocitavam a ktera jeste neni konecna = nebude se renderovat. Prave ze se v prubehu nic nemeni, jelikoz neustale sleduji, zda nenastala kolize, coz pri seriovem vypoctu jaksi nelze. Proto me pripada paralelni pocitani fyziky tak nejak spravnejsi nez seriove...asi proto, ze v realu fyzika je seriova, tedy veci se hybaji soucasne, ne seriove...neni u serioveho pocitani fyziky nahodou mnohem vice problemu s tim, ze neco se hyblo drive nez neco jineho a musi se zpetne zjistovat, zda to je vporadku a pripadne to cele pocitat znovu? Me proste prijde neprirozene nativne paralelni vec pocitat seriove...
Tedy pockat...nemyslel jsi to nahodu tak, ze nepocitas trajektorii, ale pouze vyslednou polohu? To by pak mohli vznikat hrozne chyby, jsi si toho doufam vedom...

Myslím, že to je hloupost, protože ty musíš počítat pohyby snímek od snímku, jinak totiž nebudeš mít žádnou interaktivitu s jednáním uživatele. A nemůžeš někam ukládat aktuální polohu, protože ta je jen jedna. Výpočet neudělá nic jiného, než že vezme aktuální polohu, spočítá pár výpočtů fyziky a vyplivne polohu v dalším snímku. Pokud se v průběhu výpočtu změní vstupní parametry výpočtu, máš problém.

jinak ad1) To by se samozřejmě vyřešilo tak, že panák č. 2 by se zastavil a panák č. 1 by byl na své původní pozici.

Coze? Budto jsem tvuj post vubec nepochopil, nebo jsi to napsal spatne, nebo teda fakt nevim.
Ad prvni dve vety: ano, misto tam BYLO, protoze jsi jeste nespocital pohyb druheho panaka. Po jeho spocitani zjistis, ze tam misto neni, ze doslo ke kolizi, kteoru musis nejak resit. Pri paralelnim reseni, ktere jsem navrhnul ja, zjistis kolizi ihned a muzes ji zacit ihned resit. Ale je mozne, ze se pohyb a fyzika dela ve hrach uplne jinak a ze mnou nastineny zpusob paralelniho reseni pouzit nelze...

Proč bys měl řešit pozici panáka 1? Vždyť tam bylo místo, tak neni důvod tam toho panáka nenechat. Vsériové fyzice to funguje takhle; dejme tomu, ze máme dva panáky a ty jdou proti sobě až se srazí
- U prvního panáka se zjistí, jestli je před ním místo; je tam, takže se tam posune
- U druhého panáka se zjistí, jestli je před ním místo; ne, není - stojí tam první panák, takže druhý panák zůstane stát
- U prvního panáka se zjistí, jestli je před ním místo; ne, není - stojí tam druhý panák.

Co z toho plyne? Vyhrává ten, na kterého došla dřív řada při aktualizaci pozice . Btw teoreticky se to dá ošetřit těma zónama. Pokud je fyzika hodně složitá, tak si před výpočtem jednotlivých panáků udělám kolem nich nějaké pomocné neviditelné boxy (velikostí úměrné rychlosti pohybu) nebo koule (neni nic jednoduššího než počítat vzdálenost dvou bodů) a kontroluju, které boxy se s kterýma prolínaj. Vyjde mi, že třeba scénu s 5ti panáky v jednom bytě můžu rozložit na tři zóny. Můžu si tak paralelně vytvořit 3 klasické sériové výpočty.
Dejme tomu, že pak zabere výpočet teoreticky na dovu jadrech 3/5 času, na tříjádru 2/5 (a na všech vyšších už zase jen 2/5).

Taky jde určitě vymyslet lepší řešení...

[misokgb]

Tak musim ja napisat...

Presiel som z Celeron D na D930, najprv sa mi zdalo, ze komp rychlejsie startuje ale az po tu dobu, nez som zistil, ze HDD je brutalna brzda. Inak krom toho, ze mam dva grafy v taskmanageri som v podstate ziadny rozdiel nezbadal. Tak ale vies, poviem v skole, ze mam 2x4GHz v kompe, pritom robim na tomto PC kancelarske veci. Nic len Opera, Miranda, mIRC a v podstate sa tesim z toho, ze mam dva grafy, teplejsiu Ninju v PC, vacsiu spotrebu a v reali mi to absolutne nic neprinieslo. Ale robit upgrade z Celeron D na P4... No neviem, za tuto cenu radsej rovno Pentium D, mozno sa o nejaky ten cas zide

Jo nie je to moj PC, ale bratov, pouzivam ja, brat si kupil notas. Keby si ja mam kupovat PC, tak JEDNOZNACNE single core

[Rainbow]

Asi to tu zamknem...

[Keymaster]

<J/K>
A vubec ... dete s tim uz dopr****

Ja mam dual-core, stal spoustu penez, ale mam takhle
|--------------------------------->
|--------------------------------->
dlouhy e-penisy a mam dva!


Kdezto Eagle ma e-penis jen
|-----> takhle kratky a jen jeden... HEC!


</J/K>

//OT
LOL. Slogan "Dualcore - do more" pro mě právě získal zcela novej rozměr

[swarm]

Ad prvni dve vety: ano, misto tam BYLO, protoze jsi jeste nespocital pohyb druheho panaka. Po jeho spocitani zjistis, ze tam misto neni, ze doslo ke kolizi, kteoru musis nejak resit.

No, tak pokud jde o panáky, tak co se stane ve hrách, když jdou dva proti sobě? Zastaví se, jak jinak. To se stane ale i v tom případě, co jsem napsal. Je to jako bys hrál šachy nebo jinou tahovku. První tam má místo, tak se tam hne. Druhý tam už místo nemá, tak zůstane stát na místě. Takhle to prostě zůstane a až když se řeší další cyklus fyziky, tak první panák už bude stát na místě, protože před ním už místo není a druhý panák to samé. <-- tohle je případ, kdy mezi panákama v prvním okamžiku bylo ještě trochu místa. Pokud by tam bylo míň místa než kolik je delta x toho panáka, tak už by to vyhodnotil, jako, že tam místo není už v tom prvním kroku. Pokud tam však místo je, tak neni důvod tam toho panáka nepošoupnout jenom proto, že tam možná bude chtít i panák dva. Kolize je zároveň ošetřená tím, že první panák si samozřejmě kontroluje jestli je předním něco jiného, takže se nemůže cíleně zaseknout do druhýho panáka. Stejně tak druhý panák už řeší tu fázi, kdy je první panák zpracován a pokud ten se k němu pošoupnul, tak už prostě před sebou žádný místo nemá a tak se nehne. Takže vlastně k žádnýmu zaseknutí do sebe nedojde. Akorát se na sebe nalepěj jak dva buzíci. Nic víc. Takhle jak jsem to popsal se to doopravdy řeší ve hrách a takhle to i funguje. Vim to, protože jsme to takhle už i implementovali. Jestli to potěší, tak ti ten zdroják klidně i pošlu (pure C a OpenGL).

[Eagle]

Vsechno, co jsem napsal, jsem myslel v ramci jednoho framu. Aktualni polohou jsem myslel polohu, kterou prave vypocitavam a ktera jeste neni konecna = nebude se renderovat. Prave ze se v prubehu nic nemeni, jelikoz neustale sleduji, zda nenastala kolize, coz pri seriovem vypoctu jaksi nelze. Proto me pripada paralelni pocitani fyziky tak nejak spravnejsi nez seriove...asi proto, ze v realu fyzika je seriova, tedy veci se hybaji soucasne, ne seriove...neni u serioveho pocitani fyziky nahodou mnohem vice problemu s tim, ze neco se hyblo drive nez neco jineho a musi se zpetne zjistovat, zda to je vporadku a pripadne to cele pocitat znovu? Me proste prijde neprirozene nativne paralelni vec pocitat seriove...
Tedy pockat...nemyslel jsi to nahodu tak, ze nepocitas trajektorii, ale pouze vyslednou polohu? To by pak mohli vznikat hrozne chyby, jsi si toho doufam vedom...

Samozřejmě že počítáč jen výslednou polohu, protože trajektorie je přece blbost. Situace se nezobrazuje v nějakém spojitém rytmu, ale po snímcích. Že je to plynulé, splyne člověku v hlavě. V reálu je to ale snímek po snímku, stejně jako třeba fotky. Ty potřebuješ vědět, jaká bude poloha panáka v následujícím snímku, ne jaká bude za deset snímků dopředu (to tě nezajímá, protože do té doby do něj může hráč střelit kulometem, a tak změnit jeho rychlost pohybu atp.).

A příklad, jak to swarm (i já) myslíme:
P - panák č. 1, posunuje se vpravo
R - panák č. 2, posunuje se vlevo
x - možné lokace umístění

Výchozí situace:
P x x x R

1. krok:
x P x R x
- P i R se posunuli, nic jim v tom nebránilo

2. krok:
fáze P:
x P x R x -> x x P R x
- P se posunul, nic před ním nestálo

fáze R:
x x P R x -> x x P R x
- R zjistil, že už před ním něco je (Pčko), tak se zastavil

3. krok
x x P R x
- P i R zjistili, že před nimi něco je, takže se nehýbou

Čili kolize je ošetřena tím, že vše probíhá sekvenčně.

------------
Kdybys to dělal paralelně, tak v 2. kroku budeš mít následující problém:

fáze P, thread P:
x P x R x -> x x P R x
- P se posunul, nic před ním nestálo

fáze R, thread R:
x P x R x -> x P R x x
- R se posunul, nic před ním nestálo (tučně jsem znázornil zastaralá data)

Jenže tady vidíš, že to není v souladu, protože každý thread vidí svého konkurenta na jiném místě! P se tam posunul, protože tam (z jeho pohledu) nic nebylo. Ale R se tam posunul také, protože tam také (z jeho pohledu) nic nebylo. Jenže v reálu (objektivně) tam už byl druhý panák. Takže ve výsledku situace po sloučení výstupů threadů vypadá takhle:
x x PR x x

... takže máš problém.


Multithreadově by to šlo (částečně) udělat tak, jak navrhuje swarm, tj. namísto plnohodnotného počítání fyziky v prvním kroku použít nějakou velmi hrubou (= velmi rychlou) aproximaci pohybu a v globání paměti označit problémová místa, u nichž hrozí, že se tam panák přesune (pokud se ona aproximace trefí). Ale to je zase o odhadování a může to mít hodně blbé následky - pokud se aproximace netrefí, tak se ti prostě může stát, že buďto:
1) se dva panáci pohnou na stejné místo
2) jednomu panákovi bude odepřen vstup na nějaké místo, kam aproximace předpovídala pohyb jiného panáka, přestože po spočtení detailní fyziky se tam nepohnul

Čili sekvenční zpracování, které ti zaručuje, že se vše bude hýbat správně, se změní na sice rychlejší paralelní, ale také s potenciálem produkce chybných výsledků.

[swarm]

Multithreadově by to šlo (částečně) udělat tak, jak navrhuje swarm, tj. namísto plnohodnotného počítání fyziky v prvním kroku použít nějakou velmi hrubou (= velmi rychlou) aproximaci pohybu a v globání paměti označit problémová místa, u nichž hrozí, že se tam panák přesune (pokud se ona aproximace trefí). Ale to je zase o odhadování a může to mít hodně blbé následky - pokud se aproximace netrefí, tak se ti prostě může stát, že buďto:
1) se dva panáci pohnou na stejné místo
2) jednomu panákovi bude odepřen vstup na nějaké místo, kam aproximace předpovídala pohyb jiného panáka, přestože po spočtení detailní fyziky se tam nepohnul

Já bych předpokládal, že pokud v předvýpočtu vyjde, že by se dva objekty teoreticky mohli potkat/ovlivnit, tak ne, že by jim to odepřelo možnost se pohnout někam, ale seřadilo by to všechny elementy, co by se mohli ovlivnit, do jednoho threadu a spočítalo by je to klasicky sekvenčně (tak jak jsme si ujasnili už předtim). To nám ale nezakazuje pokud nám výpočet zjistí, že někde je blízko sebe jiná skupinka panáků (někde dál od té první), že se nemůže prdnout do dalšího threadu a uvnitř něj opět zpočítat sériově (ale zase jenom pro ty dané elementy/panáky). Pokud je těch panáků v aktivní scéně víc, tak se dá dojít ke zrychlení...pokud se všichni nenamačknou k sobě, kde se vlastně všechno hodí do jednoho threadu. Podle umístění panáků tak bude záviset to, jak moc to přinese výkonu navíc.

Samozřejmě základem je ten předvýpočet nastavit tak paranoidně, abychom vyloučili, že se nám potkají (to už by se zase dalo vymyslet různými způsoby).

[THX]

Kdybych teď koupil Celeron D za 1500, tak ho za půl roku můžu vyměnit za E4300 za 3000, přičemž to je stále méně než E6300 dnes za 5200. A ještě mi pak zbude ten Celeron, který budu moct prodat. A situace za rok? To už budou 45nm modely s větší cache, čili opět výhoda. Mimo to tímto postupným upgrade dostaneš novější revize procesorů s méně bugy a i lepšími možnostmi přetaktování.

neviem si predstavit ako taky bezny uzivatel co si kupi pc v tescu upgraduje procesor a potom este predava ten stary (...a ze vobec tusi ze daco take sa da)

Víš, on Xeon MP je určený pro 4-way desky, a proto má takovou cenu. Zjisti si ceny Opteronů 2xx a klasických Xeonů. Tak odlišné od desktopu nebudou.

ale ani nebudu mat vacsiu cache

Omyl, ty jsi žádné dva protipříklady nenašel. Ty jsi prostě jen srovnal jeden z nejvýhodnějších dual-core (C2D) s jedním z nejméně výhodných single-core (P4) a vymyslel si účelové překroucené tvrzení.

Blbost, porovnaval som p4 a p-D. C2d nemam s akym sc porovnat.

To už mi nějak nápadně připomíná toho, jehož jméno se nevyslovuje, který také je schopen programovat, surfovat po webu, kompilovat, dívat se na HDTV film, psát dokument ve Wordu a hrát počítačovou hru v jeden jediný okamžik.

no mozno by si neveril, ale u mna to dost casto tak vyzera, neviem co sa ti zda nerealne na tom hrat hru, mat pri tom pusteny winamp a TS a na pozadi este nejaky bordel....

Takže ty když bys měl někomu koupit single-core, půjdeš do obchodu a vezmeš P4ku, i když poskytuje horší výkon než A64 a stojí o hodně víc? Vybral jsem to, co je v SC výhodné (tj. A64) a k němu vybral dual-core se stejným single-threaded výkonem.

Ak mi niekto povie - chcem pentium, lebo ma hyper super threading tak mu kupim pentium. Ked mi niekto povie ze ten zly intel nechce ani vidiet, tak mu kupim amd. Rozdiel v cene pocitaca skoro ziaden... a mne je to tiez jedno, ja by som si momentalne do noveho pc iny procak ako e6300 nekupil. Procesor s takym dobrym OC potencialom (a pridanou hodnotou) tu dlho nebol (ak vobec niekedy bol) a mozno sa uz ani tak skoro nevyskytne.

To, co říkáš, je nesmysl, protože zamknout si pozici znamená, že už tam ten
panák je (je veden v nějaké lokaci a pak se tam vyrenderuje). Jenže tady mluvíme o něčem jiném. Máš thread, který potřebuje spočítat posun panáka (fyziku - tj. jak daleko, zda z něčeho nespadne atp.). Tenhle thread si načte info o okolních věcech ze sdílené RAM, včetně pozic okolních panáků. Provádí výpočet a když zapisuje výslednou pozici svého panáka... ejhle, už tam nějaký jiný panák je. Chápeš? K problému dojde v důsledku toho, že při paralelním zpracování se scéna změní v době, kdy thread počítá s původními daty. V single-threaded zpracování se ti něco takového nikdy stát nemůže, protože threadu nic za běhu výpočtu změnit sdílenou RAM nemůže.

ejhle tam uz nejaky cizi panak je - tak riesim kolizi... Nic sa nemeni, akurat ze panacikovia netahaju jeden po druhom, ale jak to pride. Panak2 proste ostane tam kde bol.

Podla mna by sa kolize nemala riesit tak, ze ak sa zisti ze nieco stoji v ceste, tak zastanem, ale pekne slusne spocitat kde by sa ti panacci presne zrazili a podla toho im dat realnu poziciu, pripadne ich odrazit atd. Moderne fyz. enginy to uz zvladaju - a su aj (prekvapivo) narocnejsie na procesor ako tie jednoduche seriove...

Asi to tu zamknem...

nie nie, prosim este aspon do 40.tej stranky nie
Myslim ze teraz sa to zacalo konecne vyvijat tym spravnym smerom a nabralo to pomerne rychly spad, takze ani dlho nebudes cakat...

[Eagle]

Já bych předpokládal, že pokud v předvýpočtu vyjde...

Tak by to šlo samozřejmě vyřešit taky, ale pak je tu ten problém, že když bude skupinka panáků u sebe, bude se to na DC hýbat stejně rychle jako na SC. Opět mi z toho vyplývá, že prioritní je co nejvyšší frekvence CPU, protože jedině ta může zabránit propadu výkonu.

[THX]

Kdybys to dělal paralelně, tak v 2. kroku budeš mít následující problém:

fáze P, thread P:
x P x R x -> x x P R x
- P se posunul, nic před ním nestálo

fáze R, thread R:
x P x R x -> x P R x x
- R se posunul, nic před ním nestálo (tučně jsem znázornil zastaralá data)

Jenže tady vidíš, že to není v souladu, protože každý thread vidí svého konkurenta na jiném místě! P se tam posunul, protože tam (z jeho pohledu) nic nebylo. Ale R se tam posunul také, protože tam také (z jeho pohledu) nic nebylo. Jenže v reálu (objektivně) tam už byl druhý panák. Takže ve výsledku situace po sloučení výstupů threadů vypadá takhle:
x x PR x x

... takže máš problém.

No a to sa da jednoducho osetrit pomocou zamkov: R si spocita ze sa ide presunut, spocita kam - potom si to miesto zamkne (ak sa da, t.j. ak ho nema momentalne zamknuty iny thread - potom vie ze sa tam pohne ten iny panak a R ostava stat) ak sa mu podari zamok, a ak je volno, tak sa tam posunie a odomkne. Ktokolvek iny tam bude chciet prist, tak sa to miesto pokusi zamknut, tak tam nic nie je, tak tam pojde, ak tam nieco je, tak ostava tam kde bol. V podstate sa tym stane to, ze ten vypocet buducej pozicie panaka2 bol zbytocny, lebo panak2 ostava stat...

Jediny rozdiel oproti seriovemu spracovaniu je ten, ze panaci netahaju jeden po druhom, ale proste jak to pride (race conditions). Tot vse, ziaden problem.

[šaman]

Asi to tu zamknem...

To by bylo myslim rozumné. Zvrhlo se to tu na debatu o ničem.
btw: s tou "fyzikou" se panove poustite do vod, kde je tahle diskuze skutecne pod uroven. Jediny swarm ma imho nejake zkusenost, bohuzel z meho zdani pouze s uzivanim nejakeho hotoveho enginu (nebo se pletu?), tj. bez hlubsi znalosti pozadi (nadefinovat world a krokovat ho, pripadne "upravovat" vyniknuvsi nesrovnalosti v problematickych vazbach apod. se skutecne neda povazovat za proniknuti do problematiky).

[Eagle]

neviem si predstavit ako taky bezny uzivatel co si kupi pc v tescu upgraduje procesor a potom este predava ten stary (...a ze vobec tusi ze daco take sa da)

Uživatel, který jde pro počítač do Tesca, se většinou zajímá o co nejnižší cenu. A to bys nevěřil, jak by těm počítačům v hyprech prospělo mít levnější CPU s méně GHz a naopak více RAMky a lepší disk.

ale ani nebudu mat vacsiu cache

Tak kupuješ si druhé jádro nebo větší cache? Máš v tom docela zmatek

Blbost, porovnaval som p4 a p-D. C2d nemam s akym sc porovnat.

Ty jakožto zákazník porovnáváš produkty podle stejné architektury? Já teda myslel, že se porovnává podle výkonu. To taky porovnáváš auta podle ročníku výroby nebo podle toho, jak jsou prostorná, jaký mají kufr, motor atp. ?

no mozno by si neveril, ale u mna to dost casto tak vyzera, neviem co sa ti zda nerealne na tom hrat hru, mat pri tom pusteny winamp a TS a na pozadi este nejaky bordel....

Mně takové věci běží v pohodě i na single-core. Jestli je něco limitující, tak nedostatek RAM a výkon grafiky. Ony totiž ty věci na pozadí můžou počkat, stačí jim přidělit nízkou prioritu a OS už zařídí, že pro CPU kritická scéna ve hře bude mít celý výkon CPU, zatímco ve scéně, kde je limitem grafika, se využije volný výkon CPU právě na ty věci na pozadí. Dokonce když máš aktivní okno s hrou, tak OS zařídí sám, že bude mít vyšší prioritu.

ejhle tam uz nejaky cizi panak je

Jsi asi jediný, kdo to nepochopil. Thread při výpočtu neví, že tam nějaký panák je. To by musel na konci výpočtu provádět kontrolu vstupních dat s aktuálním stavem. A když by zjistil rozdíl, tak by to celé musel přepočítat. Čili v situaci, kdy by bylo hodně panáků u sebe, by se thready dostaly do několikanásobné smyčky, protože bys musel jeden výpočet udělat třeba 10x. To mi moc efektivní nepřijde a výkon by byl opravdu "skvělý".

No a to sa da jednoducho osetrit pomocou zamkov: R si spocita ze sa ide presunut, spocita kam - potom si to miesto zamkne (ak sa da, t.j.

Tak to přece nejde, protože klíčová je délka výpočtu pohybu R. Samotný zápis pozice je tak na 10 instrukcí maximálně. S tvojí logikou bys nechal CPU spočítat náročný výpočet pohybu R, pak zjistil, že už tam něco je, tak bys to zas přepočítal s novou scénou a pak teprve Rkem pohnul. Jenže když tohle budeš dělat paralelně, tak se ti ta scéna bude měnit až do okamžiku, kdy bude na tahu poslední thread. Výkon by šel totálně do háje.

[Petrik]

1)nevim, proc by se zrovna meli zastavit, klidne se muzou srazit, porazit, odrazit...ale to je detail.
2)Takze podle tebe, jestli to chapu spravne, bude tvuj algoritmus davat odlisne vysledky, podle toho, jakeho panaka zacnes resit drive a jakeho pozdeji, prestoze se oba pohybuji zaroven, tedy jakoby paralelne (mysleno casove)? Mozna to je jen nedorozumeni, protoze jsi dal priklad se sachama, coz je tahova zalezitost (nepohybuji se soucasne), ale tohle mi pripada jako klasicka chyba, ktera vznika tim, ze se nativne paralelni problem (pohyb dvou nezavislych panaku) resi seriove. Spravne by to prece melo byt tak, ze jesltize se oba panaci pohybuji soucasne proti sobe (tak jsem to pochopil a myslel od zacatku), tak by zadny nemel dostat prednost (jako prvni panak v tvojim reseni), ale oba by na tom meli byt stejne, ne? To znamena zadny by nemel mit vyhodu, ze popojde na volne misto pred nim a druhy ostrouha... Pri paralelnim pocitani v tom neni zadny problem (nebo ho nevidim), u serioveho se to musi nejak dodatecne resit a opravovat... proste skutecne mi nepripada stastne resit paralelni zalezitosti seriove...

No, tak pokud jde o panáky, tak co se stane ve hrách, když jdou dva proti sobě? Zastaví se, jak jinak. To se stane ale i v tom případě, co jsem napsal. Je to jako bys hrál šachy nebo jinou tahovku. První tam má místo, tak se tam hne. Druhý tam už místo nemá, tak zůstane stát na místě. Takhle to prostě zůstane a až když se řeší další cyklus fyziky, tak první panák už bude stát na místě, protože před ním už místo není a druhý panák to samé. <-- tohle je případ, kdy mezi panákama v prvním okamžiku bylo ještě trochu místa. Pokud by tam bylo míň místa než kolik je delta x toho panáka, tak už by to vyhodnotil, jako, že tam místo není už v tom prvním kroku. Pokud tam však místo je, tak neni důvod tam toho panáka nepošoupnout jenom proto, že tam možná bude chtít i panák dva. Kolize je zároveň ošetřená tím, že první panák si samozřejmě kontroluje jestli je předním něco jiného, takže se nemůže cíleně zaseknout do druhýho panáka. Stejně tak druhý panák už řeší tu fázi, kdy je první panák zpracován a pokud ten se k němu pošoupnul, tak už prostě před sebou žádný místo nemá a tak se nehne. Takže vlastně k žádnýmu zaseknutí do sebe nedojde. Akorát se na sebe nalepěj jak dva buzíci. Nic víc. Takhle jak jsem to popsal se to doopravdy řeší ve hrách a takhle to i funguje. Vim to, protože jsme to takhle už i implementovali. Jestli to potěší, tak ti ten zdroják klidně i pošlu (pure C a OpenGL).

Mozna ze se to tak skutecne dela, nevim, ale to se pak muze lehce stat, ze objekty, ktere by se za vysokeho poctu FPS srazili, se pri malem FPS jednoduse minou, protoze ta jejich kolizni poloha se netrefi do zadneho framu...jestli mi rozumis. To by pak tedy chovani fyziky bylo silne ovlivnebo poctem FPS, coz se realne nedeje, alespon v dobrych hrach s havokem rozhodne ne. Takze podle me se pletes a trajektorie se proste pocitat musi. Jinak bys nemohl spolehlive detekovat kolizi, nebo me alespon zadny rozumny zpusob bez trajektorie nenapada. A jakmile se pocita trajektorie, neni problem s paralelnim pocitanim fyziky...

Samozřejmě že počítáč jen výslednou polohu, protože trajektorie je přece blbost. Situace se nezobrazuje v nějakém spojitém rytmu, ale po snímcích. Že je to plynulé, splyne člověku v hlavě. V reálu je to ale snímek po snímku, stejně jako třeba fotky. Ty potřebuješ vědět, jaká bude poloha panáka v následujícím snímku, ne jaká bude za deset snímků dopředu (to tě nezajímá, protože do té doby do něj může hráč střelit kulometem, a tak změnit jeho rychlost pohybu atp.).