CXS600 - enorm ekstra regnekraft

[Del]

Lær dere å stave, det staves Matlab. Det er neppe Matlab og Mathematica clearspeed blir brukt til. Mathematica brukes hovedsaklig til symbolske, meget lette oppgaver. Matlab er beregnet for numeriske matriseoperasjoner, og bruker et skriptspråk. D.v.s. at all kode må tolkes hver gang den kjører. Det er velkjent at det er en performance hit ved å kjøre tunge beregninger i Matlab, men det er veldig lett å lage noe som går over natten der, så en skikkelig speed-up av Matlab ville vært kjærkomment for de fleste brukere.

 

Matlab er essensielt et bibliotek (med et pent brukergrensesnitt), bibliotekene som følger med clearspeed er ment for programmering i C, og inneholder antagelig de mest brukte vektor og matriseoperasjoner, samt kanksje noe litt mer sammensatt slik som FFT. Kompilator følger med. Faktisk er Matlab programmert i C. Likevel ser jeg ikke for meg at Clearspeed kan brukes sammen med Matlab, har heller ikke sett noe informasjon som tyder på det.

 

Hvert innstikkort har 96 prosesseringsenheter, med fire innstikkort gir dette bortimot 400 operasjoner som skal gjøres parallelt for å utnytte disse. Det er noen saftig store vektorer man skal håndtere for å utnytte dette. Med tunge floating point beregninnger er det dog ikke uvanlig å ha matriser som har 400x400 elementer eller flere, så helt urealistisk å få utnyttet store deler av kapasiteten er det ikke, burde gi en rimelig heftig ytelse ved bruk av FORALL kommandoen (unnskyld, det er jo Fortran, merkelig at de ikke har støtte for Fortran, burde være en smal sak når de har det for C).

 

Når det gjelder ytelse pr. watt er dette trivielt (eller pr CPU for den saks skyld). Cray'en har like mange innstikkkort, men flere prosessorer, værre er det ikke. Kortene står for det grøvste av Gflops, og bruker lite strøm. Det har ingenting med xeon kontra opteron å gjøre.

Endret 26. september 2005 av Del

[Codename_Paragon]

OK dette er egentlig en typisk Cell/Aeigia (eller hva den PPU utvikleren nå enn heter)  løsning. Det er massivt parallelt og har typisk de samme trade-off's som andre parallelle løsninger; masse teoretisk ytelse og utnyttelsesgrad som varierer sterkt med applikasjon.

Er PhysX fra Ageia såpass godt beskrevet offentlig at en vet det virkelig er en massiv parallel løsning?

[Del]

Sjekket opp Clearspeed litt, det ser ut som om de støtter både C++ og Fortran (i tillegg til C), selv om de bare oppgir å levere C kompilator. Det er jo selvfølgelig mulig de bare linker opp bibliotekene når det kodes i C++ eller Fortran, og det er sannsynligvis kun bibliotekene som blir kjørt på innstikkortene. Må også trekke tilbake antagelsen om Matlab/Mathematica støtte, de har visst demonstrert dette på en messe (uten at de oppgir å levere det til kunder):

http://www.d-silence.com/headlines/64-bit%...processor/21272

Hvordan de har gjort det vet jeg ikke (kanskje en patch av binær-filene, evt. et samarbeid med Wolfram og MathWorks). Linken gir oss også svar på hvor de har sine Gflops tall fra. Vi kan regne det som rimelig sikkert at de med vilje har valgt problemer som yter optimalt på arkitekturen, så de fleste kan nok bare drømme om å ha så godt egnede problemer (dersom tallene stemmer da). Selv nettstedet stusser på tallene oppgitt av Clearspeed (sjekk nederst på siden).

 

Var litt kjapp sist, ytelse og watt diskusjonen var mer nyansert enn hva jeg trodde ved første øyekast. At Cray systemet bruker mer watt pr. CPU har med systemet å gjøre slik som AJ påpeker, Cray putter endel snacks inn for å få meget god skalering til 12-way, og det koster selvfølgelig noen watt, men nå er vel neppe dette målt effekt, så hvis noen måler faktisk forbruk vil kanskje pendelen svinge tilbake. Interprocessor latency på Cray'en ved parallell programmering er oppgitt til imponerende 1,7 microsekunder. Husk da at Opteron sin integrerte kontroller maksimalt støtter 8-socket system, så her har Cray designet sitt eget system. Cray systemet leveres også med dual-kjerne, og 12 slike kan kobles sammen med totalt 288 2.2GHz Opteron kjerner, og en interprosessor latency på 2 microsekunder! Å sammenligne dette med en 2U Xeon er selvfølgelig ikke særlig relevant. Selv skaleringen til Itanium-system sliter med å slå denne, så det er fullt mulig å få Opteron-baserte systemer omtrent så kraftig man vil, men på kostnadssiden drar det seg til når Cray designer.

 

Når det gjelder Cell, er påstanden om at de ikke er konkurrent hentet fra Clearspeed selv. På spillmarkedet er dette riktig pr. i dag, men det er bare fordi Clearspeed ikke har klart/prøvd å selge seg inn der. Husk at Cell allerede har blitt nevnt av IBM som aktuell for HPC, så her er det nok konkurranse i fullt monn, og i dette segmentet har de meget like produkter (massiv parallellisering av flyttallsoperasjoner).

 

Jeg har ennå til gode å se noen relevante benchmarker av Clearspeed sine produkter, hvis noen har et link eller info er jeg meget takknemlig.

Endret 27. september 2005 av Del

[Del]

Er PhysX fra Ageia såpass godt beskrevet offentlig at en vet det virkelig er en massiv parallel løsning?

Det må det nesten være. 100x ytelse hvis den er seriell, ville gitt 100x2(SSE float)x3,8GHz=760GHz klokkehastighet. Det må være transistorer fra en annen verden.

[Del]

Cell kan også gjøre 64bit FP beregninger, men da synker en til ca halvparten av ytelsen.

Du mener en tiendedel av ytelsen?

[Anders Jensen]

Cell kan også gjøre 64bit FP beregninger, men da synker en til ca halvparten av ytelsen.

Du mener en tiendedel av ytelsen?

Mener å huske jeg så noen tall som lå litt under halvparten for 64bit fp. Mulig jeg husker feil. Om det er snakk om programvareemulering så er nok 10% mer realistisk ja.

[Del]

Fant dette i en link du ga:

http://www.blachford.info/computer/Cell/Cell1_v2.html

-256 GFLOPS (Single precision at 4 GHz).

-25 GFLOPS (Double precision at 4 GHz).

Men jeg må si at jeg er skeptisk til en kilde som ikke har kontroll på Amdahls lov. Likevel mener jeg å ha sett flere steder at SPE'ene bare har 32-bit float, og isåfall er vel en form for emulering nødvendig, med ditto ekstra sykluser for å dele og lappe sammen til 64-bit.

[Anders Jensen]

Den kilden var generelt litt ullen ja. Kanskje PPC kjernen støtter DP og at resten kommer fra emulering i SPE. Da er ikke 25 GFLOPS så utenkelig. Ser at SP oppgis til ikke å være IEEE kompatibel så de har vel tatt en rekke snarveier når det gjelder evaluering av korrektheten av resultatene i hw. Det virker i alle fall rimelig å annta at første generasjon Cell ikke er egnet til HPC.

 

Ellers er jo flernivå adresserbart minnehierarki, slik benytet i Cell med scratchpad til SPE, et interessant konsept. Vanskelig å programmere for er det definitivt, men ettersom kompilatorer og utviklings verktøyet generelt blir bedre tilpasset som kan det vise seg å være uhyre effektivt. Det er mye locality som er kjent ved compile time. Scratchpad i seg selv er vel ikke så innovativt, men om e klarer å lage en verktøypakke som virkelig klarer å utnytte dette så vil jeg si det er noe av det mest innovative som har skjedd i CPU verdenen på lenge.

Endret 28. september 2005 av Anders Jensen

[Del]

Absolutt, men jeg tror ikke noe før jeg ser resultater.Som du allerede har påpekt er massiv parallelisering pent på papiret, men har vist seg utfordrende i praksis. Det er i hverfall spennende tider med mye nytt på gang.

[Anders Jensen]

Absolutt, men jeg tror ikke noe før jeg ser resultater.Som du allerede har påpekt er massiv parallelisering pent på papiret, men har vist seg utfordrende i praksis. Det er i hverfall spennende tider med mye nytt på gang.

En bør være forsiktig med å forlange resultater for tidlig med dagens CPU situasjon. All den lavthengende frukta er plukket for lengst og de nye teknikkene har ofte massive fallgruver en må designe rundt før en får fullt utbytte av det. TLP har vi jo fiklet med i mange år nå og der er det fortsatt mye å lære (så mye at IBM mente det var smart å "gjenoppfinne" Connection Machine med sin BlueGene?). Scratchpaden i Cell kommer ikke til å bli noen dans på roser heller, men som sagt er det en ekstremt kraftig teknikk for å håndtere det stadig økende minne/cpu ytelsesgapet. Så har en jo også EPIC da.. nok et eksempel på et ting tar tid, mye tid.

 

Poenget er at skal en ha mulighet til å rykke fra resten i dette markedet så må en være villig til å satse tungt og være tålmodig. Intel har hatt IPF ute i 4-5 år nå og det begynner så smått å bli rimelig dreis på verktøyene og systemene som helhet, men de er fortsatt milevis etter på mange områder i forhold til mainstream ARM og x86. IBM er nå i ferd med å hive seg ut i et lignende løp. Det er forbausende mange likheter: markedsføringshype, verdensherredømme, teknologi ingen forstår hvordan en skal utnytte... De skal få noen heftige år foran seg med å innta markedet, men de har nok vært en smule smartere med valg av introduksjonsmarked. I alle fall er det slik det ser ut nå.

 

Jeg er forresten kjent med at det er et nytt ISA (ja faktisk!) som vil bli lansert om ikke lenge. Instruksjonssettet og den første implementasjonen av det er gode for 11 patentsøknader. Jeg snakker om AVR-32 (Atmel) utviklet på Tiller, Trondheim, Norway. Den er ikke annonsert ennå, men skal visst være en dårlig holdt hemmelighet i sine kretser. Kan dessverre ikke si mye mer en det. Det er snakk om å konkurrere med ARM-7/9 og Java samt multimedia ytelse står sentralt. Jeg vil si det i hovedsak var snakk om et typisk RISC ISA med noen smarte justeringer som gir en smule CISC følelse...

[Del]

Interessant, jeg har en bekjent som jobber med chipdesign der, så jeg får prøve å pumpe han for litt info. Hadde vært dritkult å fått en lokal killer.

[Anders Jensen]

Høres bra ut. De har NDA krav for å gi ut info på dette, men når de letter på sløret så hadde det vært kult å få vite enda flere detaljer.

Endret 29. september 2005 av Anders Jensen