Vyznam dual core

[THX]

Cache nijak s dvoujádrem nesouvisí. Intel klidně mohl udělat single-core se 4 MB L2. Neudělal, protože by na to nemohl nabalit dual-core BS a prodávat to za dvojnásobnou cenu. Lidi nejsou zas tak hloupí, aby nevěděli, že velká cache není něco, za co by se nechali nachytat a za co by byli ochotni zaplatit dvojnásobek.

No, neviem, viz servrove CPU. Su podstatne drahsie - ale iba koli cache. Ak by bola 2x vacsia cache, tak by sa robil marketing o tu cache. V podstate skoro ani nezavisi aky je ten novy procesor, ake ma presne feature, hlavne ze je celkovo vykonnejsi a teda ho mozno draho predavat. Marketing by skratka propagoval inu feature, ale o tom sme sa tu uz bavili...

Víš, jakých procesorů se prodá nejvíc, zejména ve státě typu ČR ? Jsou to levné Semprony a levné A64. Takových čipů se prodává hromada, C2D E6300 je teď v cenové relaci, která je pro hodně lidí příliš vysoká. Modelů jako E6600 se u nás prodá naprosté minimum. A jen pro zajímavost - CPU v ceně nad 20 tisíc se prodá v pár desítkách, maximálně stovkách kusů za rok. Ano, uznávám, že v porovnání s E6600 je AMD dražší, ale to nic nemění na faktu, že za pár MHz navíc bych si ty horentní sumy nepřiplatil ani u Intelu, a proto je pro mě tahle kategorie nezajímavá. Beztak v téhle kategorii už single-core nejsou a nač bych platil víc za DC, když ho nevyužiju? (= E660 stojí víc jak 3x tolik co A64 3500+, ale o kolik má vyšší výkon? 20 % ?).

Sice e6600 stoji 3x viac ako 3500+, ale ja ti viem ukazat fx-62, ktory ma rovnaky vykon ako 6600 a stoji este 2.5x viac...
A ano, najviac procakov sa preda lacnych, no a?
A samozrejme, tiez je jasne ze optori procesoru s najlepsim pomerom cena/vykon, budu mat vsetky ostatne tento pomer horsi. Ved aj SC s o 20% vyssim vykonom nestoji o 20 ale o 50% viac...

Víš, ony se ty ceny změní tak, že single-core ještě zlevní. Teď máš Celeron D 347 za 1500 s DPH. P4 6xx má od ledna stát 69 dolarů (2000 s DPH). C2D zlevňovat nebude, A64 X2 asi taky ne.

a potom zmenis tie tvrdenia ze p4 za danu cenu nema co nabidnout? Ved potom bude lacnejsi ako rovnako vykonny A64...
Budes prepisovat vsetky tie prispevky?

Protože tohle, co tady uvádíš, ti přidá nějakou hodnotu (např. u té limonády chuť). Já vím, že je těžké pochopit, že dual-core nepřidá vůbec nic. Tak se ti to pokusím vysvětlit ještě jinak, polopaticky:

výkon SC: x
výkon DC v ST aplikaci: x
cena SC: y
cena DC: 2y

poměr výkon/cena u SC: x/y
poměr výkon/cena u DC: x/2y

Co má vyšší poměr? Jistě že SC. A nezmění se to do doby, než výkon u DC v ST aplikacích bude 2x nebo cena DC bude y. Ale taková situace teď není.

tak za 1., vykon DC v ST aplikaci 1.1-1.3x v zavislosti co vsetko mi bezi na pozadi (winamp, TS, dc++, driver zvukovky atd.)
za 2., cena DC 1.2y, 1.3y, resp. v istych kategoriach vykonu obdobne SC nie je. Ty si nasiel jeden priklad kedy je cena 2x vyssia, ja som ti nasiel dva protipriklady kedy nie je - ale odmietas to uznat.

Tam ti pomůže i cache OS a DRAM buffer na disku. Další prostor pro zlepšení je malý.

nj, tak ked uz nic, aspon to znizi spotrebu, ale ak tam budu dobre nacacheovane veci, tak to moze dost pomoct (napr. pri bootovani a pod.).
To uz je ale trocha OT.

Pokud mi něco na default přinese jen pár desítek procent výkonu navíc a přitom to stojí majlant, tak to nepovažuju za dobrou koupi.

Poradim ti, pretaktuj...

