250 halve GFLOPS

Om supercomputere i almindelighed og den her i særdeleshed.

(Andet indlæg i min real-time ESO/ELT-WFRTC føljeton, første indlæg finder i her)

Hvad har en supercomputer med et spejl at gøre ? Er det spørgsmål jeg oftest mødes med om WFRTC projektet og svaret er at computeren skal krølle spejlet til perfektion.

Luften over jorden er urolig, selv hvis man finder det mest perfekte sted i en ufremkommelig stenørkenet sted i det sydlige udland.

Derfor består et af spejlene i ESO's ELT teleskop af flere tusinde små spejle, der af 6350 "aktuatore" kan bringes i form som lige nøjagtigt det spejl der kompenserer for at en klump varm eller kold luft blæser hen over teleskopet nogle kilometer højere oppe.

For at vide hvorledes spejlet skal krølles, observerer man nogle egnede "guidestars", (Ikke Den Lede Stjerne samledigteren skrev om), og hvis ikke der er nogen der egner sig, laver man selv nogen med laserlys.

Med robotarme følger en Shack Hartmann Wave-Front-Sensor disse "guidestars" og måler hvor meget lyset er blevet forstyrret undervejs igennem atmosfæren og derefter er det nogenlunde simpel matematik at udregne hvor meget spejlet skal krølles for at kompensere.

Problemet er at WFS'erne ikke sidder i midten af det optiske system men ude i kanten og som om det ikke var nok, roterer robotmekanismen når teleskopet følger et eller andet objekt på himlen, så der er noget geometri der skal håndteres.

ESO/ELT har flere "observation modes", men den numerisk største er dimensionsgivende og den vi roder med:

Input fra Wavefront sensoren er 10008 float værdier.

Først skal koordinaterne transformeres så de passer med spejlet. Det er en multiplikation med en tyndt populeret 10008x10008 matrice, hvor matricen ændrer sig ca. en gang i sekundet.

Dernæst skal der interpoleres for de ståldragere og andet isenkram der skygger for bestemte dele af teleskopet. Det er en anden tynd 10008x10008 matrice, som heldigvis er konstant.

Endelig skal de nødvendige korrektioner distribueres til de 6350 aktuatorer med en 10008x6350 fuldt populeret men konstant matrice.

Og det skal vi gøre på 1 millisekund, 500 gange i sekundet.

Niels som har styr på de dele siger at det kræver omkring 250 GFLOPS

Den overordnede plan er at input data kommer som 5 jumbo ethernet pakker via multicast og de fem compute-nodes modtager dem samtidig og kaster 3 cores efter registreringen og interpolationen, som altså udføres fire gange mere end nødvendigt, men til gengæld sparer det os for en kommunikation imellem computerne.

Når interpolationen er overstået, bliver ca. 44 cores sluppet løs på den store matrice og når de er færdige sender hver maskine en ethernetpakke med 1/5 af resultatet.

Derefter har vi et millisekund til at trille tommelfingre, inden den næste byge pakker ankommer.

At vi idler i 50% af tiden reducerer naturligvis elregningen og mindsker muligvis problemerne med at køle computerne i 3km højde.

Men en del af opgaven går ud på at se hvor meget vi kan presse citronen: Hvis vi kan regne hurtigere eller oftere, er der en konkret men sikkert marginal videnskabelig gevinst i form af skarpere billeder af universets barndom.

Det siger sig selv at vi har rigtig meget kig på det der millisekund: Hvorfor bruge 250 halve GFLOPS når man har 250 hele GFLOPS ?

phk

Kommentarer (21)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mads Johansen

Jeg kan ikke dy mig. Ifølge qwikmark ( http://www.vtaskstudio.com/vista.pl?action=download&link=qwikmark.exe ) har min i5 Sandy bridge 65 GFLOPS, programmet bruger kun 1 kerne (af 4), så 65*4 = 260 Gflops.

Der er naturligvis noget jeg ikke har forstået siden man ikke "bare" smider en laptop til at lave de beregninger. Jeg glæder mig til at blive klogere :)

  • 0
  • 0
Casper Bang

Hvis i har CPU tilrådighed, og problemet er I/O, hvorfor så ikke kigge på en rudimentær men hurtig form for komprimering? Jeg forestiller mig at der må være en pæn sjat af redundans i bitmappet (RLE?), ligesom entropien nok ikke stiger voldsomt imellem hver matrice (send delta frem for aktuel værdi)?!

  • 0
  • 0
Carsten Frigaard

Hvis du havde haft problemer med båndbredde (f.eks. ikke anvendt multicast) kunne en alternativ løsning være brug af en enkelt PC med en eller flere GPU'er.

