PathScale AMD64-compiler levert 40 procent prestatiewinst

Op de site van PathScale staat het bericht dat zijn nieuwe AMD64-compiler tot zo'n veertig procent prestatiewinst oplevert op Opteron-servers die Linux draaien. De technologie waar de PathScale compilersoftware op is gebaseerd komt van SGI en wordt gezien als een van de beste op compiler-gebied. Volgens een PathScale-woordvoerder is er grote interesse naar een complete 64-bit compiler voor Linux-clusters gebaseerd op de Opteron, en het bedrijf zou met deze compiler-suite aan die vraag voldoen. In verschillende benchmarks blijkt de PathScale-compiler sneller dan die van concurrerende bedrijven, waarbij er een balans is tussen zowel floatingpoint- als integer-berekeningen. Met de AMD64-compiler zou de machtsverhouding op de high-end 64-bit markt een stuk in AMD's voordeel uit kunnen gaan vallen:

California based PathScale, which develops technologies that increases the performance and efficiency of Linux clusters, has announced AMD64 compiler support. The company claims that its 64-bit version for AMD Opteron-based Linux servers are the highest performing by a margin of up to 40%.

[...]PathScale claims that in both floating point and integer intensive benchmarks, its compilers substantially out-performed its competing counterparts. It also says that these compilers deliver balanced performance as measured by SPEC benchmarks and real application code.

Reacties (19)

[TD-er]

The company claims that its 64-bit version for AMD Opteron-based Linux servers are the highest performing by a margin of up to 40%.

Dat laatste vind ik vrij apart geformuleerd, om het maar voorzichtig uit te drukken.
Ik zou wel eens real-world toepassingen willen zien waarbij je echt een wezenlijk verschil haalt.
Het zou namelijk best zo kunnen zijn dat deze compiler voor een hele specifieke toepassing inderdaad 40% snellere code levert, terwijl de rest mogelijk zelfs langzamer is dan bij bijv GCC.

Kijk het is dus niet zo dat het niet mogenlijk zou zijn, bijv. omdat de AMD64 een stuk meer registers heeft, maar een stukje als dit zegt dus net niets.

[Atmosphere]

Er staat niet veel anders dan dat je op een Opteron gebasseerde linuxserver prestatie verbetringen tot 40% mag verwachten. Niets vreemd aan behalve het getal voor the '%'-tekentje

Uit de context in het verhaaltje kan je dan halen dat het een compiler betreft en dat ze vergelijken met meerdere concurenten. Het is dus niet per definitite de vergelijking met GCC waar die 40% voor geldt.
Hiervoor geldt wel dat je alles opnieuw zou moeten compilen met PathScale compiler.

Het leuk aan dit hele verhaal is dat bij lange na niet alles uit de opteron gehaald wordt op het moment. En dit is eigenlijk dus een zeer gunstige ontwikkeling voor AMD aangezien er andere compiler-producenten even beschaamd naar beneden kijken. Deze zullen vast snel volgen waardoor de acceptatie van de x86-64 weer een flinke zet kan krijgen.

[Verwijderd]

Tja, als een winkel zegt "tot 40% korting!" lijkt het me vrij duidelijk wat ze daarmee bedoelen. Het klinkt wat beter dan 0-40% korting, en daar komt het over het algemeen toch op neer.
Je zal nooit een compiler kunnen schrijven die bij alles even veel voordeel heeft boven andere compilers aangezien er uit simpele code (die geen gebruik kan maken van de voordelen van x86-64) nu eenmaal niet meer te persen valt dan bestaande compilers al doen.
Ik vind dus dat je een beetje loopt te zeuren over iets dat je heus wel begrijpt. Heb je het misschien niet zo op AMD of SGI dat je deze open deur intrapt?

[TD-er]

Heb je het misschien niet zo op AMD of SGI dat je deze open deur intrapt?

Nee hoor, als de chipset voor de AMD64 zonder noemenswaardige problemen met vrijwel alle kaarten samenwerkt en de software die ik zal gebruiken minstens net zo goed (snel) werkt als op de concurrerende processoren, zal ik zeker overwegen zelf een AMD64 aan te schaffen.
Mijn (helaas) beperkte ervaringen met SGI zijn ook positief, dus dat is het ook niet

[AlterEgo]

The Company claims......
Dat betekent dat je beter een iets onafhankelijkere bron de vergelijking tussen compilers kan laten uitvoeren.
Er is bekend dat de Intel C Compiler (ICC) ook hele snelle code voor de 64-bits AMD processor schrijft.

Ik neem niet aan dat PathScale deze compiler free (als in bier en als in speech).
ICC kost ook geld, maar voor de thuisgebruiker is in een gratis licentie voorzien.

[komkommer]

kan je deze compiler nou ook als 'gewone' consument gebruiken?

en zo ja, heeft het ook een groot verschil op een desktop linux computer?

[Confusion]

Je kan hem op een AMD64 gebruiken, ongeacht wie je bent.
Wat je bedoeld met een 'desktop linux computer' is me niet duidelijk, maar als jij thuis een Opteron als desktop gebruikt, ja, dan genereert deze compiler dus snellere code voor applicaties die aan 'high performance computing' doen. Dat zullen er niet veel zijn.

[Verwijderd]

en met een athlon 64 3200+

[Countess]

hoezo alleen linux?
een compiler heb je ook nodig als je windows programams maakt.
en op the register hadden ze het ook over win en unix bv.

[Verwijderd]

Een compiler komt waarschijnlijk het best tot zijn recht als het operating system (en de C libraries, en de hardware drivers) er ook in gecompileerd is.
Linux kan je makkelijker 'even opnieuw compileren' dan Windows of de meeste closed-source Unices.
Vandaar, vermoed ik.

[PipoDeClown]

waarschijnlijk bedoelen ze dat compileren 40% sneller is als gcc?

Please visit here soon to learn about the performance of the PathScale Compiler Suite.

[cybermans]

zeker niet

het boeit heel wat minder hoelang een compiler er over doet om zijn taak te volbrengen. De uitgebraakte files worden er dus mee bedoeld. GCC is trouwens niet de meest snelle compiler maar dat soort dingen houd je toch.

[voodooless]

Interessante ontwikkeling! Nadelen zijn er echter wel: Het is niet opensource, niet gratis en de echte resultaten moeten we nog afwachten. Weet iemand al van prijs voor dit geintje?

Ben beniewd naar de SPEC benchmarks. Ben ook benieuwd hoe compatible de compiler is met de verschillende linux appicaties en de kernel. Ja, er staat dat het compatible is met gcc.. maar in hoeverre dat echt klopt is altijd nog maar af te wachten.

[Verwijderd]

Ben ook benieuwd hoe compatible de compiler is met de verschillende linux appicaties en de kernel.

Ik zou deze compiler nooit inzetten om de kernel te compileren. Zelfs al zou je daar een prestatiewinst halen van 100%, dan merk je dat nauwelijks, omdat normaal gesproken de kernel vrijwel geen cpu-tijd verbruikt. Dit weegt niet op tegen mogelijk compatibiliteitsproblemen. Waar deze compiler wel heel geschikt voor is, is voor echt rekenintensieve toepassingen (technisch/wetenschappelijk). Daar valt veel winst te behalen door een goed compilerontwerp.

[packman]

Als je scheduling en memory managment een pak performanter gaat ga je dat zeker en vast WEL merken. Maar ik geef je wel ergens gelijk, een kernel compilen kan wel eens gevaarlijk zijn - zeker voor productiemachines, gewoon omdat de huidige kernel eigenlijk bijna enkel met GCC gecompiled wordt tot nu toe. Voor een desktopgebruik thuis zou ik dat wel direct proberen darentegen

[Verwijderd]

Ik neem aan dat de 64 ook gewoon 2 ALU's heeft en eentje voor floats geschikt is. En als ze een slimme manier hebben uitgevonden om die balans tussen die twee uit te knutselen kan het idd rap gaan ja. Maar dan maar net de vraag hoe vaak die 40% verbetering gehaald wordt. Het zou nog goed de helft van het verschil dus 20% kunnen zijn en zelfs dat al is niet mis zou ik zeggen.
Daar zal een tweaker toch wel even tegenaan moeten tweaken om dat er ook zonder extra koeling eruit te kunnen halen.

[Parody]

Nou, qua interne werking van de execution units is de K8 vrijwel gelijk aan de Athlon, op het 64-bits gedeelde en de extra registers na. De truuk is dus ook om goed gebruik te maken van die extra's.

Uiteraard zijn er meer effecten te merken. Zo is geheugentoegang goedkoper dan op een P4 of een Athlon (lagere latency), en heb je een andere (in principe grotere) hoeveelheid cache tot je beschikking. Dit zijn allemaal dingen waar een compiler rekening mee moet houden.

Een compiler die goed gebruik weet te maken van de bovenstaande dingen zal zonder meer extra performance uit de nieuwe architectuur weten te halen. Qua scheduling van de instructies zal er niet veel winst te halen vallen, want ik neem aan dat de dames / heren dat al bij de Athlon geleerd hebben. Nu alleen GCC nog...

edit:

Nog even op de AMD-site gekeken. Een K8 kan theoretisch 3 integer-operaties, 3 adres-generatie operaties en 3 FP-operaties (FADD (optelling), FMUL (vermenigvuldiging), MISC (overige)) per tik starten. De integer-operaties zullen gewoonlijk in 1 tik afgelopen zijn, maar de FP-opdrachten kunnen langer duren. Verder zijn integer en FP pipeline onafhankelijk. Al deze dingen zijn volgens mij hetzelfde als bij K7, alleen kan een K8 ook 64-bits integer verwerken en heeft-ie meer registers.

[Verwijderd]

Maar is die 40 % ook wel genoeg voor de brute kracht van een Itanium(2)

[Verwijderd]

Sinds wanneer is de opteron tegenover de Itanium 2 gepositioneerd?