vícejádrové programování?

[shipo]

Neznáte někdo nějaký odkaz, název knihy nebo příklad o problematice rozdělení aplikace(her) na paralelně běžící části?
Stačilo by snad rozumně vytvořit co nejvíce podprocesů a nechat systém ať si je aktuálně rozdělí na jádra CPU podle zátěže?

[rezna]

vysokoskolska skripta o paralelismu - zakladni synchronizacni techniky (mutex, kriticka sekce, ...) - rozdeleni casovych kvant pro jednotliva vlakna/procesy - vzdavani se casoveho kvanta - aktivni/pasivni cekani - ...

netyka se to vice-jadroveho programovani - obecne staci multi-threaded programovani - to ze mas vic jader je dnes jenom takove "IN", ackoliv je to stare a zname protoze vice procesorove stanice jsou tu uz nekolik desitek let, a stejne tak treba gridy/clustery

[Fila]

[Ladis]

Ve hrach je multithreading relativne stale jeste novinka, takze o tom asi moc clanku nenajdes. Muzes si vygooglit clanky a prezentace Tima Sweeneyho, autora noveho Unreal3 enginu, nicmene po zadani tim sweeney multithreading do Googlu je spousta toho jen nejaky kratky zpravy nebo diskuzni fora .

EDIT: Jo jinak, ja bych problem vyuziti jader CPU zkusil realizovat modelem producer-consumer. Pro predstavu, nejaky prehledny priklad: Mas softwarovou transformaci vertexu modelu ve hre, tak single-threaded model je, ze projde pole vertexu od zacatku do konce a kazdy transformuje. Multi-threaded model producer-consumer je, ze mas objekt, ktery vrati nasledujici kus N vertexu ke zpracovani, a objekty, ktere obdrzeny kus transformuji (a nekam ulozi). Takze pak pro 2 jadra mas 2 consumer-thready, kazdy si vezme treba 1000 vertexu, a kdyz je s jejich zpracovanim hotov, tak si vezme dalsi kus, dokud to neni cele zpracovane (predpokladam vytizeni objektem vracejiciho vertexy minimalni; obe jadra budou naplno vytizena a je jedno, jestli nektera zpracovavana data jsou zpracovana rychleji nebo pomaleji - narozdil od modelu, kdy si zpracovavana data rozdelis na stejne velke dily).
_________________
Award-winning game developer

[rezna]

Ladis: to je dobry napad, ale musi se dat pozor na to abys ty pocty vertexu mel opravdu rozumne velke, jinak muze prijit neprijemna rezie prepinani vlaken a prilis velka rezie pridelovani kusu

treba pokud nekdo pracuje s 1M vertexu tak 1k vertexu jako dil je dost malo. spis tak 100k vertexu by bylo optimalni - protoze si predstav ze se bude muset 1000x prepnout vlakno a 1000x pridelit zpracovavany kus.

kdezto i pri kusu 100k vertexu je porad sance na az 2nasob. urychleni a pritom tam nemas rezii prepinani vlaken - prepne se +- 10x

Autor: dalsi moznosti kde je uziti multithreadingu (a tim moznost pripnout vlakna k ruznym procesorum (nerikam schvalne jadrum, protoze proste jsou to procesory) je oddelit grafiku a fyziku a kazde pocitat s jinou frekvenci (ikdyz i toto si kolega z prace osetril do single-threadu). typicky fyzika drzi svuj posledni stav vystaveny 0.1s a az pak se znovu dopocita a vystavi novy stav - to mezi tim se interpoluje (protoze typicky grafika na 60FPS ma tedy delku jednoho "stavu" 0.0166s.

ale je potreba se zamyslet jestli se ti tyto hratky vyplati.

PRO:
-- jednoznacne pro je zprehledneni citelnosti kodu
-- nemyslim ted samotnou synchronizaci vlaken/procesu ale to samotne oprogramovani fyziky napr. proste dany kus kodu je jenom fyzika, v nekonecne smycce se ti nemicha vsechno dohromady

PROTI:
-- problemy s uvaznutim - dead-locky - toto je snad nejhorsi vec nad odladeni, protoze to typicky nastava zcela nahodne
-- problemy se sdilenim dat - musis si dat pozor aby vsechna data ktera sdilis a je mozne do nich i zapisovat byla pocitve uzamykana a tudiz nedoslo k tomu ze jeden druhemu neco prepise

takze prvne by tvoje uvaha hlavne mela smerovat na to co je pro tebe lepsi - jestli obetovat cast vykonu a mit kod ktery se nechova cas od casu znacne nepredpovidatelne a nebo jestli ti stoji jit do nekonecneho debugovani a hlavne do teoretickych uvah a modelovani propojeni sdilenych objektu za nejaky ten vykonnostni narust.

[Fila]

Jen poopravim Reznu -- pokud ti bezi na kazdem procesoru jedno vlakno, tak te nemusi trapit prepinani stavu, zadny se neprepina. I tak je ale treba davat bacha, abys vytezil vic z paralelniho spracovani, nez promrhal komunikaci mezi thready a zamykanim. Obecne se hodi paralelizovat vypocty, kdy jsi schopen rozdelit data nad kterymi pracujes na vice skupin a ty pridelit jednotlivym vlaknum, v momente, kdy se o tato data (pri zapisu) vlakna tahaji, to je problematicke.

[kerekes]

Pokial by slo o c++, tak nedavno som zacal skumat OpenMP. Ide o kniznicu pre podporu multithreadingu na zaklade zdielanej pamate. Pracuje sa s tym celkom jednoducho (resp. ovela jednoduchsie ako priamo s volanim os-ka (winapi). Musi to vsak podporovat kompilator. Defaultne to podporuje vc++ 2005 pro, myslim ze aj g++ od nejakej verzie 4.2.
Napriklad automaticke rozdelenie spracovania cyklu for sa da definovat:

[shipo]

Všem moc děkuju za rychlé odpovědi , docela mě nasměrovali(už vím co a kde hledat).
Nejde mi ani tak o pararelní řešení 1 výpočtu(SIMD), ale spíš o zkloubení několika různejch oblastí(AI,Fyzika,příprava,analýza) ve hře, co si můžou krádkodobě žít vlastním životem. Krásně to vystihl rezna: