Prestatiewinst AMD64-compiler klinkt veelbelovend

Bij The Inquirer is een sappig bericht verschenen over de prestaties van een nieuwe compiler die overweg kan met de 64-bit instructies van de AMD Opteron. Volgens cijfers vrijgegeven door de Portland Group, de ontwikkelaar van de compiler, is de nieuwe versie van de compiler gemiddeld 34 procent sneller dan zijn voorganger op het Opteron-platform. De prestatiewinst blijkt wel sterk samen te hangen met het type applicatie. In de SPEC2000 floating point benchmark nemen de prestaties toe met maar liefst 375 procent terwijl andere programma's er geen milliseconde sneller op worden. Verwacht wordt dat de nieuwe compiler, die binnen vijf dagen beschikbaar zal zijn, een impuls zal geven aan de aantrekkelijkheid van het Opteron-platform:

Reacties (32)

[BasHouse]

Goed werk van die Portland Group. Eerlijk gezegd vind ik het jammer dat het potentieel van de huidige techniek niet wat vaker wordt uitgebuit. Ik bedoel, de meesten gaan zich liever bezig houden met weer nieuwe dingen dan een product nou es echt uit te ontwikkelen.

[charops]

Goed nieuws dat de compilers voor 64 bit nu echt op gang komen. Ik moet er alleen wel bij zeggen dat een prestatie-winst op een grote, bekende bench-tool me enigszins huiverig doet terugdenken aan een recent 3dmark verhaal ( maar dat is hopelijk hier niet het geval)

[warp]

Een compiler kan geen stukken code weglaten; dan werkt de gecompileerde source code (i.e. software) immers niet meer (in ieder geval niet meer zoals het zou moeten werken); dus voor 3dmark toestanden hoef je hier niet bang te zijn

Edit: @ hielko: 2 zielen 1 gedachte

[Hielko]

Dat is hier niet het geval, want hoe kan je nu een compiler maken die niet exact doet wat de source code zegt? Krijg je leuke programma's als jij als programmeur zegt dat je 3 * 4 wilt doen, en de compiler denkt, nee ik doe 3 + 4 want dat is sneller

[ewasx]

want hoe kan je nu een compiler maken die niet exact doet wat de source code zegt?

Een voorbeeld van vroeger:
Er was ooit een SPEC benchmark kernel die iets deed als:

y = (SQRT(X)/2)^2

die werd door sommige compilers geoptimaliseerd door er y=x/4 van te maken. Het suffe hiervan is natuurlijk dat zo'n berekening in de werkelijkheid nooit zal voorkomen, en dat deze optimalisatie alleen in die compiler zat om met die benchmark een hoge score te behalen. Je kan een compiler dus wel degelijk voor een benchmark optimaliseren.

[Verwijderd]

y = (SQRT(X)/2)^2 = {(1/2)*SQRT(X)}^2 = (1/4)X = X/4

Hierbij valt wel meteen de voorwaarde weg dat X niet negatief mag zijn. De 'optimalisatie' slaat de plank dus mis! Want eigenlijk:

{SQRT(X)}^2 /= X

Tenzij vermeld wordt dat X >= 0

Of tenzij X een imaginair getal mag zijn waarbij de wortel van een negatief getal gewoon mogelijk is bij gebruik van de volgende definitie:

SQRT(-1) = i

Maar dat voert dan denk ik weer veel te ver .

[Verwijderd]

Volgens mij is de enig juiste optimalisatie van dit voorbeeld SQRT(x). Zo'n optimalisatie ligt er echter zo dik bovenop, dat vrijwel alle optimaliserende compilers dit doen zullen.

[0rbit]

Ik ben van mening dat de ontwerpers van de benchmark dan fout bezig zijn. Hulde aan een compiler die de berekeningen desgewenst vereenvoudigd zodat ze veel sneller zijn. Je kunt met niet vertellen dat de makers van zo'n benchmark niet op de hoogte zijn van zulke optimalisaties in compilers.

[Carbon]

"want hoe kan je nu een compiler maken die niet exact doet wat de source code zegt? "

Komt vaker voor dan je denkt
De eerste 100% bugvrije compiler moet nog gemaakt worden.

[hardwareaddict]

