#40
Ha szerinted a C, vagy barmelyik mas alacsonyabb szintu programnyelv a jo kis POSIX/Win32/etc szinkronizacios mechanizmusokkal kiegeszitve ugy jo, ahogy van a
sokszorosan tobbszalu hardver programozasahoz, akkor sok szerencset kivanok a jovohoz.
A cluster-ek programozasa merfoldekre esik egy tobbmagos processzor programozasatol, ebben egyetertunk.
Konnyu egy veges elem szimulaciot vagy egy CGI renderelest szetdarabolni tobb processzorra, de mit kezdesz mondjuk egy rekurziv problemaval, ami csupan lokalisan, mondjuk egy relative kis ciklus belsejeben parhuzamosithato? Olyakor jon elo az igazi problema, hogy a meglevo szinkronizacios infrastruktura teljesitmenye elegtelen a par mikroszekundumos feladatok osszehangolasahoz (talan a real-time OS-eket kiveve). Ilyenkor hol vannak a szukseges eszkozok? Ne felejtsuk el, ma meg "csak" 8 magot kell kezelni, de 5 ev mulva mar lehet, hogy 64-et.
Neki lehet allni a 8-64 szalat "kezileg" szinkronizalgatni, de a fejlesztesi ido akkor elszall az orokkevalosagig. Sot minden feladatnal ujra kell kezdeni az egeszet. Raadasul a szinkronizalas overhead-je egyre csak no.
Az egyik megodas, hogy ujratervezzuk az algoritmusokat, pl egy skalazhato pipeline architekturaba (a Cell-t erre talaltak ki). A masik meg az lenne, ha leteznenek olyan fejleszto eszkozok, amik mar a programnyelvekbe integralva tamogatnak a tobbszalusagot. Milyen szep is lenne, ha pl lenne olyan ciklus vagy elegazas, aminek a kulonbozo agai maguktol kulon threaden futnanak. Ekkor a programozo feladata csak annyi lenne, hogy eldontse, hogy mely agak hogyan futhatnak egymas mellett. Lefogadom, hogy hamarosan kijonnek a megfelelo programnyelv kiterjesztesek. Egesz biztos, hogy mar ma is sokan hasznaljak makrok tucatjait ugyanilyen celra (amolyan berhelt kiterjeszteskent).
Igenis paradigmavaltas van folyamatban. Mi masnak nevezhetnenk azt, amikor a tegnapi 1 feladat 1 szal utan holnap mar 1 feladathoz akar tobb tucat szal is tartozhat. Es a szamokon tul ez egy alapjaban eltero strukturaju programkodot jelent a hatterben.
(Jo pelda pl az ITK/VTK, ami egy thread pool-bol dinamikusan szabalyozza a filterek eroforras hozzafereset, bar ehhez persze az kellett, hogy az egeszet mar az alapoktol multithreaded-re tervezzek.)
De nem is kell bizonygatnom nekem itt semmit, hiszen a tenyek engem igazolnak. Eleg csak megnezni a jatekok skalazodasat a processzorok szamaval. Hat szanalmas! Pedig, egy jatekban a legtobb feladat elmeletben gyunyoruen parhuzamosithato lenne. Az, hogy megsem skalazodik jobban a teljesitmeny kizarolag annak koszonheto, hogy a fejlesztoknek nem eri meg annyi munkaorat beletenni a plusz optimalizacioba. Es miert kellene ennyi plusz munkaora? Mert a jelenlegi fejlesztoeszkozokkel ennyire bonyolult a parhuzamositas.
Hogy adottak-e az eszkozok a parhuzamositasra? Mindig is adottak voltak.
Jok-e? Nem elegge.
#40