Spencer

2005-ben készül el a második IBM Blue Gene/L szuperszámítógép

Az IBM bejelentette, hogy egy hollandiai rádióteleszkópos projekt keretein belül hamarosan üzembe helyezi második Blue Gene/L szuperszámítógépét.

A Linux operációs rendszerre épülő szuperszámítógépet előreláthatólag valamikor a jövő esztendőben adják át az Astron nevezetű holland szervezetnek, mely különböző rövidhullámú rádióteleszkópos kísérleteket folytat. A nem kevesebb mint 12 ezer darab processzoros rendszer másodpercenként több mint 30 billió számítás végrehajtására lesz képes.

Napjaink legnagyobb teljesítményű szuperszámítógépe, a 2002-ben épített NEC Earth Simulator másodpercenként mintegy 35,6 billió számítást képes végrehajtani, azonban a közeljövőben több olyan szuperszámítógépet is átadnak, melyek komoly versenytársat jelentenek majd a Föld Szimulátor számára. A Virginiai Műszaki Intézetben például hamarosan elkészül egy 1100 darab duálprocesszoros Apple Computer számítógépből álló, IBM-féle PowerPC 970 processzoros rendszer, a Los Alamos National Laboratory pedig egy 2816 darab AMD Opteron processzort magába foglaló új szuperszámítógépet kap a közeljövőben.

Ugyancsak említésre méltó, hogy a Linux Networx egy olyan 2132 darab Xeon processzoros szuperszámítógépet szállít le az Egyesült Államok hadseregének, melyben többek közt 1066 darab 64 bites kiterjesztésű Intel processzor lesz. Ahogy arról korábban beszámoltunk, utóbbi processzorokról először a napokban lezajlott tavaszi Intel Developer Forum keretein belül hallhattunk. Az Intel első 64 bites kiterjesztésű, jelenleg Nocona fejlesztési kódnevet viselő Xeon processzorai várhatóan idén júniusban jelennek meg a kereskedelmi forgalomban.

Az első Blue Gene/L szuperszámítógépet a közeljövőben a Lawrence Livermore National Laboratory fogja használatba venni. A rendszert úgy tervezték meg, hogy maximális teljesítménye minden további nélkül elérhesse a 360 teraflopot, vagyis másodpercenként akár 360 billió számítást is képes legyen végrehajtani.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • mir #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. :)
    :)
  • mir #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.
  • mir #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.
  • mir #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 #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..
  • mir #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?