Je kunt als compiler heel makkelijk met name op P4 processors of K7 processors niet doen wat je doen moet en toch sneller zijn.

Voorbeeld je gebruikt een 32 bits floating point ipv een 64 bits double. 32 bits float is sneller. Voor de meeste specbenches merkt niemand het, want die zijn toch alleen geinteresseerd in 'hoe lang' het kost en pas na de 5e decimaal gaat 't mis.

Dat is 1 van de bugs overigens in intel c++ die ik vond in wat code die ik compileerde. Ik raakte bits kwijt.

Natuurlijk is het wel kwalijk als je bits kwijt raakt in grote wetenschappelijke berekeingen. Soms leidt dat tot enorm verkeerde resultaten.

Hierbij dient aangetekend te worden dat de meeste methodes toch al de zaak benaderen (omdat het realtime niet benaderd kan worden) dus als dan de intel c++ compiler nog een keer de zaak benadert, dan wordt het vaak toch niet opgemerkt.

De bugs in de compiler worden dan afgewend op andere zaken.


MVG,
Vincent

[__Rza]

[Verwijderd]

Ik zou wel eens willen zien hoe de Opteron/Athlon 64 zich nu meten met Intel's processoren.

[Femme]

Als deze compiler beter presteert dan die van Intel en Compaq zal AMD waarschijnlijk binnenkort wel nieuwe SPEC scores gaan submitten. PGI 4.1 stond niet bekend stond als een super snelle compiler, dus het is de vraag of de snelheidsverbeteringen voldoende zijn om hogere SPECfp scores te kunnen produceren.

[hardwareaddict]

Het is niet te hopen dat portland 'beter presteert' als intel c++ simpelweg omdat de intel c++ zulke buggy code produceert voor gemiddelde software (en zelfs voor veel benchmarks) dat deze niet te vertrouwen valt.

Voor wetenschappelijk gebruik is het momenteel niet mogelijk namelijk om itanium2-madison + intel c++ te gebruiken.

Hoewel dit dus wel de snelste is op de specint/specfpu momenteel.

Wat heb je aan een compiler/cpu combinatie als deze gewoon niet correcte resultaten produceert?

Moet Portland ook zo diep vallen?

Tel daarbij dat ze nooit een deuk in een pakje boter hebben geslagen met hun compilers voor de c/c++ lieden.

Bij fortran ligt dat anders. Daar is niet de compiler de zwakste schakel maar vaak wetenschappers die niet weten hoe ze programmeren moeten.

Die lopen per gewoonte ook nog de loops verkeerd af. Vaak gaan lussen n, n-1, n-2 etc, in plaats van
n, n+1, n+2 etc.

Als gevolg daarvan voorspelt een processor dan verkeerd welke cache lines nodig zijn en kan er minder sequentieel gewerkt worden (enorm snelheidsverschil).

Sun had toen eens een fortran specfpu programmaatje iets anders laten 'optimaliseren' door een compiler en dat programmaatje werd toen factor 7 ongeveer sneller op dezelfde hardware, wat natuurlijk direct naar specfpu werd gesubmit.

MVG

[hardwareaddict]

Het is allemaal nog nietszeggend omdat ze relatieve snelheden laten zien in een beginfase. Ik herinner me veel software die ik geschreven heb die uiteindelijk factor 20 sneller is geworden na oorspronkelijk ontwerp (neem een paar RNGs).

Eerst laat je het ding code poepen uit het jaar 0 dan vergelijk je met een verbeterde versie.

Ze laten niet zien hoe snel het is t.o.v. andere compilers cq de scores in specbench. Ze laten in deze tabellen alleen de scores t.o.v. een jaar 0 versie van hun eigen compiler zien (en ook die jaar 0 versie hebben we niet dus daar weten we ook niet van hoe erg 0 het is).

Het is een nietszeggend marketing bericht met als enige boodschap: "de zwaar inferieure portland compiler wordt geport naar 64 bits opteron en we zijn optimistisch gestemd".

Als ze ook maar sneller waren geweest als GCC dan hadden ze dat wel met koeieletters opgeschreven. GCC overigens voor de nietinsiders is een GRATIS compiler.

[EaS]

Als ze ook maar sneller waren geweest als GCC dan hadden ze dat wel met koeieletters opgeschreven

