Viriginia Tech gaat 'supercomputer kit' aanbieden

Techweb komt met nieuws over de nieuwe supercomputer van Virginia Tech waar we eerder over schreven. Deze combinatie van 1.100 standaard Apple G5-systemen presteert uitstekend, alhoewel de rek er nog lang niet uit is. Op dit moment haalt hij ongeveer vijftig procent van zijn theoretisch maximum, wat toch voldoende is om naar verwachting op de derde of vierde plek van de ranglijst van snelste systemen te komen. Gezien zijn lage kostprijs, die slechts een fractie is van wat andere bedrijven voor zulke computers vragen, is dit een hele mooie prestatie. Virginia Tech is zelf ook erg tevreden over de bevindingen van het onderzoek en gaat hun technologie begin volgend jaar aan de man brengen:

A university spokeswoman said the Virginia Tech Intellectual Properties unit is working out licensing and patenting issues before the technology will be offered in what university officials say will be a supercomputer kit. She added that several traditional supercomputer users including the National Security Agency and the Argonne weapons laboratory have expressed interest in the technology.

Reacties (39)

[-DarkShadow-]

Als dit een succes wordt, dan zal dit een mooie inkomstenbron vormen voor De Universiteit van Virginia. Ik las vrijdag in de Volkskrant dat over twee weken de ranglijst van supercomputers bekend wordt gemaakt en dat deze apple cluster waarschijnlijk op de 3e plaats komt. De maker verwachte nog een snelheidsverbetering van 10%. In dit artikel ineens 50%???

[Carbon]

Of dit moment liggen ze op de 3e plaats met 10.28 TFlop/s (58.4%)

Zie: http://www.netlib.org/benchmark/performance.pdf

[Anoniem: 88387]

je bedoelt natuurlijk 10.28 TFLOPS
10.28 * 10^9 FLOPS
10 280 000 000 FLOPS

[Carbon]

Heb 't inmiddels gecorrigeerd.

[Q-collective]

Nu maak je zelf toch een foutje
10.28 * 10^9 FLOPS = 10 280 000 000 000 Flops, je vergat 3 nulletjes

Edit:
Owww, jullie hebben het over Gigaflops! Ik dacht ff Teraflops

[Anoniem: 32994]

[quote]Op dit moment haalt hij ongeveer vijftig procent van zijn theoretisch maximum,[/qoute]


theoretisch presteert iets natuurlijk 100 %.. maar als je met zoeits als dit de 50 % haalt is dat vrij logisch.

dus stel je hebt een cluster van 5*2 GHZ dan presteert dat niet als 10 GHZ. maar zoals je in dit geval als voorbeeld dan maar 5Ghz zou halen. dat maar kan achterwege blivjen want met "producten" zoals dit is dat niet slecht

[jvo]

Nee, hij draait nu op 50%. Daar kan nog 10% op verbeterd worden. 100% kan hij niet halen vanwege de overhead op de cluster.

[Anoniem: 77449]

Waarschijnlijk zal nooit dat theoretische maximum bereikt worden, dus nu draait ie op 50% van dat maximum, en strax op 55%

[Iblies]

Dit is dus geen goed nieuws voor IBM, HP en Sun. Universiteiten zijn toch een flinke bron van inkomsten voor hen en nu blijkt dat een universiteit een supercomputer in elkaar heeft gezet voor de fractie van de prijs. Andere scholen zullen het voorbeeld snel volgen al was het maar omdat de middelen wat schaarser zijn.
Ook voorzie ik dat er grotere (snellere) clusters in elkaar worden gezet aan de hand van 'normale' PC, amd64 of Apple.
Als het budget hetzelfde blijft, kan het misschien lucratiever zijn om het maar zelf in elkaar te zetten en voor hetzelfde geld een machine te hebben die misschien 10 tot 20 keer sneller is.
En wat betreft support, dat mag dan een stage voor de leerlingen zijn.

[Anoniem: 88387]

