SGI viser Altix 4000

[ketter]

Det største problemet for de dyreste løsningene så langt, er kanskje at de har blitt utdatert altfor fort til å forsvare investeringen. Her hjemme har vi Notur, som kostet en del millioner å få på plass, hvor mye den siste oppgraderingen kostet vet jeg ikke, men billig var det neppe. En standard x86-64 kjører i dag sirkel rundt MIPS prosessorene i Notur.

 

Skulle gjerne visst hva japanerne skal med 13TB, jeg tror neppe de kjører shared memory kjøringer som utnytter alt det minnet, bare allokering av alt det minnet vil være en tidkrevende operasjon, og for partikkelfysikk skal det gjerne regnes noe også, så jeg tør ikke tenke på hvor tidkrevende en kjøring som sluker 13TB vil være. Men de er visst tålmodige i Asia... Hvis man ikke trenger alt minne til en kjøring, har man heller ikke bruk for så mye shared, så det kan nok tenkes at en x86-64bit wannabe kunne vært aktuelt også der, men det er ikke til å skyve under en stol at SGI sin NUMA er meget godt egnet for skalering, Itanium egner seg for flyttall, og shared memory gjør livet mye mer behagelig for programmeren.

5154758[/snapback]

 

OK. Et par ting her. De dyreste løsningene holder lengre enn de billigere. Statoil har f.eks. en 32CPU's SGI maskin fra 1996 som fortsatt er en av deres operative servere.

En standard pentium ER raskere enn en MIPS, ja. Men NOTUR's maskiner har hhv. 512 CPU'er og 384 CPU'er i SSI (Single System Image), og applikasjonene som utnytter dette går bra. Husk: Det er applikasjonsytelse som teller, ikke teoretisk ytelse (FLOPS).

 

Du skal ikke se bort ifra at de faktisk kjører over 10 TB i shared memory. Dette er jo faktisk den største styrken til SGI fremfor cluster... Allokeringen vil ta litt tid, men det er nok begrenset av disk-systemet som du henter data fra...ikke maskinen's evne til å allokere minne.

En annen ting som er greit å tenke på i en slik sammenheng:

En maskin blir ofte brukt til flere typer jobber. Si de har en jobb som tar f.eks. 5TB, og en annen som bruker 4 TB. Så kommer det inn en hastejobb som bruker 4 TB til... Denne skal bruke alle CPU'ene, og har en høyere prioritet enn de to andre jobbene. Det som da ligger i minnet må da skrives til disk (swap) først, for så å laste inn data fra den nye jobben. Når denne er ferdig må data fra den ventende jobben lastes opp igjen fra swap til minne før den kan fortsette.... Dette tar tid. Har du da nok minne vil du slippe slike dilemma, og beholde data i minnet mens hastejobben kjører. I en slik sammenheng må du huske at mange jobber (beregninger) faktisk kjører i flere dager (og av og til uker) på flere hundre CPU'er.

[ketter]

Trur ente det er no i veien med det integrerte NICet, sannsynligvis bare no jeg burde ha gjort som jeg ente gjør... Dessuten trenger Octane en PCI-"boks" for å bruke PCI-kort, den har jeg ente.

 

 

Det er noe liknende det jeg har forsøkt før, men andres tanker, råd og vink er alltid nyttige. Det kan jo tenkes at jeg ser på dette her i ettermiddag 

5156541[/snapback]

 

Det integrerte NIC'et har litt problemer med autonegotiation.

Har du switch med muligheten for det ville jeg låst porten til Octan'en til 100Mb Full Duplex. Så gjøre det samme på Octanen i PROM:

 

setenv ef0mode F100

 

Har du HUB, eller ikke mulighet for å låse switch ville jeg låst til Halv Duplex (H10 eller evnt. H100). 10 Mb Halv er det tryggeste...

 

Har du norsk keyboard ? -> setenv keybd NO

 

Når alt er fikset kan du boote Octanen som foreslått, eller skrive "exit" og komme tilbake til oppstartsmenyen. Der kan du velge "Install system software" og "Install from remote directory".

[olefiver]

