13
-
#13
valóban:) és akkor még a VMS klaszterekről nem is beszéltünk:) pedig ott vannak csak igazán megasütemény dolgok :D -
Pepito #12 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. :)
:) -
#11
"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. -
Pepito #10 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. -
#9
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. -
#8
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. -
![[HUN]PAStheLoD](https://media.sg.hu/forum/avatars/10334754621140968716.jpg "[HUN]PAStheLoD")
#4
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.. -
#3
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. -
Pepito #2 Abba lehetne hagyni ennek a "felvertezett" kifejeznek a hasznalatat? Mindig ezt hasznaljatok, fiuk.
Egy szamitogep egyebkent sem "felvertezve" van a processzorokkal.
De a "teljesit szolgalatot" is kezd idegesito lenni egyebkent.
En megertem, hogy ha valaki szamitogepekrol beszel, akkor ohatalanul ismetlodo kifejezeseket kell hasznalnia valamilyen szinten. De ami sok az sok.
Koszonom. -
Zombye #1 Ezeknek a fürtözött rendszereknek van mennyiségbeli korlátja, vagy elvileg korlátlan számú gépet lehetne integrálni egy ilyen szuperszámítógépbe?