Vyznam dual core

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

[Warran]

Sice to s významem dual core nesouvisí, ale když se tady řeší ty paňácové, tak si přisadím.

Dobře mám dva panáky:
-pohyb panáka 1 (panák P jak ho značí Eagle) počítá thread 1 na jádru 1.
-pohyb panáka 2 (panák R jak ho značí Eagle) počítá thread 2 na jádru 2.

Oba se chtějí posunout na to samé místo. Pří sériovém výpočtu v jednom threadu se ta situace ošetří, jak už tady Eagle a Swarm popsali. Zastánci dual core chtějí danou pozici (tedy fyzické místo v herní scéně) zamknout. Můžou tedy nastat tři situace:

-při výpočtu threadu 1 se na výpočet panáka 1 dostane dřív než se ve výpočtu threadu 2 dostane na výpočet panáka 2. Panák 1 si to místo zamkne a posune se tam. Panák 2 zůstane stát.

-pří výpočtu threadu 2 se na výpočet panáka 2 dostane dřív než se ve výpočtu threadu 1 dostane na výpočet panáka 1. Panák 2 si to zamkne a posune se tam. Panák 1 zůstane stát.

-při výpočtu threadu 1 se na výpočet panáka 1 dostane ve stejném okamžiku jako se ve výpočtu threadu 2 dostane na výpočet panáka 2. Oba to místo zamknou Nebo co jiného udělají


Situace nastíněná ve třetí odrážce je celkem málo pravděpodobná, ale ošetřena být musí. Jak?
Leda snad ve více threadech spočítat místa kam by se panáci chtěli posunout a nebrat ohled na možné kolize. Potom v jednom threadu ta místa projít a zjistit, zda se někteří panáci nechtějí dostat na to samé místo. V pripade ze ano rozhodnout který z nich se tam dostane a který zůstane na místě.

[Eagle]

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

Máš pravdu, že pokud by počet fps klesnul pod určitou hranici, mohlo by to dělat značné potíže. V tom případě by to šlo vyřešit tak, že bys fyziku počítal s omezením na nějakou uraženou vzdálenost třeba víckrát pro jeden objekt v jednom průchodu. Pokud by ta vzdálenost nebyla tak veliká, nedělalo by to problém. Výpočet by se tím příliš nezesložitil, protože to, jestli spočítáš 500 metrů uražené vzdálenosti vcelku nebo po 20 metrech, je poměrně lhostejné (nejvíc času zabere interakce s okolím a té je v 500m 25* tolik co v 20m)

Počítat trajektorii mi nepřijde příliš reálné, neboť to by byl výpočet extrémně složitý a navíc by prakticky nešel paralelizovat. A trajektorii bys v dalším kroku stejně nejspíš musel zahodit. Představ si, že máš čtverec, který protneš různými přímkami (trajektorie pohybu). Jakmile by se dvě přímky protnuly, měl bys potenciální kolizi a musel to řešit (což by zjevně muselo být sériově, abys zabránil nechtěným efektům).

[Semik]

Ja kupujem vedsinou to najlacnejsie, ale tak aby som z toho mal najviac. (OC)
DualCore bude premna zaujimavy ked nebude CPU ktore po natakteni ziska podobny vykon. Teraz to vidim len ako snahu CPU fieriem presadit novy trend predajnosti kedze MHZ stagnuju. Horsia alternativa bude ked uz trh neda inu moznost a nanuti predrazene Dual-CPU.

Momentalne by mne Dualcore ponukal maximalne rychlejsi Task, ale to mozem investovat aj do pametoveho systemu a vysledok bude podobny. Ked bude Dual za cenu single idem do toho ale hned

[Petrik]

Uz tohoto tematu asi nechame, nebot jak Saman spravne poznamenal, ani jeden tomu nerozumime...me uplne staci, ze on prohlasil (a nejenom on), ze pokrocile fyzikalni enginy jdou bez vetsich problemu paralelizovat, cehoz je napr. source engine dobrym dukazem. Koukni treba na particle simulation, tam mas hromadu uvlivnujicich se (predpokladam) kulicek a narust vykonu je az do 4 jader 100% linearni

Máš pravdu, že pokud by počet fps klesnul pod určitou hranici, mohlo by to dělat značné potíže. V tom případě by to šlo vyřešit tak, že bys fyziku počítal s omezením na nějakou uraženou vzdálenost třeba víckrát pro jeden objekt v jednom průchodu. Pokud by ta vzdálenost nebyla tak veliká, nedělalo by to problém. Výpočet by se tím příliš nezesložitil, protože to, jestli spočítáš 500 metrů uražené vzdálenosti vcelku nebo po 20 metrech, je poměrně lhostejné (nejvíc času zabere interakce s okolím a té je v 500m 25* tolik co v 20m)

Počítat trajektorii mi nepřijde příliš reálné, neboť to by byl výpočet extrémně složitý a navíc by prakticky nešel paralelizovat. A trajektorii bys v dalším kroku stejně nejspíš musel zahodit. Představ si, že máš čtverec, který protneš různými přímkami (trajektorie pohybu). Jakmile by se dvě přímky protnuly, měl bys potenciální kolizi a musel to řešit (což by zjevně muselo být sériově, abys zabránil nechtěným efektům).

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

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

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