Det integrerte NIC'et har litt problemer med autonegotiation.

Har du switch med muligheten for det ville jeg låst porten til Octan'en til 100Mb Full Duplex. Så gjøre det samme på Octanen i PROM:

 

setenv ef0mode F100 

 

Har du HUB, eller ikke mulighet for å låse switch ville jeg låst til Halv Duplex (H10 eller evnt. H100). 10 Mb Halv er det tryggeste...

5157137[/snapback]

Har faktisk maskinene direkte kobla sammen over kryssa TP.

LAN/internett <----> Linux-maskin <----> Octane

Pga begrensninger med hvordan nettverket, for tiden, er lagt opp rent fysisk (maskiner i annen etasje, router/switch i kjeller, ingen hub, kun en TP-kabel lang nok).

[Del]

OK. Et par ting her. De dyreste løsningene holder lengre enn de billigere. Statoil har f.eks. en 32CPU's SGI maskin fra 1996 som fortsatt er en av deres operative servere.

En standard pentium ER raskere enn en MIPS, ja. Men NOTUR's maskiner har hhv. 512 CPU'er og 384 CPU'er i SSI (Single System Image), og applikasjonene som utnytter dette går bra. Husk: Det er applikasjonsytelse som teller, ikke teoretisk ytelse (FLOPS).

Vet du hvor mange MIPS baserte systemer Statoil har faset ut de siste årene? Vet du hvorfor serveren du sikter til fortsatt er i bruk? Hvilke av applikasjonene på Notur er det du sikter til?

 

Du skal ikke se bort ifra at de faktisk kjører over 10 TB i shared memory. Dette er jo faktisk den største styrken til  SGI fremfor cluster... Allokeringen vil ta litt tid, men det er nok begrenset av disk-systemet som du henter data fra...ikke maskinen's evne til å allokere minne.

Jeg siktet faktisk til allokeringen, men det var ment som en humoristisk bemerkning. På en arbeidsstasjon tar det kun minutter å allokere 16GB, husker bare jeg ble forbauset første gang jeg så hvor lang tid allokeringen tok med så mye minne, men du har selvfølgelig rett, det må et seriøst disk-system til hvis slike mengder data skal lastes opp i rimelig tid. For de fleste applikasjoner går det også en grense for hvor stort problem (les: hvor minnekrevende) du kan løse på et gitt antall CPU'er innenfor rimelig tid (les:uker). For typiske problemer fra partikkelfysikk har jeg vanskelig for å se for meg at japanerne skulle hatt behov for så mye, men de har jo kjøpt det, så jeg tar kanskje feil. Jeg tror vel vi snakker om et meget smalt segment her.

En annen ting som er greit å tenke på i en slik sammenheng:

En maskin blir ofte brukt til flere typer jobber. Si de har en jobb som tar f.eks. 5TB, og en annen som bruker 4 TB. Så kommer det inn en hastejobb som bruker 4 TB til... Denne skal bruke alle CPU'ene, og har en høyere prioritet enn de to andre jobbene. Det som da ligger i minnet må da skrives til disk (swap) først, for så å laste inn data fra den nye jobben. Når denne er ferdig må data fra den ventende jobben lastes opp igjen fra swap til minne før den kan fortsette.... Dette tar tid. Har du da nok minne vil du slippe slike dilemma, og beholde data i minnet mens hastejobben kjører. I en slik sammenheng må du huske at mange jobber (beregninger) faktisk kjører i flere dager (og av og til uker) på flere hundre CPU'er.

Dette er et godt poeng, og kan rettferdiggjøre til en viss grad et stort minnebehov, nå har jeg likevel problemer med å se for meg jobber som krever hundrevis av CPU'er få lav prioritet, finnes kanskje rimeligere måter å håndtere dette på. Husk også at på et distributed memory system er swappingen til disk ekstremt parallellisert gjennom at hver node gjerne har egen HD.

Endret 15. november 2005 av Del

[ketter]

Vet du hvor mange MIPS baserte systemer Statoil har faset ut de siste årene? Vet du hvorfor serveren du sikter til fortsatt er i bruk? Hvilke av applikasjonene på Notur er det du sikter til?

Pass

Men jeg kan anta at det er fordi de ikke har maskiner til å erstatte denne for øyeblikket ?

De har jo handlet cluster, men ikke alle applikasjoner er skrevet for distribuert minne...

Ren gjetning selvsagt, jeg har bare hørt at de hadde en.

Tenker ikke på noen spesielle applikasjoner. Poengterer kun på generellt grunnlag at et resultat fra en standard benchmark, eller et ytelsetall ikke nødvendighvis sier noe om ytelsen til en applikasjon... Det kreves ganske mye tuning og kompilering til for å få best mulig resultat.

 

Dette er et godt poeng, og kan rettferdiggjøre til en viss grad et stort minnebehov, nå har jeg likevel problemer med å se for meg jobber som krever hundrevis av CPU'er få lav prioritet, finnes kanskje rimeligere måter å håndtere dette på. Husk også at på et distributed memory system er swappingen til disk ekstremt parallellisert gjennom at hver node gjerne har egen HD.

Ja, jo. I et forskningssenter er det nok en del jobber som kjøres med relativt lav prioritet fremfor andre, men det er et litt ekstremt eksempel jeg dro frem

Og, ja; cluster har sine fordeler. Enkelte jobber vil da gå like raskt eller raskere på et cluster enn på et SSI, og visa versa. Jeg håper uansett at vi vil se selsakper som SGI, Sun og IBM fortsette med utviklingen sin, uansett om kundene presser prisene ned. Håper ikke cluster konkurrerer ut dyrere løsninger...

[olefiver]

Vet du hvor mange MIPS baserte systemer Statoil har faset ut de siste årene?

Ville bare bemerke at Octanen min kommer fra Statoil.

Så det er ihvertfall en MIPS maskin

Endret 15. november 2005 av olefiver

[Del]

Men jeg kan anta at det er fordi de ikke har maskiner til å erstatte denne for øyeblikket ?

De har jo handlet cluster, men ikke alle applikasjoner er skrevet for distribuert minne...

Mye vil ha mer og fanden vil ha fler, tilsynelatende blir det aldri nok regnekraft. De fleste store tunge applikasjoner blir over tid optimalisert for distribuert minne, det er en konsekvens av at kluster er mye billigere enn "big tin". Men slikt tar tid, og er krevende. For fremtiden (i den grad det begrepet kan brukes i databransjen) ser det for meg ut som om det også vil være et behov (om enn mye mindre enn før) for delt minne, og dyre løsninger fra IBM, SGI, Cray, om ikke annet så for software som ikke er modent nok til å utnyttes på vanlig klynge. I en utviklingsfase for en tung software vil jeg si at tilgang til en "big tin" er drømmesituasjon, spørsmålet blir hvem som skal plukke opp regninga. Nå finnes det sikkert problemer som vanskelig lar seg distribuere, jeg er nok litt farget av at alt jeg har sett og trodd i den retning har blitt gjort til skamme av nye implementasjoner som har skalert fantastisk.

Tenker ikke på noen spesielle applikasjoner. Poengterer kun på generellt grunnlag at et resultat fra en standard benchmark, eller et ytelsetall ikke nødvendighvis sier noe om ytelsen til en applikasjon... Det kreves ganske mye tuning og kompilering til for å få best mulig resultat.

Klar over det, jeg har kjørt ganske mange CPU-timer på Notur, og siktet til egen erfaring på typisk slike applikasjoner du antagelig siktet til.

Endret 15. november 2005 av Del

[ketter]

Vet du hvor mange MIPS baserte systemer Statoil har faset ut de siste årene?

Ville bare bemerke at Octanen min kommer fra Statoil.

Så det er ihvertfall en MIPS maskin

5159265[/snapback]

 

Hvor mye måtte du gi for Octane'en da ?

Spec ?

Er det Octane (grønn) eller Octane2 (blå) ? Grafikk ?

 

Når det gjelder antall Octaner som Statoil har tatt ut av produksjon vil jeg tippe et sted mellom 100 og 150...

De har nok enda noen i produksjon... Og så har de noen Tezro vil jeg tro.

I tillegg er det vel noen Onyx'er der enda...?

 

Hvordan gikk det med installasjonen av IRIX forresten ?

Hvilke versjon av OS'et ? Siste versjon er vel 6.5.28 tror jeg.

[ketter]

Mye vil ha mer og fanden vil ha fler, tilsynelatende blir det aldri nok regnekraft. De fleste store tunge applikasjoner blir over tid optimalisert for distribuert minne, det er en konsekvens av at kluster er mye billigere enn "big tin". Men slikt tar tid, og er krevende. For fremtiden (i den grad det begrepet kan brukes i databransjen) ser det for meg ut som om det også vil være et behov (om enn mye mindre enn før) for delt minne, og dyre løsninger fra IBM, SGI, Cray, om ikke annet så for software som ikke er modent nok til å utnyttes på vanlig klynge. I en utviklingsfase for en tung software vil jeg si at tilgang til en "big tin" er drømmesituasjon, spørsmålet blir hvem som skal plukke opp regninga. Nå finnes det sikkert problemer som vanskelig lar seg distribuere, jeg er nok litt farget av at alt jeg har sett og trodd i den retning har blitt gjort til skamme av nye implementasjoner som har skalert fantastisk.

Men det finnes jo også andre fordeler med de store maskinene fra f.eks. SGI.

Når jeg leser om SGI 4000 er det tydlig at en slik maskin vil ta en del mindre plass, bruke mindre strøm og generere mindre varme enn en klynge(med tilsvarende ytelse). I tillegg er det vel enklere å administrere en slik maskin.

Synes å ha lest en plass at Statoil's implementasjon av Dell klyngen tok mye lengre tid enn planlagt. I så fall er det jo en stor ekstra kostnad som må tas med i beregningen...

SGI's columbia installasjon skrøt de av at de installerte 512 CPU'er hver dag. Dette var fra lastebilene ankom til OS'et kjørte...

Klar over det, jeg har kjørt ganske mange CPU-timer på Notur, og siktet til egen erfaring på typisk slike applikasjoner du antagelig siktet til.

Men tror du så at NOTUR vil erstatte sin SGI maskin med en klynge ?

Så hvidt meg bekjent har vel de fleste nye MET installasjoner vært "big tin" ? Regner med MET skal fortsette å kjøre på NOTUR ved neste korsvei ?

[olefiver]

Hvor mye måtte du gi for Octane'en da ?

Spec ?

Er det Octane (grønn) eller Octane2 (blå) ? Grafikk ?

 

Når det gjelder antall Octaner som Statoil har tatt ut av produksjon vil jeg tippe et sted mellom 100 og 150...

De har nok enda noen i produksjon... Og så har de noen Tezro vil jeg tro.

I tillegg er det vel noen Onyx'er der enda...?

 

Hvordan gikk det med installasjonen av IRIX forresten ?

Hvilke versjon av OS'et ? Siste versjon er vel 6.5.28 tror jeg.

5161165[/snapback]

Hmm, se om jeg husker riktig nå...

Det er en Octane (grønn).

Grafikk-kortet, eller rettere kortene siden det er to (et halv høyde og et hel høyde), er av IMPACT serien. Jeg *trur* det er et MXI+SI oppsett (hvis det sier deg noe)

Prosessor: R12000 på 300MHz

Minne: 2GB

HDD: 18 GB

 

Kjøpte Octanen over qxl.no for 3000,- og fikk kjøpe en ekte SGI skjerm av SGI Norge for en tusing. Orginal mus/tastatur har jeg ikke, men det er ikke så viktig...

 

Installasjonen av IRIX lar fortsatt vente på seg, jeg har nå tilgangsproblemer med tftp serveren. Får enten "file does not exist" eller "access not allowed", altså error code 1 eller 2. Jeg har versjon 6.5.19 ... ? Husker ikke.

[ketter]

Hmm, se om jeg husker riktig nå...

Det er en Octane (grønn).

Grafikk-kortet, eller rettere kortene siden det er to (et halv høyde og et hel høyde), er av IMPACT serien. Jeg *trur* det er et MXI+SI oppsett (hvis det sier deg noe)

Prosessor: R12000 på 300MHz

Minne: 2GB

HDD: 18 GB

 

Kjøpte Octanen over qxl.no for 3000,- og fikk kjøpe en ekte SGI skjerm av SGI Norge for en tusing. Orginal mus/tastatur har jeg ikke, men det er ikke så viktig...

 

Installasjonen av IRIX lar fortsatt vente på seg, jeg har nå tilgangsproblemer med tftp serveren. Får enten "file does not exist" eller "access not allowed", altså error code 1 eller 2. Jeg har versjon 6.5.19 ... ? Husker ikke.

5161335[/snapback]

Sansynlighvis MXE med den spec'en. (hinv vil da rapportere EMXI eller noe slikt. Texture minne også da ? Bra pris !

Skjermen er en vanlig Sony trinitron tenker jeg. Veldig gode skjermer.

 

Installasjon av IRIX:

Filen du skal boote ligger på CD1, under boot-dir. Prøv å dele ut CDROM'en på serveren, og kjør en kommando som likner noe på denne fra PROM:

boot -f bootp()<server>:/<cdrom>/boot/sa(sash64)

En feil vil rapportere litt mer i PROM en på grafisk grensesnitt.

 

En annen ting; Det kan være ting som henger igjen i PROM (printenv) fra Statoil. F.eks. "netmask" e.l. Start med å skrive "resetenv" + "reset" i PROM. Gå så tilbake og skriv inn dine data (ipadresse/ef0mode osv) på nytt, for så å prøve tftp-boot på nytt.

Prøv å sette hastighet og duplex fast på begge maskinene hvis du får problemer. På linux: "ifconfig media type" eller noe slikt... (sjekk man)

[Del]

Men det finnes jo også andre fordeler med de store maskinene fra f.eks. SGI.

Når jeg leser om SGI 4000 er det tydlig at en slik maskin vil ta en del mindre plass, bruke mindre strøm og generere mindre varme enn en klynge(med tilsvarende ytelse).

Har ikke sjekket opp dette, men stiller meg litt tvilende. Et bladecenter med dualkjerne Opteron kontra Altix med Madison, er du sikker?

I tillegg er det vel enklere å administrere en slik maskin.

Godt poeng! Litt usikker på hvorvidt dette skyldes at linux-klynge er en ferskere løsning, samt at god linux kompetanse er mangelvare.

Synes å ha lest en plass at Statoil's implementasjon av Dell klyngen tok mye lengre tid enn planlagt. I så fall er det jo en stor ekstra kostnad som må tas med i beregningen...

SGI's columbia installasjon skrøt de av at de installerte 512 CPU'er hver dag. Dette var fra lastebilene ankom til OS'et kjørte...

To eksempler gir ingen trend. Notur har hatt sine problemer... Grunnen til forsinkelsen hos Statoil kan være så mangt. I dag kan du jo nærmest få ferdige klynger med posten.

Men tror du så at NOTUR vil erstatte sin SGI maskin med en klynge ?

Så hvidt meg bekjent har vel de fleste nye MET installasjoner vært "big tin" ? Regner med MET skal fortsette å kjøre på NOTUR ved neste korsvei ?

I sin tid var jeg en av de ved NTNU som ga tommelen opp for innkjøp av Origin maskinene. I dag ville jeg kanskje anbefalt å vurdere klynge med 2xDC Opteron noder, infiniband interconnect, og Pathscale kompilator pakke. Dersom MET var alene om å spytte inn penger, ville en benchmarking av koden deres vært på sin plass.

[ketter]

I sin tid var jeg en av de ved NTNU som ga tommelen opp for innkjøp av Origin maskinene. I dag ville jeg kanskje anbefalt å vurdere klynge med 2xDC Opteron noder, infiniband interconnect, og Pathscale kompilator pakke. Dersom MET var alene om å spytte inn penger, ville en benchmarking av koden deres vært på sin plass.

5163205[/snapback]

 

I en liten notis i Computerworld fredag nevnte Hysing at det ble SGI til slutt hos NOTUR. Har ikke sett noe på nettet om dette, men hvis så er tilfellet er jeg fornøyd med det !

Det er godt at det fortsatt finnes noen som tenker kvalitet fremfor kvantitet :-)

Og jeg regner da med at benchmark'en var en avgjørende faktor i valget.

[Del]

Kjenner ikke beslutningsprosessen der, hvilke argumenter og systemer som var involvert, eller hvilket prisnivå SGI la seg på, er du sikker på at det dreier seg om utskifiting av Notur? Med en reell benchmarking, og markedspris for systemet, vil en slik beslutning overraske meg.

 

Når det gjelder kvantitet og kvalitet skjønner jeg det er følelser ute å går, jeg har også sansen for SGI, men andre leverandører kan også levere produkter av høy kvalitet.

[ketter]

Kjenner ikke beslutningsprosessen der, hvilke argumenter og systemer som var involvert, eller hvilket prisnivå SGI la seg på, er du sikker på at det dreier seg om utskifiting av Notur? Med en reell benchmarking, og markedspris for systemet, vil en slik beslutning overraske meg.

 

Som nevnt har jeg ikke sett noe om dette andre steder. Undrer meg i grunn at Computerworld skriver noe som dette uten at NOTUR har noe om det på sin side (og ingen andre nyhetskanaler melder om det som jeg kan se).

Har fulgt litt med på saken i nyhetene, og det stod vel som jeg har forstått mellom SGI og IBM i slutten (tror det var Computerworld som skrev det også).

Markedspris: Vi snakker vel skjeldent om markedspris i universitetsdealer (?) Jeg tror nok både SGI og IBM var konkuransedyktige også når det gjelder pris/ytelse.

I tillegg kommer andre faktorer som nok er viktige for met:

 

Fra en annen artikkel av hr. Hysing:

Værvarslet vårt utarbeides daglig på NTNU av SGI Origin 3000 med kallenavnene Embla og Gridur. Værvarselet vil nok fortsatt bli beregnet i Trondheim, spørsmålet er på hva?

SGI Altix eller Cray XT3 er kanskje de to mest spennende alternativene. IBMs Blue Gene er best for oppgaver som kan splittes og fordeles på mange prosessorer.

Meteorologisk Institutt har bevist at det går med sin IBM-klynge basert på AMD Opteron, men værberegningene forutsetter en effektiv og rask sammenkobling og samkjøringsteknologi som MPI Connect (Message Passing Interface) og Manage fra Scali.

http://www.computerworld.no/index.cfm/fuse...tikkel/id/51973

Er ikke enig med alt dette, men han har et poeng.

 

Når det gjelder kvantitet og kvalitet skjønner jeg det er følelser ute å går, jeg har også sansen for SGI, men andre leverandører kan også levere produkter av høy kvalitet.

5599231[/snapback]

 

Selvfølgelig leverer nok de fleste konkurenter HW av kvalitet. Jeg tenkte nok mer på kvalitet når det gjelder teknologi... Har vel litt blandede følelser ovenfor f.eks. Dell som (så hvidt jeg forstår) gav tilbud her. Dette med referanse til vår tidligere diskusjon om hvor mye de respektive putter inn i R&D osv. Jeg er for all del enig i at et visst prispress i bransjen er bra, men hvis det skulle gå ut over firma som driver med utvikling av alternativ teknologi er det ikke bra. Dell gjør en fantastisk jobb med logistikk, og lager sikkert bra PC'er (eier et par selv), men jeg holder mer av mangfold.

Når det gjelder kvalitet er det med tanke på at det antaklig er gjordt "real world" applikasjonstester her, og ikke bare fokus på linpack og GFLOPS som det er på f.eks. Top500. Hele denne diskusjonen har vi gått gjennom før, men jeg kan vel bekrefte at det er litt følelser ute og går

[Del]

Kan forstå dine følelser angående Dell, men IBM er jo et godt eksempel på kvalitetsleverandør, Cray likeså. Tror du har helt rett når det gjelder prising ovenfor universiteter, men dagens Notur var på ingen måte billig. Husker ikke prisen lenger men det var en del millioner som skulle ut (synes å huske at det lå mellom 50 og hundre, men kan hende hugen er på bærtur), men den gangen var spleiselaget større. Derimot verserer det mange historier om ekstrem gavmildhet knyttet til Itanium den siste tiden.

 

Når det gjelder benking på den type problemer met regner på egner Opteron seg meget godt, på andre problemer egner Xeon seg bedre, og Itanium har sine styrker også, men det kan være krevende å få fullt utnyttet Itanium sitt potensiale. Denne balansen kan slevfølgelig forandre seg i løpet av året, hvilket blir spennende å se.

 

Mine oppfatninger er overhodet ikke basert på Linpack. Hvis du har befatning med den type kode vil jeg anbefale deg å teste litt selv. Så lenge softwaren er distrubuert (og det bør den nesten på SGI også) kan faktisk Infiniband konkurrere godt med Numalink på en god del problemer.

[ketter]

Usikker på om du viser til den som er ute på anbud nå, men der var det vel snakk om 30M. Det er i hvert fall en del mindre enn tidligere runder. Aner ikke hva de har lagt på tidligere, men det kan nok godt være som du skriver.

Tror nok gjerne Intel vil rabattere Itanium, ja. De trenger å bygge opp sin install-base.

Er forøvrig enig i at IBM og Cray er i samme klasse som SGI, og det finnes flere andre som er der oppe. I tillegg er kluster er fantastisk mulighet der applikasjonene tillater det. Men noen applikasjoner vil som vi tidligere har diskutert med fordel kjøres på "big iron" shared memory maskiner.

 

Benchmarks: Her er jeg IKKE i mitt rette element. Jeg antyder ikke at du tenker i noen spesifik retning, men kommenterer på generellt grunnlag ut fra manges oppfatning av hva som gjør en "supercomputer" til den "raskeste" i verden. Jeg er som du gjerne forstår skeptisk til Top500 da det faktisk finnes alternative måter å måle ytelse på. Linpack er nok av de enkleste, men gir gjerne ikke et helt balansert bilde. Tror det var bl.a. Cray som foreslo en alternativ test, men at det ble for omfattende (Finner ikke henvisning til dette i farten)

 

Når det gjelder SGI er vel deres styrke akkurat og utnytte Itanium, og skalere bedre enn de fleste konkurrenter. Det er vel ikke Numalink som er hele hemmligheten til SGI's maskiner, men også minnehåndtering mm. Det eneste jeg er sikker på er at vi vil se mye spennende i årene som kommer...både fra SGI og konkurrenter av SGI.

Jeg har nok ikke mulighet til å teste noe på SGI maskiner...desverre :-)

[Del]

Mener det skal stå en del Itanium maskiner på Gløs fortsatt, så det burde vel være mulig å teste hvis du befinner deg der.

 

Når det gjelder skalering, er Numalink den begrensende faktoren, siden det er navnet på SGI sin node-interconnect, brikkesettet vil hovedsaklig påvirke node-ytelsen, og der har ikke SGI gjort så veldig imponerende jobb.

 

Hvis du leser dine egne linker ser du at met bruker MPI for å skalere koden sin, hvilket forteller deg at applikasjonen er distribuert, hvis du sjekker opp hva NUMA forkortelsen betyr, finner du også fort ut at det gir liten mening å skalere en applikasjon til mange CPU'er uten å programmere distribuert. Det som derimot er saken er at SGI sin NUMAlink er den mest effektive løsningen på node-interconnect i markedet, hvilket gjør at den performance hit'en du får når data må fra en node til en annen er litt mindre enn hva infiniband kan vise til. Med massiv skalering (f.eks. til flere hundre CPU'er) kan denne lille forskjellen bli ganske stor, du kan sette opp et enkelt regnestykke for å se sammenhengen her, men dette vil være applikasjonsavhengig. Så "big iron" kontra "small" blir misvisende, selv om Altix har delt minne, så betyr ikke dette at det gir mening å kjøre store jobber på Altix med simpel flertråding.