Niet met koeieletters, maar het is er wel te vinden: GCC 3.3 vs. PGF90 5.0

[hardwareaddict]

specfpu bestaat uit een hele berg applicaties. Ze laten maar een paar er zien. Dus gemiddeld zijn ze vast nog wel langzamer.

de GNU fortran compiler is overigens zo traag dat er niet eens een resultaat van is gesubmit.

hier 1 van de resultaten op specbench. Dan zie je met name de programma namen en hoe WEINIG het bedrijf Portland laat zien eigenlijk. Zelfs met 380% verbetering slaan ze nog niet een deuk in een pakje boter voorlopig. Het is triest

168.wupwise 1600 159 1005 120 1336

171.swim 3100 180 1724 179 1731

172.mgrid 1800 185 975 179 1007

173.applu 2100 223 944 205 1024

177.mesa 1400 104 1341 97.9 1431

178.galgel 2900 193 1501 191 1519

179.art 2600 208 1248 182 1429

183.equake 1300 127 1026 112 1156

187.facerec 1900 152 1246 150 1265

188.ammp 2200 232 948 215 1025

189.lucas 2000 167 1195 153 1308

191.fma3d 2100 195 1076 190 1105

200.sixtrack 1100 250 441 225 489

301.apsi 2600 275 944 274 949

SPECfp_base2000 1070
SPECfp2000 1154

http://www.specbench.org/osg/cpu2000/results/res2003q2/cpu2000-2003042 1-02109.html

[Verwijderd]

Waar die 64bit compiler er duidelijk uitspringt, komt die 5.0 32bit ook aardig mee. Het hangt dus nog niet alleen af van de 64bit performance winst.

[Verwijderd]

wat voor compiler is 't ? C ? C++ ?

[Femme]

PGI compileert Fortran, C en C++ code. Zie voor info www.pgroup.com .

[Mujo]

Fortran...
En www.pgroup.com, anders kom
je bij een of andere grondgraver uit

[Ronald]

SPEC bestaat uit zowel C and C++ software van welke de source vrij beschikbaar is.

[Verwijderd]

Ik meen gehoord te hebben dat heel wat games geprogrammeerd worden onder een C-variant. Als dat zo is, zou dat dan ook een enorme impact hebben op de gameprestaties. Dit verbetert de toekomstperspectieven voor AMDs Athlon64 nog meer!

Correct me if I'm wrong, eigenlijk ken ik niet zo veel van programmeren (yet )

[hardwareaddict]

Portland bericht iets over fortran hier. Niet over C.
Het is wel zo dat de opteron een ideaal gamersplatform is in theorie. 2 dingen nodig. Een goede C++ compilers ervoor en een simpel te gebruiken OS. dus een 64 bits windows versie.
linux draait al 64 bits erop (maar nog niet erg goed, maakt geen gebruik van NUMA voordelen).

[Verwijderd]

De meeste spellen worden geprogrammeerd in C++ (kijk maar naar de half-life SDK)

[hardwareaddict]

Specint is voornamelijk C. Specfpu hier echter is voornamelijk fortran.

[voodooless]

C en C++ zijn geen compilers maar programmeertalen...
Ik vraag me af hoe deze compiler presteert in verhouding tot de x86-64-bit port van GCC, waar AMD ook aan heeft meegewerkt.

[Verwijderd]

Weet iemand hier toevallig misschien op en met welke Operating Systems deze compiler op dit moment werkt? Dat wordt uit het Enquirer-artikel namelijk niet duidelijk.

[hansg]

Het plaatje in het artikel meldt dat dit Suse, dus Linux is.

[RobT]

En toen bleek dat verreweg de meeste instructies van de meeste progjes lijken op sixtrack en swim....

[JeroenB]

Jeetje, eerst nieuws dat er misschien volgende week weer iets gaat komen van AMD en dan nu het nieuws dat er iemand heeft geroepen dat de compiler heel vet wordt! Ik moet toegeven, de feiten liegen er niet om. Alhoewel, welke feiten zijn er nou precies?

[Verwijderd]

hmmm kijk uit naar de desktop versie met XP 64, hopen dat hij 2 gig draaid en niet een berg duiten kost