Uenighed om dansk supercomputercenter

...så er konklusionen, at Danmark bør have et supercomputercenter. En af årsagerne er, at der mangler regnekraft, men også at Danmark går glip af EU-midler

går glip af EU-midler??? ....haha, Jep en dårlig undskyldning for at man vil prøve Crysis på storskærm med max opløsning.

#1, Renderet via realtime raytracing vel at mærke. ;)

Vi har da DASK.. det må være fint.. ;)

dmi kunne godt bruge en hardware opdatering IMO... ikke at de ikke gør det godt nok, men comon... alt kan forbedres

Jeg tror det er rigtigt at mange forskere vil foretrække (mindre) supercomputere på de enkelte universiteter. Jeg tør slet ikke tænke på alt det papirnusseri man sikkert ville kræve af folk for at de kan få cpu-tid på et fælles cluster.

Altså med den de har flækket sammen i japan, hovedsageligt af GPU'er, så kan man da forestille sig at noget lignede ville være smart i Danmark hos de enkelt forskningsafdelinger.

Som #5 siger kan jeg også godt tænke mig at det ville være et mareridt at book tid. Så hellere mindre og dedikerede enheder rundt omkring.

Nu har jeg ikke ret meget forstand på supercomputere, men kan de ikke bare koble de nuværende supercomputere rundt omkring i landet sammen, og dele de særligt ressourcekrævende opgaver ud i mellem dem? Hvad er fordelen i at centralisere computerkraften? Stilles der krav om at hardwaren står samlet ved tildelingen af EU-midler?

#5,6: Fik tiltusket mig et login til Sun HPC systemet på DTU for nogle år siden, tror der var 2-400CPU'er dengang (det var inden de blev stålet ;))

Jeg fil ikke arbejdet så meget med det, men det var ret enkelt - det program der skal køres pakkes ind i en slags shell script hvor man definerer nogle få parametre så som path til de filer som stdout og stderr redirectes til og så submitter man scriptet som bliver stillet i kø til at blive kørt.

- Og så får man en email når det har kørt. Afhængig af hvor mange striber man har på skuldrene har logins så forskellig prioritet, så køen bliver prioriteret derefter.

Altså intet papirnusseri eller noget som helst.

(Og ja, det føles lidt fedt at fyre op for f.eks. 50CPU'er på en gang :D)

vestas har en på top 250 spec 1344 kerner på hver 3.33Ghz, 2760GB ram
25TB diskplads


og dmi får eller har Cray XT5 som skulle blive nr 54

så det er noget fis at de skriver der ik er nogle på top 100

Hvorfor får de ikke lavet en opgradering af BOINC som bruger det den der DTU student har opfundet. Noget virtualisering som ikke taber regnekraft?

Så kan de jo bare smide det på alle deres computere over det hele.

Wupti så har de da fået lavet en super computer.
:D

#8: Ja, men tror du ikke det ville være væsentligt sværere at få adgang til et fælles cluster? Det er jeg ret overbevist om.

Min pointe var jo lige netop, at det formentligt er meget nemmere at få adgang til en cluster på samme institut som én selv.

#9: Men nu er det jo ikke regnekraft der er tilgængeligt for danmarks universitets-ansatte forskere.

. .

Anders Feder (7) skrev:

Nu har jeg ikke ret meget forstand på supercomputere, men kan de ikke bare koble de nuværende supercomputere rundt omkring i landet sammen, og dele de særligt ressourcekrævende opgaver ud i mellem dem? Hvad er fordelen i at centralisere computerkraften?

Fordelen ved at have dem på samme lokalitet er, at man kan opnå mere effektiv kommunikation imellem dem. Det gælder både latens og båndbredde. Groft sagt kan beregningsopgaver indeles i fire klasser efter om deres performance er afhængige af hver af de to parametre.

Der findes opgaver der er trivielle at parallelisere fordi de stort set ingen krav stiller til kommunikation, f.eks. brute forcing af krypteringsnøgler er trivielle at parallelisere. Andre opgaver som f.eks. vejrberegninger stiller langt større krav til kommunikationen.

Nogen gange må man indgå kompromiser, f.eks. kan der være situationer hvor man simpelthen vælger at udføre samme beregning på flere CPUer for at være mindre afhængig af kommunikation.

Laver man udregninger på vejret kan man indele verden i områder, hvor hver CPU beregner et område. Men på kanten mellem to områder vil de to CPUer så skulle kommunikere fordi vejret indenfor det ene område påvirker det andet og omvendt.

I stedet for at vente på kommunikation efter hvert skridt af beregningen, så kan man have et overlappende område som beregnes af begge CPUer. Det kræver mere CPU tid at udføre samme beregning, men det bliver alligevel hurtigere fordi de ikke skal stå så meget og vente på data fra hinanden. Selvfølgelig skal de stadigvæk kommunikere, fordi de enten langsomt vil få ukorrekte data langs kanten af det område de beregner eller må indskrænke det område de beregner fordi de ikke har data nok til at beregne langs kanten. Når der ikke længere er noget overlap mellem de områder som begge CPUer har beregnet "korrekt" er de nødt til at vente på data fra hinanden. På den måde er man mindre følsom overfor latens, men man skal bruge lidt mere CPU tid og lidt mere båndbredde.

Er CPUerne placeret langt fra hinanden er det umuligt at opnå lige så lave latens, og det er dyrt at opnå høj båndbredde. Og det er ikke alle beregninger hvor det er rentabelt at kompensere for høj latens. 10Gbit/s mellem to lokale i en bygning er billigere end 10Gbit/s mellem Århus og København.

Der er også fordele ved at man selv er tæt på det cluster man udfører beregninger på. Men det er ikke nært så vigtigt som at CPUerne i clusteret er tæt på hinanden. Kommunikationen mellem clusteret og omverdenen (brugerne) er ikke så omfattende som den der foregår indenfor clusteret, men båndbredde og latens har stadig lidt at sige (omend Danmark er ikke stort nok til at latens har nogen betydning for den del af det). Selvfølgelig er der også lidt mindre risiko for at forbindelsen bliver afbrudt hvis man er tæt på clusteret, men jeg tror ikke det er noget som man bekymrer sig om i den her sammenhæng.

En ulempe ved at pladsere alle maskinerne på et sted er at man så har et single point of failure. Man kan meget nemmere risikere at miste alt sin computerkraft på samme tid. Men jeg tror ikke mange af disse opgaver reelt kan flyttes mellem clusters i dag, så om de alle går ned på samme tid eller på forskellige tidspunkt kan nok være lidt ligegyldigt.

Et langt større problem er, at for at kunne køre beregninger over de forskellige maskiner skal de ikke blot være på samme lokalitet, de skal også faktisk forbindes til hinanden med et samlet netværk, og der skal være noget fælles administration og jobafviklingssystem. De ændringer vil betyde er der ikke længere er tale om forskellige clusters, men et enkelt cluster.

At gøre det hele til et cluster vil bidrage yderligere til at gøre det til et single point of failure, men det vil også introducere administrative vanskeligheder. Forskellige opgaver stiller forskellige krav, så kan alle disse institutioner blive enige om, hvilken arkitektur der skal anvendes? Og kan de blive enige om hvem der skal administrere det? Og kan de blive enige om hvordan resourcer skal bruges? Fordeling af resourcer bliver vanskeligere når der er flere brugere som i mindre grad har interesse i hinandens jobs. Med et lille antal brugere kan en gentleman agreement ofte være tilstrækkeligt, men et stort cluster der skulle dække hele landets behov ville kræve enforcement af resource fordeling.

I øvrigt er det en forudsætning for at man overhovedet kan få glæde af at samle resourcene, at man har brug for flere resourcer på nogle tidspunkter end på andre, og at de forskellige brugere har brug for resourcerne på forskellige tidspunkter. Hvis man har brug for den samme mængde resourcer hele tiden, så er det mere cost effective at have sit eget cluster.

Stilles der krav om at hardwaren står samlet ved tildelingen af EU-midler?

Aner det ikke.

#14 jeg har ratet dig informativ men har ærlig talt ikke overskuddet til at læse det hele men tænkte at siden du har skrevet så meget så er det nok noget du brænder for XD

og sværger skal nok få taget mig sammen til at læse det når jeg står op :P

Kan godt være jeg er rimelig stiv, men jeg ville nok lægge mine penge hos dem der satser på den decentraliserede model.

Der er alt for meget bøvl i en centraliseret supercomputer og det er alligevel kun ganske få programmer der kan skrives så parallelt at det reelt betyder ret meget at have adgang til 1000 fremfor 50 CPU'er eller 4 for den sags skyld.