hm, tis best goed nieuws voor ibm aangezien powerpc clusters flink veel ibm processoren af nemen

en daarnaast komt ibm in januari ook met powerpc 970 blades. blades zijn altijd geschikter voor clustering dan desktopcomputers als de apple powermac g5. het is voor ibm natuurlijk alleen maar beter ook de behuizing van dr processoren mee te kunnen leveren.

kon nog wel eens wat extra business voor ibm van afkomen deze 'design win' van de ibm powerpc 970 proc in de scientific computing cluster markt. en microsoft stap ook al over op de powerpc architectuur voor haar x-box.

een tijdje terug zei een meneer van amd nog dat er wereldwijd gestandariseerd moest worden op x86 processoren.

[Anoniem: 63491]

Kunnen we eigenlijk nog wel van "supercomputer" spreken. Het is gewoon 1100 standaard pc's aan elkaar koppelen en zorgen dat het werkt.
Je zou dus kunnen stellen dat het in principe geen prestatie meer is om een "supercomputer" te maken, maar meer om iets erop te installeren dat al deze pc's kan aansturen.

Misschien leuk idee voor mensen met teveel tijd over, schrijf gewoon een programma ofzo dat veel te veel pc's tegelijk kan aansturen, want dat is eigenlijk waar het bij die "supercomputers" om draait.

[Brent]

Kun je gewoon een supercomputer downloaden Slim idee!

[golfdiesel]

kan dat niet al langer? Er zijn toch al zat mogelijkheden om clusters te bouwen met standaard PC's.

[Brent]

Meestal is dat dan voor een bepaald programma en niet voor 'all-round' (alsof je dat doet op een super computer ) computerwerk.

[Supremo]

Het is maar wat je geen prestatie vindt.

Is een computer met meerdere processoren dan ook geen supercomputer, maar een machine met meerdere computers ingebouwd?

En ik zou de architectuur van het netwerk ook niet onderschatten.

Wat ik wel moet toegeven is dat er nu 3 types supercomputers zijn.

Een machine zoals bijvoorbeeld Big Blue, waarbij alles in een machine zit.

De gekoppelde machines, zoals Big Mac.

En als laatste de opstelling die gebruikt wordt bij bijvoorbeeld RC5, waarbij het werk in een enorme hoeveelheid pakketjes verdeeld is die asynchroon verwerkt kunnen worden.

[MrMr]

