Gå til innhold

Tyan satser på clustersystemer?


Anbefalte innlegg

Videoannonse
Annonse

For å være helt ærlig så tror jeg clustre er i ferd med å floppe slik vi ser de i dag. De vil nok klore seg fast i en del "embarrasingly parallel" HPC applikasjoner en stund til. Det som ser ut til å bli fremtiden er "big tin" sammen med clustre basert på blades. Kombinerer en disse to så har en et system som kan konfigureres til å løse nesten alle typer oppgaver. Blades gir mulighet for bedre tetthet, bedre administrasjon, lavere pris (i allefall om noe tid) samt raskere interconnects enn rack baserte clustre eller NOW løsninger. "Big tin" gir skalering på applikasjoner som er for vanskelige å skalere på clustre.

Endret av Anders Jensen
Lenke til kommentar

Spørs hva du mener med cluster, for meg er en samling blades koblet sammen med nic et cluster, også det som gjerne refereres til som "computer farm" kaller jeg gjerne et cluster. Så her tror jeg det er nødvendig med en klargjøring av begreper. For meg er overgangen til SMP når hver prosessor kan adressere alt minnet, men det er jo også en del glidende overganger, løsninger med veldig kjapp kommunikasjon mellom nodene.

Endret av Del
Lenke til kommentar

Det som betegnes som "big tin" er ofte også bygget opp på nøyaktig samme måte som klustre, siden infrastrukturen stort sett er nøyaktig den samme. Begrepet "superdatamaskin" er sånn sett blitt ganske løst etterhvert. Hvis man derimot definerer "big tin" som "superdatamaskiner" som flere 64+veis systemer som er bygget sammen av så er tendensen ganske klar - disse systemene blir i stadig større grad erstattet av rimeligere 4+veis systemer som er bygget sammen. Ref. salgstallene av Cray XD1 vs. SGI Altix.

Endret av snorreh
Lenke til kommentar
Spørs hva du mener med cluster, for meg er en samling blades koblet sammen med nic et cluster, også det som gjerne refereres til som "computer farm" kaller jeg gjerne et cluster. Så her tror jeg det er nødvendig med en klargjøring av begreper. For meg er overgangen til SMP når hver prosessor kan adressere alt minnet, men det er jo også en del glidende overganger, løsninger med veldig kjapp kommunikasjon mellom nodene.

Jeg tror nyansen kommer frem i min første post. Det var imidlertid et poeng at blade backplane er og kan bli mye bedre enn ethernet NIC. Typisk er det snakk om delvis proprietære eller fullt standardisert interconnect basert på Infiniband. De korte avstandene gjør det også lettere å holde høye overføringsrater.

Lenke til kommentar
Jeg tror nyansen kommer frem i min første post. Det var imidlertid et poeng at blade backplane er og kan bli mye bedre enn ethernet NIC.

Beklager, men den var ikke klar for meg, som du ser her:

http://www.intel.com/cd/ids/developer/asmo...cess/190795.htm

er en blade løsning med infiniband definert som cluster av Intel, så nettopp derfor ville jeg gjerne klarere. Da er det selve node kommunikasjon med nic som du ikke tror vil overleve? Der er det vanskelig å være uenig. Nic'en er jo uansett ment som internet kobling, som får en latency hit p.g.a. ethernet protokollen (den sender informasjonen i pakker, så da må det pakkes, sendes og pakkes ut etterpå), og vil sannsynligvis aldri gi like kjapp kommunikasjon som løsninger beregnet på nodekommunikasjon. Jeg regner jo også med at prisen på løsninger a'la infiniband går ned over tid. Vi har jo sett en drøss med løsninger fra forskjellige leverandører de senere årene for å speede opp kommunikasjonen. Den beste er kanskje SGI's NUMAlink, men QsNet og Myrinet er vel også verdt å nevne.

Lenke til kommentar
Jeg tror nyansen kommer frem i min første post. Det var imidlertid et poeng at blade backplane er og kan bli mye bedre enn ethernet NIC.

Beklager, men den var ikke klar for meg, som du ser her:

http://www.intel.com/cd/ids/developer/asmo...cess/190795.htm

er en blade løsning med infiniband definert som cluster av Intel,[]

Jeg definerer jo også blade med infiniband som Cluster i første post; "clustre basert på blades" ;)

Lenke til kommentar

