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:)