FPU-performance P4 met diverse compilers vergeleken

Bij Ace's Hardware is een artikel verschenen dat de snelheid van de FPU van de Pentium 4 bekijkt. In tegenstelling tot normale tests wordt bekeken hoe de performance is bij gebruik van verschillende compilers voor de benchmarktool. Er wordt gebruik gemaakt van GCC 3.2, ICC 7.1, VS.NET en VS.NET2003, elk met verschillende optimalisaties ingeschakeld. Zoals uit eerdere tests al is gebleken, is ICC - de compiler van Intel - het snelst in bijna alle gevallen, vaak met een grote voorsprong. GCC, de open-source compiler, levert de minst snelle code op voor de Pentium 4. Volgens GCC-developer Andi Klein is dit de schuld van Intel, omdat het bedrijf te weinig informatie zou vrijgeven:

When you take a look at the gcc 3.3 source code you will notice that gcc 3.3 is able to schedule for K6,PPro/P2/P3,K6,Pentium-Classic,K7,K8 - but not Pentium4.

All -mcpu=pentium4 does is to tweak some instruction costs for particular pentium 4 problems (e.g. lea with factors being rather slow, so it is avoided). Not having a scheduler will especially hurt for floating point code which usually really needs well scheduled code.

One likely reason for this is that Intel does not release enough information to write a good scheduler description. The information in the optimization manual is not enough, it just gives some vague information on what unit or cluster of units an instruction maps to, but nothing detailed enough to actually write a scheduler.

Reacties (21)

[Verwijderd]

waarom geen GCC3.3? Die kon toch juist de pipelines van de verschillende processors op een zo efficient mogelijke manier vullen? Plus dat deze 3dnow(+) en SSE2 ondersteund.

GCC3.2 kan wel, maar volgens mij is het niet helemaal eerlijk...

[sonix666]

Ik ben degene die zo gek is geweest om al die Flops binaries te maken en te benchmarken op mijn overgeklokte P4 systeem.

De reden waarom ik GCC 3.2 heb genomen is omdat ik via de officiele GCC site alleen een gecompileerde versie van GCC 3.2 kon vinden voor Windows. Dat is eigenlijk de enige reden.

Het is niet mijn bedoeling om dit een AMD vs. Intel discussie te maken. Ik heb uit interesse die tests gedaan op mijn thuis PC en de resultaten gepost op het Aces Hardware forum om voor de andere mensen te zien.

Er staan overigens op het forum updated results voor GCC 3.2 met nog wat andere optimalisatie opties.

[Verwijderd]

Is het niet mogelijk om alsnog een test met GCC 3.3 uit te voeren?

Ik ben van mening dat, als er binnen die compiler versie een aantal dingen geoptimaliseerd zijn, die versie met de test moet worden opgenomen. De argumentatie dat deze niet getest is omdat er alleen binaries beschikbaar is niet fair, aangezien de sources van de andere compilers ook niet bekend zijn. Daarmee vervalt in mijn ogen het argument over de sources.
Het gaat er bij deze test immers om hoe snel het resultaat is, niet hoe snel iets gecompileerd word.

[Ploink]

Je kunt hier GCC 3.3 en zelfs 3.4 binaries downloaden:
http://www.thisiscool.com/gcc33_mingw.htm

[sonix666]

Die heb ik gisteren ook al gevonden. Alleen dit zijn helaas nog geen officiele distributies als ik het goed begrijp?

[sonix666]

Als jij de tijd en zin hebt om een compile te maken van GCC 3.3 die gericht is op Windows, dan gaarne. Ik heb daar geen zin in gehad en dus is het GCC 3.2 simpelweg geworden. Ik hoef mijn Visual Studio en Intel C Compiler ook niet te compileren!

[max3D]

/offtopic
For reasons unknown to me kan ik even niet modden. Kan de rest even wakker worden en het postje hierboven van sonix666 opwaarderen naar iets meer dan een schamele 1?
Als grondlegger van de hele discussie op ACE en hier door de tests uit te voeren verdient hij toch wel wat meer!
/offtopic

Hele boeiende tests op zich, maar de conclusie was dat minder. Dat de Intel compiler het best presteert was eigenlijk al bekend; het nieuwe is vooral dat je deze nu ook voor produktiecode kan gebruiken. Oude versies waren 'benchmark compilers' die vooral de SPEC suite erg snel deden, maar verder niet in te zetten waren voor real life code. Die tijd is voorbij; het wachten is nu op ontwikkelaars die over durven schakelen van de MS compiler naar de Intel. Het zijn er nog maar weinig (hoewel niet de minste).

[ANdrode]

When you take a look at the gcc 3.3 source code you will notice that gcc 3.3 is able to schedule for K6,PPro/P2/P3,K6,Pentium-Classic,K7,K8 - but not Pentium4.

All -mcpu=pentium4 does is to tweak some instruction costs for particular pentium 4 problems (e.g. lea with factors being rather slow, so it is avoided). Not having a scheduler will especially hurt for floating point code which usually really needs well scheduled code.

Blijkbaar is er toch naar GCC 3.2 gekeken.

[beany]

