Vyznam dual core

[richie08]

No, jak myslíš. Já vážně nějak nemám potřebu se s někym přít na foru o HW. Prostě jestli myslíš, že se jedná o lidi bez potřebného know-how, kteří pořádně neumí, co dělají, tak je to čistě tvá věc.
EDIT: Tahle část tématu je z mé strany už uzavřená, vyjádřil jsem se k tomu, jak se to často dělá, nic víc - dál už mi to ani nestojí za námahu. Richie08 se může pochlubit, ve kterých hrách dělal fyziku, když je tolik erudovaný a říká jak to jiní dělají špatně.

EDIT2: Jinak teda teď jsem se zeptal jednoho malého týmu, jak je to u nich s threadama a v podstatě zatim u nich ani nebyl důvod to použít, když u nich stačí i nějaký P4 1.6GHz procesor celkem v klidu. Jejich příští engine pravděpodobně později bude mít podporu více threadů, ale předělávat ten současný by samozřejmě nešlo. Ohledně fyziky se vyjádřil docela svérázně . Tady máte kousek rozhovoru (jenom ten kus z historie, kdy jsem neseděl u jiného počítače v době, co jsem objedval a pokračování o úskalích vydání jsem taky vyhodil, protože by tu nikoho nezajímalo):

....jinak teda ještě z věcí okolo. MT hra samozřejmě neznamená, že se více jader využije naplno, protože se taky může (nezřídka) stát, že právě ty okolní thready nebudou tak náročné jako jeden z nich, a tak ten bude zase bržděn výkonem na jedno jádro a ty ostatní jádra nebudou naplno využité přitom. Taky teda hry až na pár výjimek nějak nebudou extra lpět na dualcore v následujících aspoň dvou-třech letech určitě.

Můj názor jinak je: kupujte Dual-Core jak jen to jde. Za těch několik let, kdy najdou konečně víc využití, budou pro mě levnější. No a třeba se stane, že až konečně najdou využití, tak ty vaše dual-core nakoupené teď už budou výkonem pozadu tak, že si koupíte zase novou generaci.

EDIT3:
richie0: Já jsem to nějak nenapsal jasně, ale obecně platí téměř výhradně, že nějaký fake fyziky pro konkrétní případ použití (čim užší využitím tím víc) je výpočetně rychlejší než jakákoli obecná fyzika. Délku vývoje bych nějak úplně možná ani neřešil, to je zas úplně jiný faktor, ale o ten rozdíl rychlosti může už být kritický.

Ten Tvuj clovek z icq uplne potvrdil to co rikam. O laplaceovkach pravdepodobne nema ani paru a "kodi" si neco cemu si rika fyzika. Opravdu zarny priklad. Myslim, ze jsi se ptal dobre, ale nespravne osoby Tim ho nechci shazovat, treba umi jine veci, ale fyzika a vicevlaknove programovani to nebude. Simulace v automobilovem prumyslu me zivi takze o tomhle neco malo vim. Kdyby treba vedel ze mat. modely ze Simulinku jdou vyexportovat do C bez toho aniz bych musel neco vedet o solveru... Jenze spoustu lidi proste nevi.

Nekteri lide uz pochopili, ze oddelit fyziku, AI, atd... do jednotlivych vlaken je nejen elegantni, prehledne, ale nakonec mozna i jednodussi nez to vsechno bastlit do jednoho hlavniho vlakna stejne, jako to se to delalo kdysi davno na Sinclairu. Jenze tenkrat jiny HW proste nebyl a mackalo se z nej kazde procento vykonu a schopnosti. Pak prisla Amiga s jejimi koprocesory... Vim, je to slaba paralela na problem multi-core, ale nemuzu si pomoci, ze programatori dnes mrhaji prostredky, ktere maji k dispozici.


PS: Amiga 500 and SilkWorm forever.

[swarm]

Ten Tvuj clovek z icq uplne potvrdil to co rikam. O laplaceovkach pravdepodobne nema ani paru a "kodi" si neco cemu si rika fyzika. Opravdu zarny priklad. Myslim, ze jsi se ptal dobre, ale nespravne osoby Tim ho nechci shazovat, treba umi jine veci, ale fyzika a vicevlaknove programovani to nebude. Simulace v automobilovem prumyslu me zivi takze o tomhle neco malo vim. Kdyby treba vedel ze mat. modely ze Simulinku jdou vyexportovat do C bez toho aniz bych musel neco vedet o solveru... Jenze spoustu lidi proste nevi.

Ten člověk dělal arkádovku. Jestli nezná extra fyziku, tak to bylo v konkrétní hře skoro jedno. Ten rozhovor jsem uváděl k jiné části této diskuze. Btw je fajn, že děláš fyziku pro nějaký simulace. Jak moc jsou ale realtime? jsou schopný krmit vykreslovací engine, co musí jet 100fps?

