Vyznam dual core

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

[JonnZ]

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

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


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


</J/K>

juhuu, tusim tomu zacinam rozumiet !

moj najvacsi multitasking??
na pozadi makro v ultime online, simpsni vo WMplayer, nejake forum a par stranok v opere, trillian, nod, idlujuci winamp, total comander, teamspeak, na pozadi strong dc++, na popredi racer v okne (pripadne supaplex/mario... cez dosbox).
zatazenie? racer s max prioritou si zobere okolo 90%. vsetko ostatne spolu tych 10%. odozva systemu uplne bez problemu, vsetko sa v pohode stiha.
staci mi na to sempron 2800+

ano, ak by som chcel este k tomu komprimovat video, tak by som potreboval este jedno jadro. ale takto

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

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

[Eagle]

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

Jen se snažím vysvětlit ti některé věci, které bys měl chápat sám. Bohužel se mi to nedaří, a tak nám tu stále prezentuješ nesmysly, kterým snad i věříš.

Niekolko stranok threadu si tu rozvijal svoju "teoriu prasenia", ktora sa zakladala iba na tom, ze si nepochopil spravne jeden clanok.

Ehm... na posledních asi dvou stranách jsme to probrali a výsledkem je, že s tou paralelizací to není zdaleka tak žhavé. Ty taky budeš jenom opisovat výkřiky z netu nebo se pokusíš jednou něco do diskuze přinést?

Povedal som - vacsia cache je draha - ty si oponoval ze ani nie

Aspoň nelži, když už. Já jsem ti tak maximálně oponoval, že dvousocket není o tolik dražší než jednosocket, což je (bohužel pro tebe) pravda. Akorát ty jsi sem zanesl čtyřsocketový procesor, na který se samozřejmě vztahuje tučná prémie, protože už dnes umožňuje postavit osmijádrový počítač. Zbytečně se snažíš o účelový argument, ale nevychází ti to. Člověk, který má jakž takž přehled, totiž ví, že ekvivalentem k desktopovému CPU od Intelu je Xeon (ne-MP). Ten o tolik dražší není.

konkretne:

Opět ta tvoje ubohá snaha vnášet zavádějící argumenty. Tak teď ti to vysvětlím naposledy, jako pro úplného pitomce.
P4 2.66 GHz stojí 2570 Kč.
A64 3000+ stojí 2285 Kč.
Který z těchto procesorů má vyšší výkon? Athlon 64. Který z nich je levnější? Athlon 64. Co z toho plyne? Že Athlon 64 má vyšší výkon za nižší cenu, a tedy se nevyplatí o P4 vůbec uvažovat, protože P4 je předražené. Takže když budu porovnávat ceny, tak budu uvažovat výhodný single-core (= A64) a proti němu výhodný dual-core s podobnými parametry (= C2D).

bohuzial, ono to ten win. az tak celkom nezariadi

Tobě možná ne, ale já s tím problémy nemám a spousta diskutujících tady evidentně taky ne.

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.

S tímto přístupem budeš mít ve scéně některé objekty 2x. Příklad: První postavička je na lokaci x. V přístím snímku se přesune na lokaci y. Logicky tedy se x uvolní a y zaplní. Pokud bude další thread pracovat s původními daty, vyhodnotí x jako zaplněné, přestože se tato pozice uvolní.

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

Přesně tak.

[Darth Maul]

Fakt už to tu zamkněte - točí se to tu pořád dokola, podle Eagla jsou všichni pitomci a jenom on je letadlo a přitom o korektní, konzistentní a věcné argumentaci snad nikdy v životě ani neslyšel... motá tu páté přes deváté a jsa přistižen při činu se jen ztrapňuje, což IMHO při svých znalostech fakt nemá zapotřebí...

[Rainbow]

Takze slavnostne na koniec roka to tu zamykam.
A do buducnosti odporucam vsetkym, aby nediskutovali takymto sposobom o veciach, ktorym nerozumeju (sifrovanie, paralelne programovanie, fyzikalne algoritmy a dalsie veci).