Raskere Sparc64 fra Fujuitsu

[int20h]

Raskere Sparc64 fra Fujuitsu

Fujitsu øker ytelsen på sine Sparc64-prosessorer ved å bruke ny produksjonsteknikk. I tillegg gifter selskapet seg i disse tider med Sun Microsystems.

 

Les artikkelen her

[TheZombie]

Hm den nye cpun blir jammen meg rask.

 

Nye Sparc64-prosessorer er på vei. Fujitsu sin nye produksjonsteknikk på 90nm kommer til å danne grunnlaget for en rekke prosessorer klar for lansering i løpet av året. I første omgang snakkes det om en CPU som kjører på 1,89 MHz og har 3 MB cache. Til sammenligning kjører dagens toppmodell på 1,35 GHz og har 2 MB cache (130 nm teknologi). De nye prosessorene vil være pinne-kompatible med tidligere versjoner og oppgradering er dermed enkelt.

[Coffie=JavaCode]

Finnes det noen tester som kan vise hvor rask den er kontra en litt vanligere CPU?

[Knick Knack]

Finnes det noen tester som kan vise hvor rask den er kontra en litt vanligere CPU?

SPEC er vel det nærmeste du kommer. (de nye 90nm prosessorene er selvsagt ikke teset) [Edit: joda de har faktisk blitt lagt inn nå se lengre ned.]

 

SPEC gir forøvrig et greit bilde av virkeligheten så lenge en ikke skal bruke systemene på store datamengder. (mange GB)

Endret 23. juni 2004 av Knick Knack

[Hummbugg]

jeg lånte for en stund siden en Dual 45MHz Sparc maskin med linux og vil si

at ytelsen på denne hvar omtrent som en Dual Pentium pro 180MHz.

eneste var at den var treg på oppstarten pga SCSI systemene men det

er det jo SCSI på eldre x86 systemer også.

 

men nå vet jeg ikke åssen det er men Sparc prossesorer har gitt mer

ytelse pr. MHz en de fleste andre vanligvis

[Knick Knack]

Her er forresten SPEC resultatene for SPRC64 sammenlignet med det som kryper å går av 1 til 8 way servere:

SPECmine Int_rate2000

 

Edit: SPECInt_rate2000 med mer allment kjente prosessorer

 

Det nye SPARC64 systemet er faktisk ikke mindre enn en liten sensasjon. Definitivt årets overraskelse. Jeg hadde begynt å miste troen på SUN og SPARC. Nå ser i allefll SPARC ut til å ta seg opp. 8-way systemet blir kun slått av Itanium 2. Nå mangler riktig nok 8-way Opteron her, men den ligger vel ikke veldig godt ann til å slå SPARC systemet.

 

Floating point ytelse er den god på også!

Endret 23. juni 2004 av Knick Knack

[Coffie=JavaCode]

SPEC er vel det nærmeste du kommer. (de nye 90nm prosessorene er selvsagt ikke teset)

 

SPEC gir forøvrig et greit bilde av virkeligheten så lenge en ikke skal bruke systemene på store datamengder. (mange GB)

Det ser dårlig ut for x86 for tiden. Glad for at SUN kommer seg vekk fra nedgangen de har hatt i det siste.

 

Ca hvor kommer Power 5 til å befinne seg på grafen?

Endret 23. juni 2004 av Macfan

[Knick Knack]

SPEC er vel det nærmeste du kommer. (de nye 90nm prosessorene er selvsagt ikke teset)

 

SPEC gir forøvrig et greit bilde av virkeligheten så lenge en ikke skal bruke systemene på store datamengder. (mange GB)

Det ser dårlig ut for x86 for tiden. Glad for at SUN kommer seg vekk fra nedgangen de har hatt i det siste.

 

Ca hvor kommer Power 5 til å befinne seg på grafen?

Det har vel aldri sett bra ut for x86 (med unntak av introduksjonen av P6), likevell henger den med og kommer desverre til å gjøre det en god stund til.

 

Power5 vil vel bare havne en plass på lista. Nemlig på toppen. En ikke helt uvanlig plassering å havne på når verdens største IT firma satser alt på HPC... Spørsmålet er bare hvor lenge de blir liggende på toppen. Til rundt juni 2005 kanskje?

 

NB! maskinene listet i SPECmine må ikke forveksles med de som er listet på top500.org. Det er stort sett cluster på top500.org og selv om de kan skilte med enorme mengder tflops i linpack så ville de færreste klart å kjøre vanlige workstation programmer som de i SPEC suiten med lignende ytelse som de klarer i linpack. Dette fordi linpack består av oppgaver som ikke krever at prosessorene sammarbeider i vesentlig grad.

Endret 23. juni 2004 av Knick Knack

[Coffie=JavaCode]

SPEC er vel det nærmeste du kommer. (de nye 90nm prosessorene er selvsagt ikke teset)

 

SPEC gir forøvrig et greit bilde av virkeligheten så lenge en ikke skal bruke systemene på store datamengder. (mange GB)

Det ser dårlig ut for x86 for tiden. Glad for at SUN kommer seg vekk fra nedgangen de har hatt i det siste.

 

Ca hvor kommer Power 5 til å befinne seg på grafen?

Det har vel aldri sett bra ut for x86 (med unntak av introduksjonen av P6), likevell henger den med og kommer desverre til å gjøre det en god stund til.

 

Power5 vil vel bare havne en plass på lista. Nemlig på toppen. En ikke helt uvanlig plassering å havne på når verdens største IT firma satser alt på HPC... Spørsmålet er bare hvor lenge de blir liggende på toppen. Til rundt juni 2005 kanskje?

NICE Dette ser svært bra ut.

[snorreh]

SPEC gir forøvrig et greit bilde av virkeligheten så lenge en ikke skal bruke systemene på store datamengder. (mange GB)

Nei, SPEC er mer en benchmark av kompilatorer for forskjellige plattformer på små og som regel utdaterte koder (ikke akkurat state-of-the-art) og er derfor etter manges mening en dårlig indikator på reell ytelse. SPEC-testene skiller seg sånn sett ikke ut fra andre syntetiske tester. Ønsker man et mer riktig bilde av virkeligheten bør man gjøre som en rekke uavhengige teststeder gjør, nemlig å teste prosessorene vha. et bredt utvalg av forskjellige benchmarks (både syntetiske og programvare-baserte). Hvis du tror utelukkende på SPEC, så lurer du bare deg selv...

[Knick Knack]

Nei, SPEC er mer en benchmark av kompilatorer for forskjellige plattformer på små og som regel utdaterte koder (ikke akkurat state-of-the-art) og er derfor etter manges mening en dårlig indikator på reell ytelse.  SPEC-testene skiller seg sånn sett ikke ut fra andre syntetiske tester.  Ønsker man et mer riktig bilde av virkeligheten bør man gjøre som en rekke uavhengige teststeder gjør, nemlig å teste prosessorene vha. et bredt utvalg av forskjellige benchmarks (både syntetiske og programvare-baserte).  Hvis du tror utelukkende på SPEC, så lurer du bare deg selv...

Om en bruker SPECint_rate2000 Base så får en faktisk et bilde som stemmer veldig godt overens med den gjevne ytelsen til de fleste "vanlige" applikasjoner fordi en eliminerer muligheten til ekstrem optimalisering av koden og fordi integer er mer typisk for "vanlige" programmer enn FP. SPECint_rate inneholder vel ca 18% branches også så CPU blir testet hardt på det som virkelig gjelder. Klart det er mulig å dra konklusjoner om hvor bra kompilatorene er ved å sammenligne base og peak resultater med de optimaliseringene som ble gjort ved kjøring av peak testene.

 

Ellers regner jeg med at du mener alle tester som ikke favoriserer Opteron er ubrukelige. Spørsmålet er bare hvor lenge det er til Unreal er den eneste "real" benchmark

 

Pussig nok er Opteron klart best i SPECint_rate2000 Base. Den skalerer bare litt dårlig...

Noe bedre skalering enn Xeon seff:

Opteron, Xeon MP, Itanium2

Endret 23. juni 2004 av Knick Knack

[snorreh]

Om en bruker SPECint_rate2000 Base så får en faktisk et bilde som stemmer veldig godt overens med den gjevne ytelsen til de fleste "vanlige" applikasjoner fordi en eliminerer muligheten til ekstrem optimalisering av koden og fordi integer er mer typisk for "vanlige" programmer enn FP. SPECint_rate inneholder vel ca 18% branches også så CPU blir testet hardt på det som virkelig gjelder.

Du må bare fortsette å tro det, men du lurer bare deg selv...

 

Ellers regner jeg med at du mener alle tester som ikke favoriserer Opteron er ubrukelige. Spørsmålet er bare hvor lenge det er til Unreal er den eneste "real" benchmark 

Latterlig påstand!

Endret 23. juni 2004 av snorreh

[Knick Knack]

Du må bare fortsette å tro det, men du lurer bare deg selv...

 

 

Latterlig påstand!

Hva med å gi meg enn referanse til noe som underbygger at SPEC er ubrukelig som benchmark? Da helst en kilde som ikke tar for seg alt annet enn "SPECint_rate2000 Base" (beklager at jeg ikke alltid tar ditt ord for god fisk sånn helt uten videre, men du mangler argumentasjon(!) og strengt tatt er det ikke første gang du skyter i blinde.)

 

Ja jeg vet det var en tåpelig påstand. Kunne bare ikke dy meg. Det er så tydelig.

Endret 23. juni 2004 av Knick Knack

[snorreh]

Du må bare fortsette å tro det, men du lurer bare deg selv...

Hva med å gi meg enn referanse til noe som underbygger at SPEC er ubrukelig som benchmark? Da helst en kilde som ikke tar for seg alt annet enn "SPECint_rate2000 Base" (beklager at jeg ikke alltid tar ditt ord for god fisk sånn helt uten videre, men du mangler argumentasjon(!) og strengt tatt er det ikke første gang du skyter i blinde.)

Det har vært en hel drøss av diskusjoner vedrørende SPEC på Ace's Hardware sitt diskusjonsforum som f.eks. dette gode innlegget av forfatteren bak DIEP:

http://www.aceshardware.com/forum?read=105040672

spec programs do in general fit in very small instruction caches.

 

Read the interview with the intel c++ compiler team, and i am sure other compiler teams will confirm it, a BIG problem is getting the instruction cache filled during the run of a program.

 

With the tiny spec programs that task is considerable lighter than real world applications.

Chip Architect har undersøkt dette nærmere her:

http://www.chip-architect.com/news/2003_08...r_SPEC2000.html

The SPEC 2000 benchmarks are subject to much debate in the scientific community. Are they broken? Do they just depend on memory bandwidth?  Do they fit entirely in the cache?  The recent publication of new benchmarks for the hp server rx5670 gives us a chance to produce some metrics.

SPEC har også blitt flittig diskutert på Beowulf sin mailingliste:

http://www.beowulf.org/pipermail/beowulf/2...ber/008411.html

The real problem with SPEC is that your application may well resemble one of the components of the suite, in which case that component is a decent predictor of performance for your application almost by definition.  However, the mean performance on the suite may or may not be well correlated with that component, or your application may not resemble ANY of the components on the suite.  Then there are variations with compiler, operating system, memory configuration, scaling (or lack thereof!) with CPU clock.

Digit-Life har også undersøkt SPEC-testene ganske grundig her:

http://www.digit-life.com/articles2/inside...000-part-e.html

The present situation can only mean one thing for testers: that from now on, CPUs made by different companies will be tested on very different codes. Which is not very good, in general. But then again, synthetics remain synthetics, no matter what.

Og videre her:

http://www.digit-life.com/articles2/inside...000-part-f.html

The fact that the compilers can't be possibly compared indicates their crudeness (as well as a rather bad AMD64 adaptation of the codes). But certainly, we can also note some progress in the development of standard compilers for Linux and Windows platforms. Although in such case, compilers are more expected to just work than provide a maximal efficiency of the resulting code.

Jeg sier altså ikke at SPEC-testene er ubrukelige, men bare at de bør tas med samme menge salt som alle andre syntetiske benchmarks som nødvendigvis ikke gir et helt riktig bilde av virkeligheten

 

Latterlig påstand!

Ja jeg vet det var en tåpelig påstand. Kunne bare ikke dy meg. Det er så tydelig.

Så vennligst hold det for deg selv neste gang da, for slikt sludder ødelegger enhver god diskusjon

Endret 23. juni 2004 av snorreh