[THX]

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

zmatek v tom mas ty a teda poriadny, odbiehas casto od veci, nieco tvrdis, to ti vyvratim a ty na ten moj protiagument povies no a co, ale zase tam neplati nieco (uplne) ine...
Niekolko stranok threadu si tu rozvijal svoju "teoriu prasenia", ktora sa zakladala iba na tom, ze si nepochopil spravne jeden clanok.

Povedal som - vacsia cache je draha - ty si oponoval ze ani nie - tak som ti nahodil priklad realnych porovnatelnych procesorov, na rovnakej freq., s rovnakym poctom jadier, pricom jedny maju o dost vacsiu cache a su o dost drahsie - a ty mi na to povies ci kupujem druhe jadro alebo vacsiu cache....

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

Ja myslim, ze ty ani nemyslis. Povedal si ze DC je 2x drahsie ako SC, na to som ti nasiel priklad dvoch procesorov s rovnakymi jadrami na rovnakom vyrobnom procese, kde jeden je DC a druhy nie, kedy DC nie je 2x drahsie, konkretne:

Ad ceny:
single core 2.66ghz p4 2 570,- Kč
dual core 2.6ghz pD 2 868,- Kč
rozdiel 12%
single core 2.8ghz p4 2 237,- Kč
dual core 2.8ghz pD 2 856,- Kč
rozdiel 30%.

Nedokazem si vysvetlit, ako si z tohto pochopil ze porovnavam C2D s niecim. Mas tam jednoznacne napisane pD (t.j. pentium D) + este link na czechcomputer.

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.

bohuzial, ono to ten win. az tak celkom nezariadi - bud to ftp pojde sakra pomaly, alebo dokonca zacne cela hra sekat stylom 0,9s 100fps a 0,1s nic, este vacsia sranda je, ked mas na pozadi pustene nejake flash radio a firefox sa zrazu rozhodne ze mu spadol flash a zozerie 100% vykonu procesora

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ý".

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.

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.

Takze este raz pre nechapaveho eagla:
Na konci vypoctu nepotrebujes robit ziadnu kontrolu vstupnych dat, len sa pozries ci na poziciu kde zapisujes uz niekto je, alebo nie, to je vsetko. Prepocitat to nemusis - lebo kolizie mas osetrene tak, ze sa nic nestane, t.j. panak ostane stat. Ziadne cyklenie a pod. sa nekona.
A dalej - tiez neviem preco sa tu bavime o tom comu velmi nerozumieme, napada ma len snad to, ze eagle chce pri kazdej veci o ktorej tvrdil ze nie je mozne paralelizovat a niekomu sa to podarilo paralelizovat, detailne vysvetlit ako presne sa mu to podarilo, a ked sa nam to nepodari, tak zacne tvrdit, ze ani tomu clovekovi sa to nepodarilo paralelizovat a ze je to iba podfuk a prasarna.

To by pak tedy chovani fyziky bylo silne ovlivnebo poctem FPS, coz se realne nedeje, alespon v dobrych hrach s havokem rozhodne ne.

Bohuzial v takych skvostoch ako CS sa to deje. Niektore veci ohladom pohybu, rozptylu, strelby zbrani, vypoctu zasahov zavisia od FPS. Ale kedze dnes to uz kazdemu ide na 100fps (t.j. rovnako), tak sa to celkom da.

Počítat trajektorii mi nepřijde příliš reálné, neboť to by byl výpočet extrémně složitý a navíc by prakticky nešel paralelizovat. A trajektorii bys v dalším kroku stejně nejspíš musel zahodit. Představ si, že máš čtverec, který protneš různými přímkami (trajektorie pohybu). Jakmile by se dvě přímky protnuly, měl bys potenciální kolizi a musel to řešit (což by zjevně muselo být sériově, abys zabránil nechtěným efektům).

Ja by som povedal, ze moderne fyz. enginy ako havok, novodex atd., skutocne funguju vektorovo a skutocne pocitaju trajektorie a zrazky. Tiez by som tipol, ze ten algebraicky vypocet trajektorie by (asi) siel celkom dobre paralelizovat.
Eagle - tvrdis ze nie, ze by to neslo - tak to prosim dokaz.

-při výpočtu threadu 1 se na výpočet panáka 1 dostane ve stejném okamžiku jako se ve výpočtu threadu 2 dostane na výpočet panáka 2. Oba to místo zamknou Nebo co jiného udělají

Princip fungovania zamkov spociva v tom, ze nikdy nemozu dva thready naraz zamknut tu istu vec, t.j. takato situacia sa nemoze stat. Je to podporovane priamo v HW, procesor ma na to spec. instrukciu (typu test and set), a samozrejme funguje to aj pre viacero jadier - teda, nikdy sa ti nemoze stat ze aj na x-procesorovom systeme zamknu naraz dva procesory tu istu vec.