Jeg leste vel litt fort, burde vel stoppet opp og tenkt når "slik vi ser de i dag" kom opp. For i dag kan vel neppe infiniband sies å være noen kjempesuksess. Det du spår en snarlig død er da det som gjerne kalles Beowulf clustre, som gjerne er basert på hyllevare komponenter (som jeg faktisk egenhendig bygde en god del år tilbake). Det fantastiske med disse er jo nettopp "hyllevare" konseptet, som gjør det fordømt billig å bygge, men dessverre ofte utfordrende å utnytte all prosesseringskraften. Nå er ikke performance hit'en så ille som man kanskje skulle tro ved bruk av Nic (de har blitt litt raskere siden jeg holdt på). For å danne seg et bilde skulle det være nok å se på top500.org lista vil jeg tro (har ikke noen annen link for hånden). Om løsninger som infiniband skal lykkes tror jeg masseproduksjon er et nøkkelord, akkurat nå er trenden at massiv I/O blir tilgjengelig på desktop, så det skulle ikke forundre meg om det dukket opp et "hyllevare" alternativ til nic'en som har både båndbredde og latency på topp, men det er selvfølgelig ren spekulasjon.

 

Det som derimot er klart, er at standard noder allerede nå begynner å få et anseelig antall CPU'er, fire, og snart kommer kanskje quad-core, slik at et dual hk kan være 8-way SMP, da er det jo naturlig å spørre for hvem HPC-behovet ikke er dekt ved en Beowulf-klynge. Man kan da ende opp med et rimelig smalt segment som trenger å kjøre enkeltjobber på flere enn 8 kjerner, og som samtidig vil ha stort utbytte av spesialløsninger som infiniband.

 

Når det gjelder "big tin", så viker det på meg som om dens dager er talte for HPC, og jeg kan vanskelig se for meg at de kommer tilbake, det er rett og slett for dyrt. Men de er jo rene drømmen for en lat programmerer.

Lenke til kommentar

Det fine oppi dette er at blade er i ferd med å bli standardisert og MMCOTS.

 

Jeg tror forøvrig du finner uhyre få ethernet baserte clustre på top500.org, men nå er jo denne lista basert på en benchmark som reflekterer teoretisk regnekraft for en applikasjon uten internode kommunikasjon. Vi snakker om skalering på 70% til 90%? helt opp til flere titusen prosessorer. Det er absolutt ingen virkelige problemer som skalerer så godt.

 

Når det gjelder "tig tin" så er disse faktisk i vinnen igjen og årsaken er nokså opplagt. Det er et stadig økende gap mellom båndbredde og tilgangstider. "big tin" interconnects løser ikke dette problemet men det utsetter det. Ultimat sett kan det nok aldri løses med mindre lysets hastighet ikke er maksimum hastighet for overføring av informasjon i romet. Google har for eksempel gått ut å slått fast at deres MMCOTS cluster teknologi ikke er egnet for deres fremtidige behov og at løsningen må ligge i retning av "big tin".

Lenke til kommentar

Sorry, jeg må lære meg å lese postene dine med lupe. Jeg trodde det var nettopp HPC du snakket om. Når vi er over på servere, så er kanskje bildet et annet. Skjønt google er bare en observasjon, og ikke mange har så stort behov. Må gå bort å ta en titt på top500 lista igjen, mente det var ganske så mange med nic når du kom et stykke nedover. Når det gjelder ytelsen ved skalering har jeg bare noen tall i hodet, men de gir jo ikke all verdens mening uten en sammenheng, uansett drøyt 50% ved nic, og drøyt 80% ved Numalink, de andre i sprer seg i mellom.

Lenke til kommentar

Om Google driver med HPC eller ikke er vel forsåvidt en definisjonssak. De er nokså spesielle. Er forøvrig enig i at rene "big tin" løsninger ikke nødvendigvis er en god HPC løsning da en ofte (men slettes ikke alltid) har veldig mye dataparallellitet som rimelig lett kan utnyttes på flere løst sammenkoblede noder. Dette er imidlertid mest applikasjonsavhengig. Mener jeg leste her for noen dager siden at SGI Altix systemene er grunnlaget for det eneste værmeldingssystemet som klarer å forutsi hvordan orkaner beveger seg. De andre modellene klarer ikke å modellere dette nøyaktig nok og bommer gjerne med flere titals mil. Så kan en jo spørre en hvilken som helst Amerikaner om det er verdt det å investere i slikt utstyr...

 