[richie08]

Ten člověk dělal arkádovku. Jestli nezná extra fyziku, tak to bylo v konkrétní hře skoro jedno. Ten rozhovor jsem uváděl k jiné části této diskuze. Btw je fajn, že děláš fyziku pro nějaký simulace. Jak moc jsou ale realtime? jsou schopný krmit vykreslovací engine, co musí jet 100fps?

Chtel jsem tim jen rici, ze clovek ktery nema poneti jak se sestavuji matematicke modely fyzikalnich deju a nikdy nedelal vicevlaknovy kod tezko muze tohle soudit.

Btw simulace dynamiky motoru nebo CFD je radove hodne pomalejsi, naopak zase simulace podvozku, spotreby nebo zrychleni vozidla pres nejaky jizdni cyklus radove rychlejsi. Bezne pouzvame na takoveto simulace laptopy a pokud 25 minutovy jizdni cyklus trva vypocitat zhruba do 10s (zhruba 150x rychlejsi nez realtime) tak si myslim ze tohle zvladne v pohode realtime i stare Pentium. Jenze najdi mi vyvojare games, ktery tohle vi.

[PiT]

Btw simulace dynamiky motoru nebo CFD je radove hodne pomalejsi, naopak zase simulace podvozku, spotreby nebo zrychleni vozidla pres nejaky jizdni cyklus radove rychlejsi. Bezne pouzvame na takoveto simulace laptopy a pokud 25 minutovy jizdni cyklus trva vypocitat zhruba do 10s (zhruba 150x rychlejsi nez realtime) tak si myslim ze tohle zvladne v pohode realtime i stare Pentium. Jenze najdi mi vyvojare games, ktery tohle vi.

Jasne. A prirataj si k tomu spocitanie kolizii polygonov nie par kvadrov namiesto objektov ale kompletnej sceny co vidis a papa aj na 5 nasobne rychlejsom stroji ako dnesny najrychlejsi DC...

[swarm]

Jenze najdi mi vyvojare games, ktery tohle vi.

Najdi si na netu nějaké přednášky o fyzice z "Game Developer Session" (videa jsou stopro volně ke stažení na netu....google poradí) každoročně pořádaného v Brně. Tam si můžeš srovnat určitou úroveň. Doporučuju ti schválně si pustit i takové, ve kterých se řeší nábor do firem a co po tobě budou chtít. Třeba tě to trochu vyvede z omylu.
Jinak, co se tak dívám třeba na nezávislou herní vývojářskou scénu, tak většina lidí studuje právě přední vysoké školy (lidi z jaderky a elektro na ČVUT, kopa Matfyzáků a obdobné školy v Brně...jejich názvy rád zapomínám). Dělání her je pro programátory pomalu tím nejtěžším zaměřením, jaké si mohou zvolit, a často ne zrovna obdobně ohodnoceným. Stále mám pocit, že na herní programátory se tu nahlíží jako na "programátory databází" s letmou znalostí 3D API .

Jinak srovnáníreálných simulací s herní simulací mi nepřijde úplně vhodné, protože ve hrách jsou opravdu komplexní scény, a tak je potřeba si tu náročnost vynásobit x-krát. Nemyslim si, že by současná fyzika ve hrách byla zapříčiněna tím, že na světě máme samé hloupé herní vývojáře, co do opravdové fyziky moc nevidí. Viz první odstavec

[Petrik]

Jasny je ze vyvojari dobrych her nemuzou byt zadni tupci marne ale vzpominam, kdy jsem videl ve hre dobrou fyziku, kdyz nepocitam havok ci aegia. Ted k temto dvema: nejak si nedokazu predstavit, jak jinak by slo udelat tak dobrou fyziku bez pouziti nejake formy pokrocile fyzikalni simulace. Taky naroky na CPU naznacuji, ze to uz nebude zadna ochcavka, ale relativne velmi presny fyzikalni modelovani. Zkuste si treba v HL2 nebo FEARu strelit do nejaky poveseny lampy nebo do nejakyho lana, to je fakt husty, co to udela. Kazdopadne si myslim ze cim vice procesoroveho casu tyto enginy dostanou, tim lepe takze dokud nebude fyzika na grafikach, vivat DC

Najdi si na netu nějaké přednášky o fyzice z "Game Developer Session" (videa jsou stopro volně ke stažení na netu....google poradí) každoročně pořádaného v Brně. Tam si můžeš srovnat určitou úroveň. Doporučuju ti schválně si pustit i takové, ve kterých se řeší nábor do firem a co po tobě budou chtít. Třeba tě to trochu vyvede z omylu.
Jinak, co se tak dívám třeba na nezávislou herní vývojářskou scénu, tak většina lidí studuje právě přední vysoké školy (lidi z jaderky a elektro na ČVUT, kopa Matfyzáků a obdobné školy v Brně...jejich názvy rád zapomínám). Dělání her je pro programátory pomalu tím nejtěžším zaměřením, jaké si mohou zvolit, a často ne zrovna obdobně ohodnoceným. Stále mám pocit, že na herní programátory se tu nahlíží jako na "programátory databází" s letmou znalostí 3D API .

