Vyznam dual core

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