Mir, Nem mondtal ellent nekem, hanem kiegeszitetted azt. Egyben valaszod ravilagit arra, mennyire torekenyek ezek a vitak(?) itt. Valoban, a 'network overhead' fogalmat nem definialtuk. :) Az en ertelmezesem kicsit tagabb volt, amirol te azt gondoltad, csak a kommunikacios overhead-rol beszlek. De jo ez igy. Pongyola megfogalmazasok... nyilvan nem doktori disszetacio. Inkabb eletestudomany szintu ismeretterjesztes, gondolat ebresztes, mas szompontok megvilagitasa. :) :)
"Ha a halozati kapcsolatnak van overhead-je (mindig van!!), akkor az a Google eseten is van. Persze vegtelensegig novelheto az osszekotott gepek szama, viszont ezzel aranyosan megno a belso adatbazis szinkronizacios - egyebkent improduktiv, adminisztracios - feladatok mennyisege." de pl. a google esetében teljesen megengedhetõ a fõ adatbázis és a nodeok adatbázisa közötti 1-2 napos eltérés, tehát ott például az adatbázis szinkronizáció nem jelent problémát
Azutan ott vannak a nagyon osszetett problemak: pl. numerikus vegeselem modszer (pl. idojaras). Ez frankon parhuzamosithato. Lehetoleg egy 3D halozattal, ha kerhetnem.... Minden node a ter egy megfelelo kockajaban vegez diszkret szimulaciot, kozben folyamatosan megosztja mind a hat szomszedjaval az eredmenyt. (Gyanitom 26 szomszeddal a network overhead mar tul nagy lenne.)" megfelelõ irányítással nem a network overhead lesz nagy, hanem az árak szöknek az egekbe, nomeg az az az iszonyatos mennyiségû kábel, amit az interconnect felemészt csak a helyet foglalja, az earth simulator építésénél ha jól emlékszem a (elfelejtettem a megfelflõ szakszót), a lényeg az, hogy minden node minden node-al 1 interconnect HUBon keresztül tud kapcsolódni, és mindegyik egyszerre, tehát a mindent-mindennel elv lehetõ legegyszerûbb de még lehetséges megvalósítása többe került, mint a NEC CPUk, pedig ott a fejlesztést is õk fizették.
A SETI, Google, Genom Project es mas, egyebkent onallo kezdettel es veggel rendelkezo, egyedi szamitasi feladatokra lebontott problemak nem kulonboznek elviekben sem a szorosan csatolt, mint pl. a cikkben emlitett halozatokhoz. Mas szempontok szerint vannak optimalizalva.
Ha a halozati kapcsolatnak van overhead-je (mindig van!!), akkor az a Google eseten is van. Persze vegtelensegig novelheto az osszekotott gepek szama, viszont ezzel aranyosan megno a belso adatbazis szinkronizacios - egyebkent improduktiv, adminisztracios - feladatok mennyisege.
Valoban. Ezek a draga berendezesek teljesen feladatorientalt modon lettek megtervezve, parhuzamosan a halad a szoftver es hardverfejlesztes. De azert ez is egy kozgazdasagi optimalizalasi feladatta valt meg azelott, hogy egyetlen sor kodot irtak volna.
Vanak olyan progamozasi nyelvek es paradigma rendszerek, amelyek elfedik a mukodteto hardvert. Peldaul lasd ZPL es Videke Afesz: http://www.cs.washington.edu/research/projects/zpl/
Azt persze altalaban elmondhatjuk, minel gyorsabb a szamitogep (hardver/szoftver), minel gyorsabb a halozati osszekottetes, minel kisebb az oprendszer/network overhead, annal nagyobb lesz a rendszer teljesitmenye.
No es most jon a matek/kozgaz resze a dolognak: A feladat megoldasahoz mondjuk kb. 7*10^45 lebegopontos muveletet kell elvegezni. Hogy ertelme legyen a beruhazasnak, meg kell legyen az eredmeny, mielott a. kijon egy fajlagosan sokkal olcsobb/gyorsabb rendszer, b. az eredmeny meg ervenyes. c. megeljuk a veget. d. a befekteto eleg turelmes, e. stb...
Ismerve a feladat termeszetet adni kell egy jo becslest a parhuzamosithatosagra. ti. a PI kiszamolasa nem igazan parhuzamosithato, mert numerikus modszerrel iteralni kell, meg kell varni az elozo reszeredmenyt. Ez egy tipikus egyprocesszoros feladat.
Masik veglet: Google, SETI, Prim szam kereses. Egymastol fuggetlen keresesek (onmagaban ez is egyprocesszoros, de sok feladat parhuzamosan), elhanyagolhato network overhead-del.
Azutan ott vannak a nagyon osszetett problemak: pl. numerikus vegeselem modszer (pl. idojaras). Ez frankon parhuzamosithato. Lehetoleg egy 3D halozattal, ha kerhetnem.... Minden node a ter egy megfelelo kockajaban vegez diszkret szimulaciot, kozben folyamatosan megosztja mind a hat szomszedjaval az eredmenyt. (Gyanitom 26 szomszeddal a network overhead mar tul nagy lenne.)
Es meg van mondjuk 826 kulonbozo tervezesi szempont. Nem hulyek ezek a fiuk.
amúgy ezeken a gépeken általában azért fut linux, met nagyon könnyen mindenki a saját céljaira tudja alakítani.
sajnos ennek elég kevés köze van az oprendszerhez. olyan szinten van, hogy az oprendszer alkalmas-e egy adott feladat megoldására tervezett kalszter üzemeltetésére, de onnan kezdve, hogy alkalmas már az oprendszernek szinte semi köze sincs a dologhoz, mert ezeken a klasztereken használt oprendszerek csak távoli rokonságban állnak általában azokkal, amiket ismerhetsz a PCkrõl. és a lényeg: elsõ sorban a futtatott program határozza meg a klaszter maximális méretét, másodsorban a nodeokat összekötõ hálózat. de a legfontosabb akkor is a program, amit futtat. ha a futtatott program mondjuk 2000 node-ig van optimalizálva, akkor hiába futtatják egy 5000 node-os rendszeren, még ha valami hiper-nasa összekötést is csináltak. azon kívül a futtatott programot magához az összekötõ rendszerhez is tervezik. itt nem HW, meg szoftver van, hanem RENDSZER és ezt együtt tervezik. nem külön külön.
hát ja .. a node-ok közötti adatforgalom egy idõ után már több mint a hasznos .. ekkor már hiába bõvítjük 10 "procival" meg a hozzá járó memóval stb.. több terhelést jelent az egész fürtnek mint ha nem is tennénk bele..
az alapkérdés az az, hogy valamilyen adott feladatot megoldó programot érdemes-e, azaz lehet-e fürtözött rendszeren futtatni hastékonyan. ha lehet, akkor lehet elgondolkodni azon, hogy mekkora fürtre tudják a programot megtervezni, mert egy-egy ilyen fürtöt a futtatandó programhoz terveznek, és vice versa. tehát van olyan feladat, aminek a megoldására szinte korlátlan darab számítógépet lehet összekapcsolni(google), és van olyan, amit meg sem próbálnak fürtön futtatni. de ha már adott a fürtön futtatott program felépítése, és az nem szab határt a fürt méretének(azaz nem túl specifikus) akkor a legnagyobb problémát a fürt nodejait összekötö ritkán 1, leginkább 2, legjobb(és messze a legdrágább) esetben három dimenziós hálózatra kötik(ne ethernetet képzelj el) és ez az összekötõ hálózat adja a fix korlátot egy adott program(ami korlátlan node-on való futást tesz lehetõvé) futtatására alkotott fürt méretére. ez nagyon vázlatos, rövid, pontatlan volt, csak megpróbáltam rávilágítani a lényegre egy aspektusból.
Informatika és tudomány