Jinak srovnáníreálných simulací s herní simulací mi nepřijde úplně vhodné, protože ve hrách jsou opravdu komplexní scény, a tak je potřeba si tu náročnost vynásobit x-krát. Nemyslim si, že by současná fyzika ve hrách byla zapříčiněna tím, že na světě máme samé hloupé herní vývojáře, co do opravdové fyziky moc nevidí. Viz první odstavec

[Eagle]

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:

We spoke with many developers including some big names and we learned that they can’t make much sense out of quad or more core CPUs. They confirm that they can put two cores to good use but not much more. The main problem is that the performance is far from scalable.

You have to spend both time and money to resource the programmer to try to make sense out f the dual core CPU. It takes up to a year to optimise the game for more threads and even if you make the perfect job you can count on twenty to thirty percent performance increase, and this is the best case scenario.

Once you start making the multi threaded game you end up making and having the multithreaded bugs as well.

You can keep one core busy with the physics and collision detection, second core will have to wait for the score to move on with the Artificial intelligence while the third core could possible calculate the graphic data. In this best case scenario you have to realise that the core number two and three would always have to wait for the core number one to finish its job and pass the job to the cores two and three. In this concept there is absolutely no place for quad core as games are non parallel applications. A game developer expert said that you can use the core number four to stream and load the data in the game and this is what the guys at Remedy did at IDF quad core demonstration. But this takes time and money and it is not commonly embraced by developers.

Game developers are in the dawn of dual core programming and now all the sudden AMD and Intel wants them to go quad core. For the time being Quad cores are good for rendering and serves but not for games.

So if you want to play games, you can forget about quad cores, you simply don’t need them and can gain just marginal performance out of them. Give the developers some time and this might change, but we are talking quarters not months.

Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).

[richie08]

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:



Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).

2 eagle:
1) Zalezi koho se vlastne ptal. "Expertem" muze by kde kdo, treba jako ten koho tu predhodil Swarm.
2) Byl bych opatrnejsi a prilis bych se neopiral o Fuadovy zavery. Pokud vim tak Fuad neni odbornikem ani na fyziku ani na programovani.
3) Jakkoli to cele vyzniva negativne pro QuadCore (a vic), pro DC vyuziti zrejme je velke => pobezi mnohem rychleji nez na SC.
4) Nevim proc by se jadra mela navzajem zdrzovat kopirovanim dat. Pokud se kazde bude zabyvat uplne jinou cinnosti (tedy jedno fyzikou, druhe grafikou - asymetricka vlakna) a budou si vymenovat pouze vysledky, tak tenhle specificky pripad vubec nenastane. Zda se mi, ze se ponekud demagogicky snazis zvelicovat nevyhody DC.

[Petrik]

Ted mi dosla jedna vec: tento problem je jiz totiz vyresen, jelikoz PPU Aegia ve hrach funguje a tento problem tam zrejmne nenastava, nebo je nejak elegantne osetren Navic, prenost dat z PPU pres PCI-E x16 do CPU je radove pomalejsi a ma radove vetsi latence, nez prenost dat z jednoho jadra DC do druheho, takze v pripadne DC to bude mnohem bezproblemovehjsi.
Jeste jedno upresneni ke GRAW: defautlne jede cela fyzika na havoku, PPU se pouziva pouze pokud je k dispozici na specialni efekty jako jsou vybuchy a pod. Jelikoz GRAW by mel umet vyuzit DC,a to pry dost vyrazne, predpokladam, ze prave havok bezi oddelne.

Dnes vyšel zajímavý článek na The Inquirer. Někdo z redakce hovořil s vývojáři her o možnosti využití quad-core:



Zvýraznil jsem nejdůležitější část. To docela mění zde nastolený směr diskuze - zjevně nebude problém zatížit jedno jádro výpočtem fyziky a kolizí, potíž bude v tom, že chceme-li, aby tato fyzika probíhala realtime (tj. aby například jedno auto neprojelo celé druhým a až pak byla zjištěna kolize), musí být fyzika spočítána hodně rychle, protože se jedná o sekvenční záležitost. A je zřejmě jasné, že když data musíme překopírovat z jednoho CPU do druhého, může DC dokonce i zpomalovat výpočet.

Možná by to šlo vyřešit tak, že jedno jádro bude počítat kolize a fyziku pro jeden frame dopředu, zatímco další jádra aktuální frame. To ale bude docela potíž z hlediska synchronizace a taky tam bude určité zpoždění reakcí na uživatelům vstup (čili zdaleka to nebude optimální).