Latence RAM se nemění, ale zvyšuje se propustnost, takže agresivní prefetch a velká cache můžou hodně zachránit. Kdyby ještě udělali hardwarový speculative-precomputation, podaří se jim tenhle bottleneck z velké části odbourat.

Myslim ze pre-computation by dost zvysila spotrebu.

Jenže ty tu srážku musíš odhalit a to se ti bude dělat pěkně blbě, když budeš hýbat dvěma objekty současně a ne po jednom.

tak mi prosim popis, v com presne spociva rozdiel pri pocitani fyziky seriovo a paralelne, v com sa meni algoritmus ratania kolizii a preco to sposobi tak velky problem, ak sa budu robit vypocty paralelne...

Co sa tyka toho textu - bud dobre nerozumies anglicky, alebo si to fakt necital.

V tom textě nic takového napsané není.

Ale je!

Je tam cosi o tom, že umožňují číst z jedné lokace více threadům, což ale předpokládá nezávislost operací.

spravne

V reálu ale ty závislosti jsou a hodně.

5% nepovazujem za hodne

Zbytek zavání šílenými deathlocky, což sami autoři potvrzují.

ano a hned dalsia veta popisuje riesenie

Jak je překonat, je snad jasné - prostě se na závislosti vykašlat a udělat to se zastaralými daty (= prasárna).

NIEEE, proste sa pouzije r/w lock, ziadne stare data, ziadne prasarny.

Tak este raz ten text:

The new pipeline featured so much multithreading that special efforts were needed to avoid the dreaded deadlocks and other pitfalls mentioned earlier. To accomplish this, programmer Leonard made use of a technique called lock-free algorithms. He implemented a spin lock to replace the more traditional mutexes (mutual-exclusion algorithms) and semaphores that are used to flag threads as being "safe" to multithread. The spin loop utilizes a new interlock instruction that is built into the CPU. However, there were still too many deadlocks. Tom examined the threads' activity with profiling tools, and it turned out that 95 percent of the time the threads were reading memory while only spending 5 percent of their time writing. A read/write lock allowed many threads to read the same bit of memory, but only one thread to write to it.

Takze sa pouziva spin lock a r/w lock. Co je na tom nepochopitelne? Normalne sa zamyka, normalne to funguje.

[Eagle]

2THX: Tvoje myšlenkové pochody mě opravdu fascinují.

No, neviem, viz servrove CPU. Su podstatne drahsie - ale iba koli cache.

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

ale ja ti viem ukazat fx-62, ktory ma rovnaky vykon ako 6600 a stoji este 2.5x viac...

Právě proto si FX-62 nekupujeme, nemyslíš?

Ved aj SC s o 20% vyssim vykonom nestoji o 20 ale o 50% viac...

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 ?

a potom zmenis tie tvrdenia ze p4 za danu cenu nema co nabidnout? Ved potom bude lacnejsi ako rovnako vykonny A64...
Budes prepisovat vsetky tie prispevky?

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í.

tak za 1., vykon DC v ST aplikaci 1.1-1.3x v zavislosti co vsetko mi bezi na pozadi (winamp, TS, dc++, driver zvukovky atd.)

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é.

za 2., cena DC 1.2y, 1.3y

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

resp. v istych kategoriach vykonu obdobne SC nie je

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ě).

Ty si nasiel jeden priklad kedy je cena 2x vyssia, ja som ti nasiel dva protipriklady kedy nie je - ale odmietas to uznat.

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

Poradim ti, pretaktuj...

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.

Myslim ze pre-computation by dost zvysila spotrebu.

To jistě... ale přineslo by to víc výkonu než ten slavný dual-core. Takže určitě bych radši bral single-core se speculative precomputation než dual-core bez něj.

tak mi prosim popis, v com presne spociva rozdiel pri pocitani fyziky seriovo a paralelne, v com sa meni algoritmus ratania kolizii a preco to sposobi tak velky problem, ak sa budu robit vypocty paralelne...

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).

5% nepovazujem za hodne

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ě.

ano a hned dalsia veta popisuje riesenie

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.

NIEEE, proste sa pouzije r/w lock, ziadne stare data, ziadne prasarny.

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

Tom examined the threads' activity with profiling tools, and it turned out that 95 percent of the time the threads were reading memory while only spending 5 percent of their time writing. A read/write lock allowed many threads to read the same bit of memory, but only one thread to write to it.

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.

[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.

[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ě.

[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í...

[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í...

[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).

[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.).

[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]

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.