Intel Itanium benchmarks

Ace's Hardware heeft mooie grafiekjes gemaakt van de benchmarks van een Intel Itanium 667MHz, naar aanleiding van deze post in het mailarchief van de makers van ATLAS. De schrijver van die post vergelijkt de prestaties van de Intel Itanium 667MHz, Intel Pentium 4 1,5GHz en AMD Athlon 1GHz (met SDRAM) onder ATLAS, een programma voor lineaire algebraïsche berekeningen. Ace's Hardware heeft een diagram gemaakt van de resultaten in een double precision matmul benchmark. In deze test worden twee matrices met elkaar vermenigvuldigd.

Intel's nieuwe IA-64 architectuur zet dus zeker geen onredelijke prestaties neer. Volgens Paul DeMone, die zijn reactie geeft in deze thread op het forum van Ace's, geeft dit echter nog geen enkele garantie voor de performance van de Itanium in andere applicaties:

Given the machines are running Linux and the IA-64 compilers on Linux don't do serious EPIC specific optimizations yet (AFAIK) I presume these Atlas routines are hand code and optimized in IA-64 assembly language. Unfortunately that reduces the usefulness of these results to predict ultimate Merced performance on compiled programs such as the SPEC suite.

In deze benchmark werden overigens nog geen SSE2 of 3DNow! optimalisaties gebruikt. Met dank aan Crack voor de tip.

Reacties (52)

[mth]

Hoe groot is de cache van de Itanium? Ik vraag me af of die knik in de curve veroorzaakt wordt door een volle cache. Een double precision floating point getal is 64 bits, toch? De knik zit ongeveer bij 350, aangenomen dat het vierkante matrices zijn en er twee verschillende matrices vermenigvuldigd worden en ook nog een resultaat matrix opgeslagen wordt, zou er ongeveer 3MB cache in zitten. Dat is een stuk meer cache dan de Athlon en de P3 hebben, dus de vraag is hoeveel deze grafiek zegt over de performance van de Itanium core.

[JeroenB]

Op http://www.vr-zone.com/Home/news56/news56.htm#8 58 wordt geclaimed dat cachesizes 2 en 4mb zullen zijn voor de verschillende modellen. Volgens Intel zelf staat het nog niet vast: ftp://download.intel.com/design/IA-64/Download s/24547401.pdf - op pagina 14 van dit document willen ze alleen kwijt dat er verschillende modellen komen. Dus die 2-4mb lijkt me niet zo gek gezien de huidige 1-2mb op de zwaardere Xeons.

[Verwijderd]

Die score valt me niet eens tegen, maar ik had 'm liever t.o. een Alpha, Sparc, Mips of HP-PA gezien want daarmee zal hij toch moeten concureren.

In vergelijking met de Athlon is hij vergelijkbaar met een 1500MHz versie, en dat voor 666MHz da's zo'n 2,25x zo snel per clockcycle...
Maar ja, zo'n monster als de Alpha 21364 moet hij nog maar eens zien te kloppen.

[0rbit]

Zoals uit de nieuwspost al naar voren komt is het inderdaad niet tegenvallend, maar je moet je wel bedenken dat dit volledig in ASM uitgewerkte routines zijn; Weet je nog wat er met FlaskMPEG gebeurde als je voor de Athlon ging optimaliseren? 200+% prestatiewinst!

De benchmark is dus wel redelijk aardig te noemen, maar echter niet eerlijk. In hoeverre een met een compiler gebouwd programma (waarbij de optimalisaties lang niet zo goed zijn) even snel is, is af te wachten. Het hangt eigenlijk dus allemaal van de ondersteuning in de compilers af...

[arjenk|IA]

Weet je nog wat er met FlaskMPEG gebeurde als je voor de Athlon ging optimaliseren? 200+% prestatiewinst!

* 786562 arjenk

[arjenk|IA]

Misschien wel erg rooskleurig, maar veel minder moet het ook niet zijn. De IA-64 heeft een nieuwe instructieset zodat eindelijk afgerekend kan worden met de x87 stack-georienteerde instructies die de oorzaak is dat P4 en Athlon in floating point naar verhouding veel slechter presteren als in integer instructies vergeleken met RISC processors. Het zou mij juist tegenvallen als Intel er niet in slaagt de relatieve FP performance te verdubbelen.

[The_Holy_Jampot]

Dit ziet er allemaal wel erg rooskleurig uit he. Ik kan me niet voorstellen dat een 667Mhz Itanium bijna 2x zo snel is als een athlon 1Ghz. Natuurlijk is het wel een 64-bits, maar ik vind het verschil wel errug groot. En waarschijnlijk zal de prijs van die itanium wel weer een paar honderd gulden hoger liggen dan die van amd's proc.

Maar we zullen zien, misschien is het wel echt een goeie en betaalbare proc, maar ik kan het me nauwelijks voorstellen dat het verschil ZO groot is

[ConZito]

Paar honderd

Reken maar op een paar duizend, dit is een high-end processor voor in servers. En het is vrij normaal dat hij op 667mhz sneller is dan een 1ghz AMD, de cores van de procs verschillen zoveel onderling, afgezien dat de ene 32bit is en de andere 64.
Over de benchmark kan ik nog weinig zeggen, zie liever real life benchmarks, maar het belooft iig veel goeds.
Dit word toch de toekomst, van 32bit naar 64bit, dus hopen dat ze ervan leren en later een mooie thuisgebruiker versie neerzetten.
Maar ik snap niet dat ze 32bit procs met 64bit procs vergelijken, dat werkt niet, het kan namelijk zo zijn dat deze proc veel langzamer is met x86 instructies dan een p3 of athlon. Dat komt omdat de instruction set EPIC zwaar afhankelijk is van de compiler, maar we zien wel hoe het verder uitpakt. Intel heeft ze zinnen erop gezet en kondigt hem nu al bijna een jaar of 2 aan, dus we wachten af.

[.oisyn]

Was het niet zo dat de itanium niet backwards compatible was? dus dat de oude x86 instructies ge-emuleerd zouden moeten worden?
Of zijn de instructies hetzelfde en moet alleen het 32bits gedeelte ge-emuleerd worden...

iig, dan is de performance gewoon zwaar klote voor gewoon 32 bits.
Wat dus NIET geld voor de hammers van AMD, want die zijn WEL backwards compatible

maar ja, backward compatibilty is ook niet alles. Als intel zijn 386 niet compatible had gemaakt dan hadden we nu waarschijnlijk met veel betere processors gezeten omdat het ontwerp dan gewoon helemaal anders had gekund.

[StarLite]

32 vs 64 bits = 2 keer.
Dus de performance zou in principe 2 keer zo hoog kunnen zijn.
Ze zeggen ook dat de bemnchmark, handmatig is geoptimaliseerd voor 64 bits. Dus in de praktijk zal dit vreschil veel kleiner zijn.

[Wietse.]

Nee, 64 vs 32 bit zegt in de eerste instantie helemaal niets over performance winst. 64 bit betekent dat het datapad in de CPU 2 keer zo breed is als bij 32 bit.
Stel het maar voor dat je nu getalletjes kan vermenigvuldigen met 2 keer zoveel cijfers. Je zou bij wijze van spreke dezelfde vermenigvuldiger uit de 32 bits cpu kunnen pakken, en die 2 keer zo breed maken. Het eindresultaat is dat hij net zo snel is.

De echte snelheidswinst bij de Itanium wordt veroorzaakt door de EPIC instructie set. Daarmee is het mogelijk om van te voren (bij het compilen) al te kijken wat er moet gebeuren (welke data uit het geheugen waarheen in de cpu). Vooral bij dit soort matrixberekeningen is dat vrij makkelijk, zoals je kan zien aan de goede resultaten. Bij spelletjes is het helaas iets minder eenvoudig, dus minder snelheidswinst.

[Verwijderd]

Nee, 64 vs 32 bit zegt in de eerste instantie helemaal niets over performance winst. 64 bit betekent dat het datapad in de CPU 2 keer zo breed is als bij 32 bit.

Natuurlijk wel. Als je (precies zoals in de test) rekent met double precision floats (die voorgesteld worden op 64 bits) dan heb je (grof gezegd) op een 32 bits processor 2 kloktikken nodig en op een 64 bits processor maar 1 kloktik per bewerking nodig. Dat is ook de hele reden dat de DEC Alpha processor zo verrekte snel is in double precision floating point berekeningen.

Ik ben wel benieuwd naar de integer performance van de Itanium, die zou wel eens een stuk achter kunnen blijven.

[Philip J. Dijkstra]

Damn ik moet echt gaan slapen:

2*X tijd moet natuurlijk X/2 zijn in dit geval.

To the point:

Het gaat niet 2 keer zo snel want ik breek mn rug.

[Philip J. Dijkstra]

Hmmm ja ja,

voorbeeldje:

Ik loop met een kruiwagen vol zand (pre-natal-silicium voor mensen die niet buiten komen )
Dit duurd X tijd
Nu krijg ik een 2 keer zo grote kruiwagen,
geldt dan : Dit duurd 2*X tijd ?

Neeeeeeee, til verdomme maar eens zo'n kruiwagen.

Nou is dit een dom voorbeeld maar bij 32 bits naar 64 bits is de versnelling niet zomaar *2 zonder haken & ogen.

Aan iemand anders de eer om die haken & ogen te gaan vertellen; ik ga fijn slapen

[Daniel]

Een Itanium is absoluut waardeloos met 32 bits applicaties....ik spreek uit ervaring

[Daniel]

Uche...top secret

32 bits applicaties werken wel op IA64 maar dan moet de code omgezet worden. Dat kost tijd, en naar blijkt erg veel tijd. Wil je een Itanium fatsoenlijk kunnen gebruiken dan moet je al je 32 bits code hercompileren, anders kun je net zo goed een pentium 100 gaan gebruiken

[johanvdw]

Maar zoveel grote servertoepassingen zijn er nu ook niet, dus dat recompilen zal ook niet zo lang duren.

[Verwijderd]

welke ervaring heb jij er mee dan? zijn er 32 bits applicaties die het doen op IA64 dan?

[Master_Egg]

sukkels.... kunnen jullie niet rekenen ofzo??

sinds wanneer is 2 * 2^32 -> 2^64 FOUT FOUT FOUT FOUT elke dode wiskundige draait zich nu om in zijn graf > .

reken zelf maar ff na als je me niet gelooft. Ik vind de prestaties daarom ook tegenvallen. Maarja hier worden ook eigenlijk appels met peren vergeleken.

[Verwijderd]

Als de Itanium 1700 mflops haalt en de Athlon 1200 mflops, dan lijkt mij de Itanium niet 2x zo snel. Eerder 1,4 keer zo snel. Neemt niet weg dat dat nog steeds lekker snel is.

[Verwijderd]

vergeet niet dat die itanium op een lagere kloksnelheid draait.....

[Verwijderd]

De EPIC instructieset is juist het goede aan de itanium, zeker voor de desktop systems. Die instructieset levert juist zoveel meer info op voor de processor om intern te optimaliseren, zodat er veel meer snelheid kan worden behaald.

de huidige 32bit programma's draaien op een Itanium lijkt me niet zo nuttig. Hij moet dan emuleren en dat levert nooit snelheidswinst op. Hercompileer je echter de code met een itanium enabled compiler, dan heb je dat voordeel van die EPIC instructieset weer WEL.

wel naar dat die instructieset 'EPIC' heet. Moet telkens denken aan een Unreal game, heel gek

[Verwijderd]

Het ligt vooral aan de software die je er voor gebruikt en met welk programma er wordt getest,

vergelijk het maar met vroeger met de (486 SX en de DX2 versies)

[BikkelZ]

Die Paul DeMone krijgt zo onderhand een goddelijke status......je kletst wat op een forum en je wordt over de hele wereld meteen gequote

[Boomrups]

Wie is Paul deMone?

[TD-er]

Zoals BikkelZ al zei:

Die Paul DeMone krijgt zo onderhand een goddelijke status......je kletst wat op een forum en je wordt over de hele wereld meteen gequote

[Verwijderd]

lineaire algebraïsche berekeningen in een double precision matmul benchmark

ja idd. als we die nou ff met een flinke terominale byte sessie converteren naar een hyper time super molecuul bypass product, dan kunnen we die vergelijken met het over suspended blue bit map syndroom.

[.oisyn]

Maar dan zit je weer met het probleem dat de quantum fluctiaties in het plasma-array gaan optreden. Wat weer tot gevolg heeft dat de superinduction lightenhancer te veel electronen in de magneton-unit brengt en dat moeten we natuurlijk niet hebben

[Frank Reiber]

Dit belooft veel goeds voor de toekomst

* 786562 Frank

[Verwijderd]

Iets meer dan een jaar zal het nog wel moeten duren.
De 64 bits processor van AMD de sledgehammer lijkt me interessanter. En die komt pas in 2002.
Maar voor de consumenten komt er nog een thuisgebruikers versie de Clawhammer. En als die komt zal het doorbreken van 64 bit denk ik pas echt gaan beginnen.

[johanvdw]

AMD gaat volgend jaar nog niet zorgen voor een doorbraak hoor. Zij hebben maar een te verwaarlozen invloed op de ontwikkelingen.

[kareltje21]

beetje scheve vergelijking, qua snelheid,
maar geeft wel potentie weer, eindelijk eens een beetje complexe dingen doen.

[Verwijderd]

ut heeft dan even geduurd..maar dit vind ik toch best knap van INTEL ... er was al een tijdjuh twijfel of die Itanium wel relax zou worden omdat ze hem eerst niet hoger kregen als 600mhz

en tja je mot wel 64bit applicaties hebben etc om kans te heben dat je die performance krijgt..

en nu wachten op de AMD Sledgehammer

toch altijd leuk om te zien hoe een cpu die op een lagere freq draait TOCH de GHZ cpu's naar de zijkant beukt met grof geweld...

[Makkelijk]

Allemaal heel leuk, en ik geloof best dat hij over 2 jaar de servermarkt gaat veroveren (als de sledgehammer het niet doet) maar hij kan geen koetje draaien! dan moeten ze de hele client herschrijven (me 16bit 286 kon ook geen koetje draaien omdat hij niet 32bit was)

Maar ff zonder gekkigheid, leuk om allemaal naar uit te kijken hoor, maaruh... volgens mij gaat het toch lang duren.. en de test is volledig onbetrouwbaar en zou nooit betrouwbaar worden omdat de toepassingen ZO veel anders zijn, toepassingen van de 286 moesten er ook allemaal uitgewerkt worden toen de 386 kwam, zo ongelooflijk veel verschil zit er tussen. En ook in snelheid, ik denk toch dat geoptimaliseerde code hiervoor tegen hetzelfde prog als het voor P3 is geoptimaliseerd minimaal een P3-2000 nodig heeft om in de buurt te komen van de Itanium 666