Mja, Intel hoeft alleen maar naar de juiste kamer te lopen voor de specs, Microsoft zal er wel voor betalen(ze kunnen het in ieder geval) en GCC staat dus langs de kant te kijken. Misschien toch een nadeeltje als Open Source project zijnde???

[Verwijderd]

Microsoft zal er wel voor betalen

En hun eigen compiler de vuilbak in kieperen zeker??? Dat zou toch erg vreemd zijn, zo kennen we M$ niet .
Volgens mij zou Microsoft eerder hun eigen compiler gebruiken, om zo Intel te dwingen informatie vrij te geven over de beste optimalisaties. Windows is nog steeds het meest gebruikte OS! Mensen zullen niet overstappen naar een ander OS omdat hun P4 onder Windows minder goed presteert, maar ze zullen mss wel een AMDproc kopen. Dus MS zit in de machtspositie .

[Vorlon]

Ik neem aan dat beany bedoelde dat MS wel zal betalen om de volledige specs te krijgen en daarmee wel een scheduler in hun (dus die van MS zelf) compiler te bouwen.

Het enige wat ik kan bedenken waarom Intel dit niet bekent te maakt zou volgens mij kunnen zijn dat of ze iets ingenieus hebben ingebouwd waarop geen patent is aangevraagd of ze iets hebben ingebouwd waar juist wel patent op rust maar dan van een ander.

Tenzij ze op de samenzweertour wil gaan en MS er van gaat verdenken dat ze Intel geld hebben toegeschoven om dit niet allemaal zo vrij te geven. Maargoed, dat lijkt me wel erg vergezocht.

[voodooless]

Leuk om op te merken is dat de AMD procs ook het beste presteren met de Intel compiler. Helaas heb ik van Gcc 3.3 nog weinig benchmarks gevonden. Ben erg benieuwd of ie bij de andere proc's wel extra performance brengt?

[catfish]

het is toch algemeen geweten dat intel al altijd de beste compilers heeft gehad voor gelijk welke taak, beetje nutteloze test lijkt mij zo

dat de AMD ook snelst gaat met intel compiler is wel opmerkelijk, alhoewel dit ook een x86 cpu is en dus vrij logisch

[sonix666]

Juist het tegendeel heb ik bewezen met deze tests. Iedere compiler lijkt zo zijn sterke en zwakke punten te hebben bij ieder van de 8 modules. De Intel compiler is alleen de enige compiler die succesvol vectorisaties op sommige modules weet toe te passen en daar SSE2 code op te genereren. Maar laten we SSE2 buiten beschouwing dan is Intel niet de grote winnaar.

[DrEvil1986]

Waarschijnlijk is intel of gewoon dom, of geven ze express zo weinig informatie. Het is natuurlijk mooi dat je als CPU-fabrikant kan zeggen "op onze cpu's draait alles", maar waarschijnlijk steekt er een marketing truuk achter. Ze willen misscjien geld zien voor hun compile codes. Maar dat gaat dan ten koste van sommige programma's/programeurs, die hun software niet goed kunnen laten lopen op P4's

[Verwijderd]

domste fout die je kan maken. Hoe beter die compilers opgebouwd zijn, hoe meer processors je verkoopt. Die paar compilers die Intel ermee zou kunnen verkopen staat in geen verhouding tot de winsten die ze maken als er opeens 10.000 extra P4's worden besteld door serverbouwers omdat de P4 zo goed presteert met <vulwatin> bv mysql oid.

[Ultraman]

Dit is een beetje onzin omdat je dan nogal jezelf al tegen aan het werken bent. Zonder goede compilers geen goede (snelle) programma's voor je proccessor en daar gaat je deel van de markt. Wat er dan gebeurt weet je zelf

[Verwijderd]

Dat gcc niet al te snelle FPU code produceert is eigenlijk niks nieuws. Zie hier de STREAMS benchmark onder Tru64 UNIX met de DEC c compiler en gcc:

runt: cc -fast
-------------------------------------------------------------
Function Rate (MB/s) RMS time Min time Max time
Copy: 780.1859 0.0272 0.0205 0.0352
Scale: 744.7066 0.0268 0.0215 0.0293
Add: 768.0000 0.0400 0.0312 0.0430
Triad: 767.9736 0.0414 0.0313 0.0469


runt: gcc (v3.0.3) -O3 -DU_ALPHA
-------------------------------------------------------------
Function Rate (MB/s) RMS time Min time Max time
Copy: 399.6014 0.0587 0.0400 0.0898
Scale: 381.0157 0.0602 0.0420 0.0986
Add: 431.1505 0.1496 0.0557 0.4150
Triad: 372.3588 0.0711 0.0645 0.0781

[AJSTempest]

Jammer dat ze Digital Mars niet hebben meegenomen in de reeks. Is de nu gratis opvolger van Zortech/Symantec C++ door Walter Bright. Deze hebben altijd tot de beste compilers behoord in het verleden en ook nu met Digital Mars is het alweer een zeer acceptabele compiler die goed wordt onderhouden.

[Verwijderd]

En je hebt natuurlijk ook nog Open Watcom (http://www.openwatcom.org/), welke vroeger ook een zeer verdienstelijke compiler was.

[Verwijderd]

Oh ja .. en natuurlijk VectorC .. die zijn ook erg goed bezig.