De skalerings tallene du oppererer med er meningsløse; "uansett drøyt 50% ved nic, og drøyt 80% ved Numalink, de andre i sprer seg i mellom." Det er ikke slik det fungerer. Om disse tallene f.eks gjelder for 32 2-way noder (noe som ville være ønsketenkning i mange tilfeller) for et gitt problem så kan du være rimelig sikker på at begge systemene vil slite med å generere fremgang på linje med selv en enkelt CPU om du fordeler applikasjonen på ett tusen noder for ikke å si ~131k (BlueGene) prosessorer. Negativ skalering vil inntreffe og en ender til slutt opp med et system som bare står å venter på seg selv uten å få gjort noe som helst.

Endret av Anders Jensen
Lenke til kommentar

En ting til jeg vil nevne. Det snakkes så varmt om dual og multicore prosessorer og mens jeg i høyeste grad hilser DC velkommen på mindre maskiner, særlig de med kun en kjerne per i dag, så er dette ikke nødvendigvis noen fordel i det heletatt for større systemer det være seg "big tin" eller clustre hvor antallet kjerner allerede har vært "mange nok og vel så det" i flere år. Multicore er på mange måter å rygge inn i fremtiden. Selv har jeg jo vært rimelig ivrig på vegne av IPF fordi jeg mener det er en teknologi som i noe grad kan utsette _behovet_ for flere kjerner. Må imidlertid si jeg er i ferd med å få et nytt hjertebarn. Det er ikke snakk om Cell, selv om jeg må si jeg stadig blir mer begeistret for den teknologien også.

 

AMD's IA-64 and X86 killer

 

Ville vel ikke vært for rask til å trekke inn AMD her, men det er nå enn navnet på denne RWT tråden så jeg skal ikke underslå det. ;)

Endret av Anders Jensen
Lenke til kommentar

Jada, tallene har ikke all verdens mening uten sammenheng, jeg får prøve å hoste frem sammenhengen. Omtrent like meningsløst som orkaneksempelet ditt vil jeg si. Det problemet har ingenting med presisjon på float å gjøre, kun regnekraft, m.a.o. hvor fint grid du har tid til å regne på, og kan paralleliseres som bare det, selv om det er langt fra "embarassingly parallel", så med tilsvarende investering i Beowulf cluster (ville blitt et sinnsvakt antall CPU'er...) ville man kunne forutsagt orkanen ennå bedre. Du får sjekke opp begrepet "domain decomposition", som gjerne brukes for å parallelisere denne typen problem. Uansett utstyr, ville jeg ikke følt meg for trygg på den orkanen. Det er gjerne større usikkerhet knyttet til modellen (du bommer selv om du har uendelig regnekraft).

 

EDIT: Når det gjelder definisjon av HPC, så er dette et viktig poeng, og jeg må innrømme at jeg typisk tenker på vitenskapelige implementasjoner her, men du har et poeng, high performance kan vel romme mer, så HPTC er vel et mer passende begrep. Men begreper har jo en tendens til å leve sitt eget liv, så det kan nok være fler enn meg som bruker HPC begrepet på den måten.

Endret av Del
Lenke til kommentar

Fikk endelig en sammenheng til de tallene jeg bablet om, husken er ikke alltid på topp:Good "old" wikipedia to the rescue

NUMAlink offered an average of 84% efficiency on the TOP500 list [1], while QsNet and Infiniband reached 75%, Myrinet 63%, and 59% for gigabit ethernet

Mens jeg rotet rundt kom jeg også over denne litt bastante formuleringen:wikipedia strikes again

As technology advances, the differences in performance between loosely coupled and tightly coupled multiprocessor systems will continue to shrink. When 10gb Ethernet becomes commonplace, performance differences will become a non-issue and physical size may become the only justification for tightly coupled systems.

Nytt hjertebarn... Dette må jeg sjekke ut.

Lenke til kommentar

Forøvrig helt enig i at lite kan erstatte økt single core ytelse.

 

Fikk tatt en titt på det nye vidunderet, mange spennende løsninger. At de får designet noen prototyper tyder på at de har kommet et godt stykke, så det blir veldig spennende. Spørs om jeg må pløye igjennom noen pdf dokumenter for å få litt innsikt i detaljene. Vet du om det er patenter knyttet til arkitekturen?

Endret av Del
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...