Et sæt af grafikkort kan leverer i omegnen af de 250 GFlops, dog med alle mulige forbehold (problemer med dobbelt præcision floats, properitær library, kode virker kun på GPU'er, GPU kode der er svær at debugge og optimere, osv.).

Et interessant aspekt er dog effektiviteten af GPU'erne med hensyn på effektforbruget (GFLOPS/watt), hvor en enkelt maskine med et par GPU'er er mere effektiv en en lille hær af PC-noder.

  • 0
  • 0
Casper Bang

I/O båndbredde er vores mindste problem: Hver datasæt er omkring 40kB, vi sender 500 i sekundtet = 20MB/sec


Men hvad er så egentlig jeres største problem? Vi har fået afklaret at det hverken er CPU eller I/O, hvad er der så snart tilbage tænker jeg (og sikkert flere)?

Og betyder de 40-45KB at der er tale om 32bit floating points, for dét virker da godt nok som et væsentligt spild af de resterende (32-48) LSB'er i registrene.

  • 0
  • 0
Carsten Frigaard

GPU'er har været prøvet og det var ingen success.

På grund af...

1) den tyndt populerede matrice give en irregulær algorithme, som er svære at bruge GPU'er på?

2) GPU'erne har ikke båndbredde nok på PCI bussen?

3) Double præcision kan bare ikke kører hurtigt nok på GPU'en, eller SFU har båndbredde problemer?

4) Det crasher bare hele tiden på GPU'erne?

5) Det er fuldstændingt umuligt at anvende GPU compiler toolchainen midt i vores kode?

6) Noget helt andet?

Eller måske en kombination af 1-6...? Jeg vil gætte på 1 og 4.

  • 1
  • 0
Jacob Larsen

Har I gang i en eller anden form for Real-Time mode i FreeBSD kernen? Når latency kravet ligger nede på 1 millisekund, så betyder det jo en del hvis f.eks. kernen bruger 100us på at behandle interruptet fra Ethernet kortet. Lige som det jo betyder ret meget hvis der går tid inden man får lov at starte sin processering. Eller der polles måske på Ethernet kortet?

Jeg kan vel egentlig godt regne med at det hele kører i kernelspace på maskinerne? Turen frem og tilbage til userspace vil jo nok være en væsentlig del af den tilgængelige tid.

Har de mindre RTOS kerner været overvejet? E.g. Nucleus/ThreadX osv? Eller der kommer vi måske ud på et område hvor man først lige skal skrive hele driver stacken selv? Men ellers ville de jo være interessante fordi de netop kan give meget lav latency til den slags specialiserede opgaver, hvis man sætter det rigtigt op.

  • 0
  • 0
Morten Kristiansen

Er der tale om double eller single precision? Slog lige tal op for en FPGA. En af de store fra Altera har 1755 multipliers der kører 450 MHz, dvs. knap 800 mia. multiplikationer, 27x27 bit. Der er selvfølgelig en række forhold der påvirker, men umiddelbart lyder det overkommeligt i en enkelt kreds.

  • 0
  • 0
Anders N. Christensen

Åh jo. Jeg mente skam også som næste projekt, så I havde noget at bruge hullet på et millisekund til. Først få skidtet til at virke, så kan man lege. Kan da også godt være, at det alt for tidligt til den slags. Ikke desto mindre: Hvis du har kendskab til et sted hvor man kan hente målte eller simulerede bølgefronter, kunne det da være sjovt at kigge på.

  • 0
  • 0
Poul-Henning Kamp Blogger

National Instruments har rodet med FPGAer til den her slags opgaver, men ESO har ikke gode erfaringer med langtidsdrift af den slags hardware og de har rigtig meget erfaring med den slags hardware.

  • 0
  • 0
Morten Kristiansen

Det undrer mig lidt, for FPGA bliver brugt i telefonnetværket i rå mængder og de bryder sig normalt ikke om at skulle skifte kort i tide og utide; men der kan selvfølgelig være andre forhold der gør sig gældende. Jeg har heller aldrig hørt det skulle være ustabilt. Har du et projektnavn jeg kan google?

  • 0
  • 0
Poul-Henning Kamp Blogger

I telefonnettet er der tale om seriøs serieproduktion og reservedele er til at skaffe. I ESOs tilfælde er det typisk unika og det har de dårlige erfaringer med i det lange løb, ikke mindst hvis der skal laves noget om i "software".

Vores bud på opgaven var at gøre det med normale PC'er uden for meget magi og en ren open source løsning.

  • 2
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize