Itanium langzamer dan Alpha in SAP benchmark

In een benchmark uitgevoerd door SAP op een groot aantal high-end server systemen komt een systeem van NEC met 32 Itanium-2 processors van Intel op de derde plaats van de 32-processor systemen, zo is te lezen op Heise.de. De SAP Standard Application Benchmark wordt al uitgevoerd sinds 1993 met als doel klanten van het bedrijf een indicatie te geven welke hardware goed schaalt met de software. De benchmark waar het in het artikel van Heise.de om draait is de zogenaamde SAP-SD benchmark, waarin het 'Sales and Distribution'-deel van MySAP wordt getest.

Van de vier 32-processor-systemen werd de koppositie ingenomen door een HP-server met 32 Alpha-processors op 1150MHz en 1850KB L2 cache. De tweede plaats werd ingenomen door een IBM eServer pSeries met 32 Power4-processors op 1,3GHz en 24MB L2 cache. Een NEC-server met 32 Itanium-2 processors op 1GHz en 3MB L3 cache kwam op de derde plaats gevolgd door een Compaq AlphaServer met 32 Alpha's op 731MHz. Hoewel de Itanium niet de snelste was, kan dit ook veroorzaakt worden door de verschillende specificaties van de systemen. Van de top-3 was het Itanium-systeem, samen met het IBM-systeem, voorzien van de minste hoeveelheid geheugen (65536MB) en was de kloksnelheid het laagst.

Overigens heeft de Itanium-2 momenteel de nodige kritiek te verduren. Linux-pionier Linus Torvalds uitte onlangs de nodige kritiek richting Intel met betrekking tot de Itanium. De kern van zijn betoog is dat de Intel met Itanium dezelfde fout maakt als andere RISC-fabrikanten, zoals Alpha, in het verleden zijn begaan door een zo 'clean' mogelijke architectuur te ontwerpen. Het gevolg hiervan is, volgens Torvalds, dat het ingewikkelde werk in software moet worden gedaan. Het enige wat in de Itanium goed is, is dat de processor in staat is om grote hoeveelheden geheugen te adresseren, "'de enige grote fout die in de x86-architectuur zit", aldus Torvalds. Hij pleit er dan ook voor dat Intel, net als AMD, de IA-32-architectuur uitbreid met 64-bit-instructies.

Het punt wat Torvalds maakt, over het feit dat de 'ingewikkelde' zaken in software moeten worden gedaan voor de Itanium, wordt min of meer bevestigd door C'T. In een test die dit blad verrichte met 64- en 32-bit-processors bleek hetzelfde stuk software na compilen voor IA-64 bijna drie keer zo groot als voor IA-32. Voor AMD's x86-64-architectuur was hetzelfde programma 15 procent groter dan voor IA-32. Wel moet er bij vermeld worden dat Torvalds momenteel in dienst is van Transmeta. Deze processorfabrikant is aanhanger van het :x86-64-platform van AMD:

Linus Torvalds has been holding forth on the state of processor architecture on the Linux Kernel Archive. In words that Intel are likely to be far from happy with, the Finnish luminary has stuck the boot into Itanium.

[...] He goes on to write, "As far as I know, the _only_ things Itanium 2 does better on is (a) FP kernels, partly due to a huge cache and (b) big databases, entirely because the P4 is crippled with lots of memory". That crippling with lots of memory is due to what many people describe as a major kludge in the Pentium architecture called Page Address Extensions (PAE). According to Torvalds, "the only real major failure of the x86 is the PAE crud".

Reacties (38)

[ferdinand]

het feit dat de 'ingewikkelde' zaken in software moeten worden gedaan voor de Itanium

Dit is nu juist ook een voordeel van de IA64. Omdat de programmeur met behulp van de compiler de processor heel duidelijk kan vertellen hoe het programma gedraaid moet worden(bijv. dingen die parrallel gedaan kunnen worden) kan de Itanium veel efficienter een programma draaien dan een X86 processor. Daarom hoeven de IA64 processors ook niet zo complex te zijn. En fouten in bijv. branch prediction voorkom je ermee.

Wat Linus Tovalds leuk vind aan de huidige x86 is een programmeur veel minder werk hoeft te doen om een programma te schrijven.

[RobT]

Ok, op papier was het een leuk plan.

IA-64 op papier:
-eenvoudiger, stop de complexiteit in de compiler
-simpeler design, kleiner
-lost alle problemen op waar x86 onder gebukt gaat (anno 1994)

IA-64 in werkelijkheid, 2003:
-compiler werkt nog niet echt optimaal, code wordt 3x zo groot als bij x86 (x86-64 code is slechts 15% groter)
-ItaniumII is een beest van een proc, powerhungry ( >120W) en extreem groot ( > 400mm2 ), met name vanwege de toch niet zo eenvoudige uiteindelijke structuur en de 6MB aan cache zonder hetwelk het ding waarschijnlijk nauwelijks vooruit te branden is...
- de vermeende x86 problemen zijn met trucs allemaal opgelost, OoO etcetc.

Bovendien heeft niet iedereen zin om al zijn executables opnieuw te compilen etcetc.

Zoals Jerry Sanders III al zei: waarom zou iedereen al zijn software voor miljarden opnieuw gaan compilen zodat Intel de enige cpu leverancier kan gaan zijn?

Verder is het niet zo dat de programmeur dingen moet instellen, de compiler zou alles moeten doen (duh, anders moet je nog een keer alle sources opnieuw schrijven, dat je het opnieuw moet compilen is al erg genoeg).

En als laatste, misschien moet je het commentaar van Linus maar eens goed lezen:
http://www.ussg.iu.edu/hypermail/linux/kernel/0302.2/2021.html
dan zal je zien dat het hem er niet om gaat dat hij wel of niet meer of minder werk moet doen om een programma te schrijven. Het gaat hem om performance en real world situaties, niet om theoretisch mooi ontwerpen.

[edit]Oh ja, wat nu de bottleneck is in pc's/computers is de bandbreedte (cpu-mem en systeem-disk). Vroeger was het het geheugen, vandaar CISC. Nu heeft EPIC/IA64 een code die 300% groeit volgens CT tov x86...
Iets zegt me dat je met IA64 niet zover komt met een kleine L2 cache (~512KB), terwijl dat de prijs zo fijn betaalbaar houdt.

[TheGhostInc]

Het gaat hem om performance en real world situaties, niet om theoretisch mooi ontwerpen.

Persoonlijk was ik toch zeker onder de indruk van de Floating Point prestaties van de Itanium.
Nu is het zo dat je daar in CounterStrike niks aan hebt, maar misschien is dat ook wel niet de doelgroep van deze processor.

Linus gaat iets te snel door computerland heen, terwijl een desktop van 2K iets anders is dan een server van 2M. Je kunt niet altijd alles met x86 gaan doen, of daar nu 64bit extenties aan zitten of niet.

Want waarom staan er geen Xeon processoren in de top? En de Xeon is redelijk vergelijkbaar met de Athlon64, waarbij de Athlon misschien 2x zo snel is door de 64bit. Maar dan nog is deze niet zo snel in deze benchmark als een Itanium.

Intel heeft een andere markt voor ogen, dan Amd, Amd is nog bezig in de markt waar Intel al domineert, de kleine server (Dual/Quad's)

[dahakon]

Je loopt hier even voorbij aan het fijt dat intel toch werkelijk van plan is om de Itanium processor door te drukken als de nieuwe processor voor elke pc, wat overigens pas over enkele jaren zou moeten gaan gebeuren, als de rek compleet uit de huidige P4 (en wellicht nog P5) is...

Dus de markt die Intel voor ogen heeft is ook die van de counterstrike-spelende thuisgebruikers...

[RobT]

Tsja, je hebt gelijk dat de SpecFP van de Itanium erg indrukwekkend is.

Echter, het is niet zo dat het een veelvoud van de concurrentie is. Wat je gezien de investering misschien wel zou hopen/verwachten.

Maw met vergelijkbare investeringen in x86 (-64) zou je dat er zeer waarschijnlijk ook uit kunnen halen; feit is dat x86 (32) niet eens zo heel ver achter blijft...

En waarom kan je niet alles met x86 doen? Het enige probleem is de beperkte geheugenadressering (ofwel de performance hit als je paging gebruikt). Verder ben ik nog geen behoorlijke tegenargumenten tegengekomen.

Linus gaat helemaal niet te snel door computerland, die vent heeft zich echt zwaar verdiept in alpha en merced/itanium etcetc. Er zijn veel kernel patches voor die procs geweest; linux draait zonder meer op itanium. Dus ik denk dat Linus weet waar hij het over heeft.

Xeon staat wel degelijk aan de top, nl bij SpecInt.

Verder heeft dahakon volledig gelijk, intel wil(de) EPIC de standaard maken, ook voor pc's (nadat ze eerst de high performance sector zouden hebben uitgemolken).

[Olaf van der Spek]

Recompilen kost toch geen miljarden?

[Jit]

Om een 32-bit app voor een 64-bit proc om te zetten is iets meer nodig dan alleen een recompile. Veels te veel software is slecht geschreven; assumpties over hoeveel bit een bepaald type is bijv.
Om dit alles uit te zoeken, zullen de bedrijven veel werk moeten verrichten om zeker te zijn dat hun app 64-bit clean is. En je kan er van uitgaan dat ze de kosten gaan doorberekenen... enkele miljarden $$$ of EUR is IMHO misschien zelfs een te lage schatting.

[Olaf van der Spek]

De meeste code wordt toch in C(++) geschreven, dus dat hij meer/minder code hoeft te schrijven klopt niet.

[Bobco]

Het gaat dan ook om de grootte van de executables die de compilatie oplevert. Als dat inderdaad zoveel groter is voor precies dezelfde source, dan moet de instructie cache stukken groter zijn. Het betekent ook dat je systeembus x% meer aan data moet kunnen transporteren om hetzelfde te kunnen blijven doen.

[Olaf van der Spek]

Vaak heb je weinig code die veel data verwerkt. Dat de code dan groter is maakt niet uit.

[Skyclad]

Wel moet er bij vermeld worden dat Torvalds momenteel in dienst is van Transmeta. Deze processorfabrikant is aanhanger van het :x86-64-platform van AMD

Daarentegen als het door de C'T wordt bevestigd lijkt mij het er niet toe doen wie het naar buiten brengt, dit is tenslotte belangrijk om te weten voor mogelijke klanten.

[PowerFlower]

Wat hij zegt is sowieso goed beredeneerd. Dit is alleen een noot voor de volledigheid. Soms kan dat veelzeggend zijn (onderzoeken naar de kosten van een OS in opdracht van MS kun je wantrouwen), bij dit verhaal is het alleen een kanttekening. Maar misschien heb ik wel te veel de nijging Linus op z'n woord te geloven

[TheGhostInc]

Zonder Linus aan te vallen, komt het maar zelden voor dat iemand van een bedrijf niet een beetje hangt naar het eigen bedrijf, zeker prominente figuren hebben vaak de bedrijven voor het uitkiezen en zitten vaker bij een bedrijf dat ze zoiezo al waarderen.

Ik snap echter niet waar Linus zich druk over maakt, executables zijn zelden ranzig groot (lees groter dan een GB) en software optimalisaties zijn continu te maken, de itanium architectuur in z'n geheel heeft er baat bij als er snellere oplossingen voor problemen worden gevonden. Bij x86 wordt de snelheid vooral door extra instructiesets/mogelijkheden toegevoegd, wat dus alleen geld voor nieuwere generaties processoren. De Itanium wordt op dit moment alleen maar sneller.

Maar volgens mij begint de Itanium geaccepteerd te worden, en dan begint het pas te lopen. Het is en blijft een andere markt dan de x86 markt.

* 786562 TheGhostInc

[TheGhostInc]

Helaas, je vergeet even dat een instructie binnen de x86 architectuur soms vele clockcycles bezig is.
Het kan dus best zijn dat je een commando geeft aan de processor die daarvan weer tientallen berekeningen maakt.
Ook is het aantal instructies per clock weer belangrijk, mogelijke clocksnelheid enz. enz.

BTW. sinds wanneer is een 32bit Xeon even snel als een Itanium? In deze benchmark is een Xeon niet snel, al is de Athlon 2,17x sneller.... niks maal 2,17 is nog steeds niks.

[Verwijderd]

Zie ook de reactie van TheGhostInc..

Ik ga zelfs iets verder: het maakt namelijk geen ene ruk uit. In beide gevallen worden dezelfde instructies uitgevoerd, alleen in het ene geval word de set 'uiteindelijk uit te voeren instructies' al in de software zelf samengesteld, in het andere geval doet de CPU dit.

Een voorbeeld.. het proces: het bakken van een brood. Hiervoor zijn in mijn vereenvoudigde model 3 stappen:

1) verzamelen ingredienten
2) mixen ingredienten
3) bakken brood.

Met een 'cleane' architectuur, zoals intel blijkbaar heeft, moet de software deze 3 stappen afzonderlijk aansturen. Oftewel 3 instructies sturen. Bij de minder cleane variant heef de CPU een instructie BakBrood, waarmee in 1 opdracht van de software, een brood gebakken kan worden.

Onderhuids gaat de CPU echter nog steeds hetzelfde doen, hij zal de opdracht BakBrood gewoon omzetten in de 3 logische stappen, simpelweg omdat je die drie stappen wel moet doen om een brood te krijgen..

Voor beide aanpakken is iets te zeggen. Extra instructies in een CPU betekend vaak ook meer componenten, dus meer warmte en een hoger stroomverbruik (en duurdere wafer) .

[Skyclad]

Als de programma's 3x zo groot worden zal het dus ook 3x zoveel instructies nodig hebben voor hetzelfde.

Stel je de 64 bit situatie voor in verhouding tot 32 bit Xeons:
- AMD: 2.5x sneller maar moet 15% meer doen, dus 2.5 / 1.15 = 2.17x sneller
- Intel: 3x sneller maar 3x zoveel werk, dus 3 / 3 = 1, even snel voor een veel hogere prijs

(Getallen heb ik uit mijn duim gezogen, maar het idee is hopelijk duidelijk)

Edit: Overdrijven helpt bij dit soort voorbeelden, vandaar

[Skyclad]

Zoals ik al zei, de getallen heb ik uit mijn duim gezogen. 3x zoveel code betekend ook niet 3x zoveel tijd nodig hebben voor een berekening, het kan meer zijn en het kan ook minder zijn. Maar het zal wel meer tijd kosten dan de 15% meer bij AMD, al was het alleen maar het inlezen van disk (Stel je voor een 100MB Office applicatie die respectievelijk 115MB of 300MB zou worden)

Edit: Had gewoon een voorbeeld nodig.

[Verwijderd]

Het is een raar beest, software-optimalisatie.

Je bouwt extra stappen/lagen in, die aan de ene kant het proces versnellen, maar aan de andere kant vertragen. Bovendien worden je executables groter omdat alle optimalisaties aanwezig moeten zijn.

Just my 2 cents....

[Xellence]

een extra instructie voor het x86 platform in de CPU toevoegen is gewoon opnemen in de tabel van instructies. Van alle oorspronkelijke instructies voor x86 heeft AMD al jaren minder dan 10% echt uitgevoerd in hun cores en de rest wordt geëmuleerd omdat slechts die 10% veruit voor 90% van de tijd gebruikt wordt.

Dat x86-64 weer wél meer echte instructies bevat is niet minder dan logisch en ook hier zullen er al een groot deel van in een tabel staan in plaats echt uitgevoerd on-die. En de toekomst zal het uitwijzen of bepaalde intructies uit het 64bit kamp ook on-die uitgevoerd moeten worden ipv in de vertaaltabel-on-die. Hopelijk heb ik het nu wat ingewikkelder gemaakt

[ANdrode]

Een itanium is op dit moment al een processor die vrij veel stroom (60+ watt voor de versie met kleine cache, 100+ voor de ene met grote cache) verbruikt.
Als dat nog meer wordt vraag ik me af hoe je dat wilt koelen.

[dataworm]

hezik:

Met een 'cleane' architectuur, zoals intel blijkbaar heeft, moet de software deze 3 stappen afzonderlijk aansturen. Oftewel 3 instructies sturen. Bij de minder cleane variant heef de CPU een instructie BakBrood, waarmee in 1 opdracht van de software, een brood gebakken kan worden.

Dus SSE, SSE2 en SSE3 zijn eigenlijk volmaakt overbodig daar hetzelfde ook in software is te bereiken??

[ewasx]

...dezelfde fout maakt als andere RISC-fabrikanten, zoals Alpha...

Itanium is geen RISC processor, en dit is ook niet wat er in het artikel staat. Wat er wel staat is dat intel met de Itanium dezelfde fouten aan het maken is als de RISC producenten 15 jaar geleden aan het maken waren. De fout is volgens Linus dat ze een mooie schone architectuur proberen te maken, terwijl volgens hem de praktijk uitwijst dat dat niet beter is dan een x86 architectuur, omdat bepaalde minder mooie dingen toch moeten gebeuren, en je ze dus maar beter vanaf het begin in het ontwerp kan integreren.

[Bufiku]

Ik ben het eens dat het in dit "onderzoek" appels met peren vergelijken is. SAP is een zeer database-intensieve applicatie, en wat minstens zoveel effect op de resultaten heeft is het type database. Als we dan eens kijken wat ze hier gebruiken:

HP ==> HP Tru64 Unix 5.1B ==> Oracle 9i

IBM ==> AIX 5.2 ==> DB2 UDB 8.1

Nec ==> Windows Server 2003, Datacenter Edition ==> SQL Server 2000 EE 64-bit

Compaq ==> Tru64 Unix 5.1 ==> Oracle 8.1.6

Linkje naar resultaten

Dan zie je dat er echt volkomen willekeurige systemen met elkaar vergeleken worden.

Overigens zie ik ook de ranking op die website niet terugkomen, hoe ik ook sorteer. Ik vraag mij dan ook af of deze posting van Heise.de niets meer is dan een kapstokje is om de Itanium eens flink te bashen. Ik kan mij voorstellen dat Larry van Oracle dit ook een leuk onderzoek zou vinden, zijn database staat bovenaan (5 van de top 5 als je sorteert op dialog steps per hour).

Ik denk dat het onderzoek van SAP meer bedoeld is als indicatie voor gebruikers welke systemen welke prestaties geven.

[edit: typefoutjes]

[MarcieMars]

Als intel met een 64-bits extensie van de x86-32 bits set komt, dan zou het mooi zijn als ze met AMD meededen... Anders hebben we weer een situatie met 2 verschillende 64bits instructie sets.

Intel zal hier waarschijnlijk mee wachten. Eerst kijken wat de opteron/athlon-64 doet. Als ze nu al zoiets uitbrengen helpen ze hun eigen itanium om zeep...

Het worden spannende tijden!

[LordMithril]

dat is dus ok de reden waarom intel met de itanium doorgaat..
ze hebben er teveel geld in gestoken.. dat moeten ze eerst terug krijgen voordat ze iets anders gaan introduceren (wat dus beter is)
althans.. zo zie ik t.

[Verwijderd]

Ik denk dat zulke onderzoeken cassified worden gehouden. Stel je is voor dat dat wereldkundig wordt.

Als er iemand is op OS gebied die het overzicht heeft, is het Linux. En als deze persoon een dusdanig statement geeft, dan heeft Intel echt een probleem. En dat er een extra opmerking geplaatst wordt dat hij momenteel in dienst van AMD is, is niets mee. Het zegt niets. Het is meer een kwestie van netjes verlden van de de feiten. Ik kan me niet voorstellen dat Linus zijn reputatie door een dergelijk uitspraak ter discussie zou stellen.

[Verwijderd]

In dienst van Transmeta, niet AMD

[Olaf van der Spek]

In dienst van AMD?
Waar heb jij leren lezen?

[RIP-airco]

waarom moet AMD niet meestappen met de Itanium van Intel ?

[RobT]

AMD moet niet meestappen met de Itanium/IA-64 omdat dat niet de standaard is. x86 is wel de standaard, en AMD borduurt daar op voort met x86-64.

[Verwijderd]

Definieer standaard. Het is nl. wel degelijk een standaard, alleen niet zo open als de x86 architectuur.

Volgens jouw redenatie zouden we nu nog steeds met telramen werken, omdat die ten tijde van de 1e computer/berekenaar standaard waren en die computer/berekenaar niet.

[RobT]

Hezik: standaard in gebruikte software en geinstalleerde systemen. Zo moeilijk en ambigu was mijn opmerking toch niet?

Dat met telramen ed is een krom argument dat mijn opmerking op simpele manier probeert af te kraken.
De eerste computers waren compleet nieuw, er was niet iets vergelijkbaars dat iedereen al had.
Probeer maar eens een nieuw soort auto te maken waar een nieuwe infrastructuur voor nodig is (bv op rails).

Ik zei het hieronder ook al ergens:
Zoals Jerry Sanders III al zei: waarom zou iedereen al zijn software voor miljarden opnieuw gaan compilen zodat Intel de enige cpu leverancier kan gaan zijn?

Cafe-het-kelderke, waarom zou x86 aan zijn maximum zitten? Nonsens.

[Verwijderd]

en als X86 aan zijn maximum zit dan wat ???? bouwt AMD eff een nieuwe processor.. JA DAAAAAAAAAAAAAAAAAG te weinig tijd.

[NBK]

"Het enige wat in de Itanium goed is, is dat de processor in staat is om grote hoeveelheden geheugen te adresseren, "'de enige grote fout die in de x86-architectuur zit", aldus Torvalds"

[TD-er]

Toch wel leuk dat Linus T. een verwijt maakt dat bepaalde instructies op een CPU meer in software gedaan worden dan in hardware. De Crusoë CPU die door Transmeta bedacht is, doet eigenlijk alles in software en kan vrijwel geen x86 instructie in hardware uitvoeren.

Neemt niet weg dat 'ie gelijk heeft als je je CPU wilt verkopen als zo snel mogelijk in server-toepassingen.

[TheEagle]

Meneer Torvalds bekijkt de situatie vanuit het oog van een Programeur.

Risc processors hebben een vereenvoudigde instructie set. Wat ze in veel gevallen sneller maakt als een X86 cpu want de cisc worden in veel gevallen niet goed gebruikt.

Alleen een nadeeltje is dus dat blijkbaar de software het ingewikkelde werk moet doen en daardoor groter wordt.

Voor klanten zijn weer andere punten belangrijk dan die waaar Torvalds naar kijkt. Zoals prijs snelheid en niet groote van het programma of programeurs gemak.

[Verwijderd]

Een auto met 100 pk gaat op de weg harder als een boot met 100 pk op het water.

Appels met peren vergelijken dus.
De test is mijn inziens hooguit indicatief.

Makaman.

[lintux]

Hoewel de Itanium niet de snelste was

Hoort dat een verrassing te zijn dan? Ik kreeg zelf bij het lezen van de headlines hier meer een "DUH" gevoel.

Het enige wat in de Itanium goed is, is dat de processor in staat is om grote hoeveelheden geheugen te adresseren, "'de enige grote fout die in de x86-architectuur zit", aldus Torvalds.

Linus, in je hok! Kijk eens goed naar wat technische details van de x86. Waarom lijkt het allemaal nog zo veel op de 8088 van zo'n twintig jaar geleden? Omdat Intel het begrip "Backward compatibility" wat overdreven opgevat heeft. Met een schone lei beginnen (wat ze met de Itanium eindelijk gewaagd hebben) is helemaal niet verkeerd. Jammer voor ze dat de Alpha duidelijk nog steeds beter is.

Tsja, Intel hè...