Vyznam dual core

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

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

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