waterman#28
CPU szinten nincs olyan hogy szál. ott task-ok, feladatok vannak. a mai processzorok magja az ALU és az FPU általában RISC architektúrára épül, azaz sok egyszerű utasítást bődületes sebességgel elvégezni. ez aztán hogy kompatibilis maradjon ezért alkalmaznak egy CISC interpretert (magasabb szintű utasításokat értelmező egység) amivel különböző optimalizációkhoz jutnak - SSE, MMX, 3Dnow. ezek olyan utasításokat tartalmaznak amit egy RISC mag sosem értene meg, mert 50 utasításból áll az egész tudástára. a köré épített CISC struktúrát használva a magasabb szintű utasítások (több száz összetett parancs) gyorsan fordíthatók kicsi gyorsan végrehajthatókká. ezen a szinten pedig megszűnnek létezni a programok, itt csak olyan van pl, hogy memóriacímet add össze memóriacímmel. tehát a CPU szintjén már régóta cincálják apró darabokra a programokat/szálakat.
a gond az egyszálas algoritmusokban keresendő. példának itt egy egyszerű játék elvi váza:
repeat - ismételd míg ESC parancsot nem kapsz.
if (keyPressed) - ha megszakítás volt a bemeneten
read (key) - karaktert beolvasó függvény a bemenetről
else
animate() - animáló függvény
render() - renderelő függyvény
until(ESC) - ha jön az ESC kilép, de addig a ciklus folytatódik
azaz a ciklus fut a végtelenségig, ha jön egy billentyűlenyomás az inputról, akkor azt tudomásul veszi, különben a játékmotor újraszámolja a karakterek elmozdulását, azt hogy mit fogsz kb látni, majd lerendereli a képet és kiküldi a kimenetre. a gond ott kezdődik, hogy az animálás elé még szúrd be a
fizikaiSzámolás()
mesterségesInteligenciaSzámolás() -t. sajnos ezek olyan dolgok, amik egymástól függenek, tehát elég nehéz megoldani, hogy a játék gyors legyen és még a fizika is jól működjön, meg minden klappoljon és még gyors is legyen. ha úgy írnák meg, hogy nem sorban számolja ki a program ezeket hanem mondjuk elindítunk 4 szálat a programon belül:
1 szál:
repeat
if (keyPressed)
read (key)
else
környezetiVáltozókBeállítása()
animate()
until(ESC)
a 2. 3. 4. szál külön ciklus lenne, de egybe írom / jelekkel. szerintem egyértelmű azért így is.
repeat
fizikai / mestInteligencia / render -ParaméterekBeállítása
fizikaSzámolás() / M.I.számolás() / renderelés()
fizikai / M.I.paraméterek visszaírásaKörnyezetiVáltozókba()
until(amig az első szál él)
ekkor a 4 szál függetlenül fut egymástól, nagy lesz a játék FPS aránya, mert nem függ a renderelés a pl. fizika számításától, hanem ha renderel, akkor lerendereli azt amit épp a környezeti változókban talál. előfordulhat, hogy az előző képkocka van még ott.. ez ilyen struktúra már több magot is kihasznál, hátránya hogy környezeti változókat kell írkálni, meg átadnia a szálaknak.
más.
tömörítéskor is hasonló nehézségek lépnek fel. le kell ellenőrizni az adott adathalmazt gyakorta ismétlődő elemek után. pl ha letömörítesz 130 képet és mind jpg, akkor az első 500byte mindig nagyon hasonló. ezeket egybe lehet tömöríteni, lehet gyártani hozzá egy egyszerű mintát. de! a winchester pl elég lassú, tehát arra várni kell, plusz lehet hogy egy szálon végigtoltam egy mintakeresést, addig mit csináljon a másik szál? csak úgy a semmibe nem kezdhet bele, erősen függ a másik szál eredményétől.
viszont mondjuk egy 3Dstudio-s, Maya-s animáció renderelésekor el kell mondjuk készíteni 200 képkockát. a legtöbb képkockát alapjaiból újra kell számolni. maga az animáció sematikus (mondjuk drótvázas) előnézete pillanatok alatt elkészül, tehát ez az alap -> a képkockák tartalma minden pillanatban előre ismert. akkkor mi tart sokáig? pl egy egy képkockán van 4-5 fényforrás és sugárkövetéssel, gradiens árnyékolással szeretném megjeleníteni az animációmat. na az erőforrásigényes, ilyenkor ha van 4 magja a gépnek akkor nekifeszítem őket egyszerre 4 képkockának, ha van egy 30 gépes renderparkom akkor rászabadítok arra a 30 gépre egyszerre 30 képkockát. tehát masszívan párhuzamosítható a feladatoknál nagyon jól jön a sok mag. és ugye akkor minél többen dolgoznak rajta, annyival gyorsabban leszek készen. na jól elszálltam, respect annak aki végigolvasta:)