Ik zou zeggen:
Het is een supercomputer als er 1 kernel draait op je N pc's, en als het OS memory op elke chip kan uitdelen aan een proces op elke CPU.
Het is een berg pc's als dat niet zo is.
(Waarmee niet gezegd is dat een berg pc's niet knap gestapeld kan zijn of niet geweldig nuttig kan zijn...)

[azteke]

Onder een supercomputer versta ik een computer (al dan niet in een cluster) die wat betreft verwerkingskracht ver boven de gemiddelde pc/server uitkomt. Dus zo'n beetje alle computers in de supercomputerlijst.

[KMK]

http://setiathome.ssl.berkeley.edu/
Dat is het grootste voorbeeld van zo iets
Laat alle Idle time van PC's ter wereld rekenen en zo krijg je wel erg veel reken power.
Zo veel dat Seti het niet meer aan kan

[riffey#4]

Plaatjes:
http://don.cc.vt.edu/g5sinracks/

[Anoniem: 82253]

Deze supercomputer mag dan wel behoorlijk snel zijn, maar neemt toch ook veel meer ruimte in dan de supercomputers van IBM, HP als ik dat zo zie. Of zie ik het nou verkeerd

[gp500]

En toch heb ik het gevoel dat een cluster met opteron's beter kan.
Die doen in node als dual het al heel goed.

En mischien om het nog goedkoper te maken gewoon single athlon64's nodes. (of dual athlon fx als je die als dual kunt modden, waar kans op is denk ik).

Die zijn per stuk goekoperm inder stroom geloof ik en warmte

[Anoniem: 88387]

de opteron heeft een theoretisch maximum aantal FLOPs van 2 per cycle. de powerpc970 kan twee keer zoveel FLOPs per cycle doen namelijk 4. kijk hier maar voor een nadere uitleg: http://www.tweakers.net/reacties/?Action=Posting&ParentID=863003

FLOPs (double precision floating point) zijn maatgevend voor de supercomputer hitlist. hoe meer FLOPs deste beter. je zou voor een gelijkwaardig opteron cluster 2x zoveel opterons nodig hebben als powerpc 970's. dit is dus een duurdere oplossing en de belangrijkste reden waarom die universiteit voor G5's gekozen heeft en niet voor opterons/xeons.

qua Mhz en energieverbruik ontlopen de opteron en de powerpc 970 elkaar niet zo veel. maar ja dubbel zo veel opterons neemt natuurlijk nogal wat extra kilowatjes.

edit:
@GP500

ah ja zoiets verwachtte ik al. zon amd freak die ondanks mijn uitleg over FLOPs toch vol blijft houden.

om de ibm ppc 970 FLOP for FLOP bij te houden moet de opteron dubbel zo hoog geclocked zijn. voor een ibm ppc970@2Ghz betekent dit dat je een opteron op 4 Ghz nodig zou hebben. ik ken de roadmaps van amd niet uit mn hoofd maar ik denk dat dit nog wel een tijdje zal duren.

cray is bezig met een supercomputer. meer dan 10 000 opterons en een peak performance van 40 000 TFLOPS (theoretische piek). de Big Mac heeft 2200 ppc970's en komt al boven de 10 000 TFLOPS (in de praktijk behaald) uit.

de cray gaat kosten $90 miljoen, de Big Mac is meer dan 10 keer goedkoper terwijl de performance van de cray maximaal 4 keer beter is.

http://www.eweek.com/article2/0,4149,652520,00.asp

[gp500]

Je hebt je het nu over een 1:1 verhouding.

In cluster kan de uiteindelijk yield (kracht beter zijn).

Afgezien van het vermogen, kun je voor het geld dat je aan hardware koopt voor een G5-kast veel athlon64 of opteron kopen.

En dan waarschijn ook nog meer GHz wat dus weer dat aantal Gflops compenseerd.

Het uiteindelijk plaatje gaat het om.

Eigenlijk zou je dit eerst eens voor 1 TFlop (ideaal) en voor 20 Cpu's en voor € 50.000 uit moeten rekenen.

En dat naast elkaar houden.

[zakalwe]

Het prijsverschil van een werkstation met dual G5 of dual Opteron is niet zo groot (bron: PriceWatch).
Het verschil is net 300 euro, en dan heb je bij de G5 een OS en de Opteron niet (ja, Linux). Ga je de Opteron in een 1U kast stoppen ben je even duur uit.

Natuurlijk is dan de Opteron cluster kleiner qua formaat.
Pas als Apple de XServe G5 uitbrengt, krijg je een duidelijke favoriet.

[gp500]

Je vergelijkt nu door een bedrijfgemaakt product met een door studenten inelkaar gezet product.

Maar ik duide op athlon64 (fx) en niet op opteron's die zijn veel duurder.

Maar je het echt uit moeten rekenen, anders weet je het nog niet.

[Anoniem: 20600]

Stel dit systeem kost een X-bedrag, als je nou dat X-bedrag spendeerd aan opteron ben je dan niet veel en veel sneller, like 20 of 30% zelfs?

[cc bcc]

Ze hebben alle opties uitgezocht voordat ze hoorden dat Apple met de 64 bits G5 kwam, dus nee, voor de toepassingen waarvoor de cluster gebruikt gaat worden is de opteron niet sneller. Vergeet niet dat er op de ppc 970 een erg snelle SIMD zit.

[Anoniem: 62890]

10Gflop Haalt mijn mac thuis
het is Tflop

[Anoniem: 4087]

een dual G5?

[Anoniem: 95252]

Ik dacht dat de g5 d.m.v een slimme branch-predictor hardwarematig hash-verificatie aankon? Veel weet ik er ook niet van, maar dat dacht ik uit de volgende link af te kunnen leidden: http://www.apple.com/g5processor/executioncore.html .

[Anoniem: 69322]

In dit artikel en de whitepaper komt het woord hash niet voor, en de pagina lijkt meer op een comercial voor de G5/MAC...het brein in uw MAC....enz...

De zaken worden hierin bijna als mytish bescreven, terwijl alle genoemde technieken ook in andere processoren terug te vinden zijn. Niet dat een G5 een slechte processor is, helemaal niet, ziet er wel goed uit, maar daar gaat het in dit geval niet om.

[Anoniem: 96835]

iedereen lijkt te vergeten dat dit een cluster betreft
en dat het veel langer duurt om data te versturen
van de ene naar de andere processor dan een
echte supercomputer....Teraflops zijn niet de
enige snelheidsbepaling, een cluster kan prima
zijn voor bijv. projecten zoals die van distributed.net,
voor andere programma's kan het juist heel belangrijk zijn hoe snel de ene processor de andere
kan bereiken!

[Anoniem: 69322]

Verder is het ook nog zo dat deze G5 systemen geen error correctie geheugen kunnen gebruiken. Dit betekend dat iets wel 'snel' af kan zijn, maar dat het minstends 1 en liefst meerdre malen herberekend moet worden om er zeker van te zijn dat een reslutaat klopt.

Voor een betrouwbaar resultaat eindig je dus met een extra lastig te programeren systeem, wat ook nog eens meer dan 2 tot 3 keer zo traag is als men je wil doen geloven. Persoonlijk vind ik het dan ook niet meer dan een leuk hobbie project van een universiteit. Iets wat overigens ook veel te veel publiciteit heeft gekregen, alleen maar omdat een een G5 in ziet die ook door apple gebruikt wordt, zo vermoed ik.

[Carbon]

Verder is het ook nog zo dat deze G5 systemen geen error correctie geheugen kunnen gebruiken. Dit betekend dat iets wel 'snel' af kan zijn, maar dat het minstends 1 en liefst meerdre malen herberekend moet worden om er zeker van te zijn dat een reslutaat klopt.

Je kunt heel eenvoudig en snel een hash berekenen over de data en de code.
Na afloop van de berekening doe je hetzelfde nog een keer en vergelijkt de uitkomst, indien ongelijk dan is het resultaat van de berekening onbetrouwbaar.

Deze methode is vele malen beter (gevoeliger) in het detecteren van memory errors dan ECC memory.
Je levert uiteraard iets in aan node perfomance maar dat wordt ruimschoots gemaskeerd door de node communicatie (de echte bottleneck)

Voor een betrouwbaar resultaat eindig je dus met een extra lastig te programeren, wat ook nog eens meer dan 2 tot 3 keer zo traag is als men je wil doen geloven

De aanpak is volledig transparant, maw als programmeur hoef je er geen rekening mee te houden.

Persoonlijk vind ik het dan ook niet meer dan een leuk hobbie project van een universiteit.

Misschien moet je je eens wat meer verdiepen in de materie alvorens dat soort ondoordachte uitspraken te doen.

[Anoniem: 69322]

Een hash berekenen kost wel degelijk een berg performance. Om er zeker van te zjin dat deze methode geen onjuiste data twee keer leest moet aan een aantal voorwaarden voldaan wordern:

* Alle data en code in het geheugen moet beveiligd zijn (verifieerbaar) met zo'n hash (2 keer lezen alleen is niet voldoende).

* Er zal rekening moeten houden met de cache hierarchie van de betreffende architectuur. Zodat je niet twee keer dezelfde fout 'cached' leest. Daarom zullen cache flushes (heer erg kostbaar in termen van performance) onvermijdelijk zijn.

Om ook geheugen leesfouten (hoe klein ook) tijdens de berekeningen zelf te detecteren zul je toch echt de berekening meerdere malen moeten uitvoeren met data niet afkomstig uit de cache. Dit kost dus we wel degelijk bergen performace in de order van 2 of meer keer.

Dus zo eenvoudig als jij het stelt, dat het slechts gaat om een eenvoudige en voor de ontwikkelaar transparante methode gaat klopt niet IMHO.

Verder slaat die claim van je dat een hash vele malen naukeuriger is, nergens op en is totaal misleidend voor mensen die er minder vanaf weten! Hardware matige ECC kan voor IEDERE byte ONAFHANKELIJK een foutive bit corriegeren en een tweede detecteren. Er wordt dus per byte een extra bit ingezet (12.5% redundancy).

Een hash zoals jij voorsteld is slechts 64 (mogelijk 128 bits, maar is nog langzamer) per 1,2,4 of 8 KB, enz. Meest aannemelijke (snel) is een hash van 64 bits en als dit per 1KB block wordt gebruikt, dan kom je op een redundancy van (64 bits = 8 bytes op 1024 bytes = 0,78125%), ofwel 16 keer zo weinig en dan kan er alleen nog maar gedetecteerd worden...en dit is beslist niet naukeuriger!

Ik ben hier uitgegaan van enkele aannemelijke waarden (wil je de performance niet helemaal laten kelderen), maar wat jij denkt dat het best te gebruiken is zou ik dan wel eens willen weten. Je raad het al.....ik kan er met mijn hoofd niet bij hoe jij denkt te kunnen verdedigen dat een softwarematige hash transparant is en nog naukeuriger is dan hardware ECC. Mischien dat je hier een goede URL voor kan leveren?

Data verificatie met hashes of CRC's is een goede aanvulling waar het betrouwbaarheid betreft van opslaan en uitwisselen van data tussen nodes, maar om het als vervaning te zien (en naukeuriger) dan hardwarematige ECC lijkt mij echt erg ver gezocht!

[Carbon]

* Alle data en code in het geheugen moet beveiligd zijn (verifieerbaar) met zo'n hash (2 keer lezen alleen is niet voldoende).

Ook ECC kan die garantie nooit geven.

Verder slaat die claim van je dat een hash vele malen naukeuriger is, nergens op en is totaal misleidend voor mensen die er minder vanaf weten!

Alles hangt af van de gekozen methode, maar er zijn methodes (bv. Reed Solomon) die eenvoudig in software zijn te implementeren en veel betere foutcorrectie garanderen dan ECC

Hardware matige ECC kan voor IEDERE byte ONAFHANKELIJK een foutive bit corriegeren en een tweede detecteren. Er wordt dus per byte een extra bit ingezet (12.5% redundancy).

Nu haal je twee dingen (parity,ECC) door elkaar, voor parity check is inderdaad maar één extra bit per byte nodig, echter dat is niet voldoende om single bit errors te corrigeren en dual bit errors te detecteren, daarvoor heb je 3 bits per byte nodig.

Dus zo eenvoudig als jij het stelt, dat het slechts gaat om een eenvoudige en voor de ontwikkelaar transparante methode gaat klopt niet IMHO.

De methode die ik schetste kan wel degelijk transparant geimplementeerd worden. maar laten we gewoon afwachten totdat ze de sourcode van het systeem gereleased hebben.

Je raad het al.....ik kan er met mijn hoofd niet bij hoe jij denkt te kunnen verdedigen dat een softwarematige hash transparant is en nog nauwkeuriger is dan hardware ECC.

Standaard ECC hardware heeft maar 3 check bits/byte, met een software oplossing heb je die beperking niet.
De prijs is dat je performance inlevert en er extra redundatie voor terugkrijgt.

[Anoniem: 62890]

Hij heeft all 10Teraflop gehaald...
staat dus op de derde Plaats van de wereld