[C/C++] Wat is de beste compiler? *

[Verwijderd]

Ik heb zitten rondneuzen op het internet, maar nergens iets gevonden over welke compiler nu eigenlijk de beste is?

Ik bedoel hiermee een soort vergelijking van een benchmark op verschillende compilers (gcc/mingw/msvc/bcc/...) en dit met een aantal parameters zoals grootte compiled bestand, snelheid van de compiled versie (en misschien snelheid van compilen).

Kan er iemand mij hieruit helpen?


PS: 't is dat ik gehoord heb dat GCC beter is dan MSVC ... Maar ik wil 100% zeker hiervan zijn daarmee.


Met dank

[curry684]

Comeau.

[Robtimus]

javac is de beste

Volgende keer even in de tag je taal zetten, bv "[C Compilers] Welke is beste?"

[curry684]

igmar schreef op 12 maart 2004 @ 14:54:
En het nut van dit topic is ? Die gegevens varieren per versie, per platform en per code. Is is gewoonweg geen 'beste versie'.

Ik vind dat een boute uitspraak eigenlijk. GCC en Comeau bijvoorbeeld zijn beiden platformonafhankelijk, en kunnen dus enkel op compilerkwaliteit concurreren. En wie houdt zich het beste aan standaarden? Wie produceert de minste onverwachte errors? Wie produceert gemiddeld de snelste code?

VC7.1 kent bijvoorbeeld nog steeds de immer feestelijke Internal Compiler Error als je gaat stunten met templates, maar is als Windows-native compiler wellicht door OS-specific optimalisaties wel beter voor Win32 applicaties. Ik zie hier best een interessant topic in, maar het moet idd niet de richting opgaan van "ik gebruik deze compiler op dit platform en dat vind ik goed werken", het moet wel een inhoudelijke discussie zijn.

[.oisyn]

Ligt er een beetje aan op welke aspecten je "de beste zijn" wilt kwalificeren

Als het gaat om standaard conformance is er geen twijfel: Comeau zoals curry al zegt. Comeau is overigens geen volwaardige compiler, je hebt nog steeds een C-compiler als backend nodig (waardoor het overigens wel heel breed inzetbaar wordt)

Als het gaat om snelheid dan moet je voor intel gaan. MSVC++ is natuurlijk de keuze voor win32 development, en ik geloof dat dat ook wel een van de snelste compilers is (dus die het snelst compileert, niet die de snelste code reproduceert, hoewel ie wel vaak goed kan meekomen met die van intel).

Verder is gcc ongeveer wel voor elk denkbaar platform beschikbaar en die is bovendien gratis

[Verwijderd]

Voor de x86 (meest waarschijnlijke platform) produceren de Intel compilers over het algemeen veruit de meest optimale code. MSVC is meestal een goede tweede, alleen niet zo conform de standaards. De gegenereerde code van gcc is meestal niet zo heel erg indrukwekkend, maar deze wordt wel steeds beter...

Voor een benchmark, zie bijvoorbeeld: http://www.willus.com/ccomp_benchmark.shtml?p6+s34
Of ga zelf eens: [google=compiler benchmark intel gcc borland]


/me DaZaffiro denkt dat de combinatie Comeau + Intel waarschijnlijk de grote winnaar zal blijken in dit topic...

[Qwerty-273]

Maar vergeet ook niet de OpenWatcam C/C++ compiler voor voornamelijk het Windows-Platform. Wordt tegenwoordig als open source uitgegeven, en zal uitkomen voor het Linux en FreeBSD (een keertje). Ik gebruik deze zelf voor een stukje code die geschreven is voor de Watcom compiler die al tijden niet meer beschikbaar is.

[Glimi]

igmar schreef op 12 maart 2004 @ 17:30:
(...)
Misschien een idee om testcases op te stellen, en de resultaten daarvan in dit topic te verwerken ?

Misschien dat mensen daar tijd in zouden willen steken als je wat minder zou blaffen?

[EfBe]

Was VTune niet de compiler die de snelst executerende code opleverde op x86?

[MSalters]

Ongewtijfeld, als je weet wat voor bakken met geld Intel er tegenaan gooit. Ik geloof dat ze 300+ man aan het werk hebben.

[alienfruit]

Intel C++ Compiler vind ik dus maar niks, heb je gewoon Microsoft Linker e.d. voor nodig Oftewel je moet VS hebben voordat je de compiler kan gebruiken.

[ Voor 26% gewijzigd door alienfruit op 12-03-2004 19:52 ]

[Verwijderd]

Eventjes gelezen... Maar ik kan er echt niet aan uit dat er nergens een up-to-date benchmark is van compilers?

Bij mijn weten zijn er toch niet zo veel?

mingw, gcc, msvc, bcc, watcom...

Natuurlijk als je daar dan nog verschillende versies & platforms gaat in verwerken kom je toch al dadelijk uit op een indrukwekkend aantal.

Die tests op willus.com testen voornamelijk floating point operaties, klopt dit?


Ik weet ook natuurlijk niet hoe moeilijk het is om een compiler te "benchen"... Zoals er gezegd is geweest... Wat is de toepassing enz. Wat moet er juist gebenched worden?

[Verwijderd]

dev c++

[whoami]

igmar schreef op 12 maart 2004 @ 21:48:
[...]


Doe mij een lol en post gewoon niks als je enige doel is mensen af te zeiken en je verder niks hebt bij te dragen.

modbreak:
doe jij mij een lol, en reageer niet eens zo gefrustreerd en agressief.
Glimi heeft gewoon een punt daar. Mensen zijn niet gauw geneigd om te reageren op jouw replies als je zo'n toon blijft aanslaan.

[igmar]

whoami schreef op 12 maart 2004 @ 22:03:
modbreak:
doe jij mij een lol, en reageer niet eens zo gefrustreerd en agressief.
Glimi heeft gewoon een punt daar. Mensen zijn niet gauw geneigd om te reageren op jouw replies als je zo'n toon blijft aanslaan.

Mjah.. Zie m'n initieele topicreport. Ik hou me er verder wel buiten als het zo moet.

modbreak: sollicitaties voor moderator P&W kun je sturen naar drm(at)tweakers(dot)net. Totdat je aangenomen bent kun je ook vrede hebben met dat het huidige modteam geen probleem heeft met dit topic (zoals ik in een PM ook vriendelijk en naar mijn weten afdoende heb toegelicht )

Ik zal de rest van je reacties maar even echt trashen als je ze zo graag weg wilt hebben.

[ Voor 35% gewijzigd door curry684 op 13-03-2004 22:22 ]

[Verwijderd]

Verwijderd schreef op 12 maart 2004 @ 22:01:
dev c++

dev c++ is geen compiler. Dit is een IDE (dewelke bij mijn weten mingw gebruikt).

Is het ook mogelijk dit te staven met cijfers, daar een naampje niet veel bewijs-waarde heeft mijns inziens.

[flowerp]

Er was niet zo heel lang geleden in C/C++ Users Journal een test waarin een groot aantal compilers werd getest op C++ standaard conformiteit.

De grote grap is dat iedereen standaard denkt dat gcc de beste compiler is kwa C++ standaard conformiteit. Namelijk, gcc = opensource = standaard. De volgende gedachte stap wordt dan snel gemaakt microsoft = closedsource = slecht = eigen 'standaarden'.

Conclusie: gcc is beter dan msvc

Echter...

Het blijkt dat MS nu keihard aan het werk is met de standaard conformiteit en dat ze (verassing voor velen) een van de meest conforme c++ compilers hebben met msvc 7.1. gcc is zeker niet de beste, uit mijn hoofd nog niet eens op de 2de plaats.

Kwa snelheid van de gegenereerde code is overigens de intel compiler een van de beste, hoewel op dat gebied msvc 7.1 ook al dichterbij komt.

offtopic:
als je snelle compile tijden wil moet je overigens helemaal geen C++ gebruiken maar bv delphi, een compiler daarvoor kan miljoenen regels in enkele seconden compileren

[mbravenboer]

flowerp: Namelijk, gcc = opensource = standaard.

Tja, wie dat denkt moet dat lekker zelf weten, maar het slaat natuurlijk nergens op . Met name GNU producten hebben het nog weleens moeilijk met het zich beperken tot een standaard. Het cynische is dat ze door hun algemene toepassing vanzelf standaard worden. Ook andere compilers ondersteunen de GCC extenties.

als je snelle compile tijden wil moet je overigens helemaal geen C++ gebruiken maar bv delphi, een compiler daarvoor kan miljoenen regels in enkele seconden compileren

En daarom moet je ook kijken wat een compiler doet. De snelste compiler doet helemaal niets. Java wordt bijvoorbeeld ook vrij snel gecompileerd naar bytecode, maar er wordt in feite alleen maar code gecontroleerd en wat identifiers absoluut gemaakt. De runtime interpreteert de resulterende bytecode en JIT wordt er eventueel nog wat echt interessante dingen gedaan door Hotspot compiler.

[Verwijderd]

flowerp schreef op 12 maart 2004 @ 22:25:
Het blijkt dat MS nu keihard aan het werk is met de standaard conformiteit en dat ze (verassing voor velen) een van de meest conforme c++ compilers hebben met msvc 7.1.

Al snapt GCC wel dat er in de POSIX standaarden staat dat programma's errorcodes terug kunnen sturen.

void main

[flowerp]

Verwijderd schreef op 12 maart 2004 @ 22:44:
[...]

Al snapt GCC wel dat er in de POSIX standaarden staat dat programma's errorcodes terug kunnen sturen.

void main

Is het echt -kunnen-? I rest my case

[flowerp]

mbravenboer schreef op 12 maart 2004 @ 22:32:
[...]

Tja, wie dat denkt moet dat lekker zelf weten, maar het slaat natuurlijk nergens op .

100% mee eens. Maar je moest eens weten hoe veel mensen dat denken. Laatst sprak ik nog een jongen die 5de jaars AIO Informatica is en die precies dat dacht. Ik heb hem als hbo'er zijnde maar even uit die droom geholpen

Wat overigens ook zo is, dat nu zo'n lange tijd na het bekend maken van de C++ standaard (1998) er nog steeds geen 100% conforme compiler is. Vooral dat export keyword wil maar niet lukken. (had de EDG compiler niet een beta hiervoor?)

[Verwijderd]

flowerp schreef op 12 maart 2004 @ 22:52:
Is het echt -kunnen-? I rest my case

Verklaart uw nader

[EfBe]

alienfruit schreef op 12 maart 2004 @ 19:51:
Intel C++ Compiler vind ik dus maar niks, heb je gewoon Microsoft Linker e.d. voor nodig Oftewel je moet VS hebben voordat je de compiler kan gebruiken.

Ja duh Het is een vs.net plugin

De linker heeft IMHO niet zo'n invloed op de snelheid van de executable, het enige dat het moet doen is er 1 binary van bakken.

[flowerp]

Verwijderd schreef op 12 maart 2004 @ 23:06:
[...]

Verklaart uw nader

Het was dus inderdaad een beetje als grapje bedoeld, maar omdat jij zegt -kunnen- is dat wat anders als -moeten-. De MSVC signature van main() -kan- een return code terug geven (namelijk int main() bestaat) maar -hoeft- dit niet (void main() bestaat ook, dan geeft het systeem altijd een vaste code terug)

[MSalters]

EfBe schreef op 12 maart 2004 @ 23:11:
[...]

Ja duh Het is een vs.net plugin

De linker heeft IMHO niet zo'n invloed op de snelheid van de executable, het enige dat het moet doen is er 1 binary van bakken.

Dat was in het verleden zo. VS.NET heeft met LTCG dat veranderd, en er zijn meer compilers die IPO doen tijdens de link step.

[MSalters]

flowerp schreef op 12 maart 2004 @ 22:56:
[...]
Wat overigens ook zo is, dat nu zo'n lange tijd na het bekend maken van de C++ standaard (1998) er nog steeds geen 100% conforme compiler is. Vooral dat export keyword wil maar niet lukken. (had de EDG compiler niet een beta hiervoor?)

Ik heb die EDG compiler, en die werkt gewoon - zelfs op mijn onrealistische testcases ( Koenig lookup over translation units, herhaald, zodat je een template uit x moet instantieren om er een uit Y te istantieren om er een uit x ... )

[ACM]

Is het trouwens niet ook zo dat een compiler ook voor bepaalde toepassingen beter of minder geschikt is? Dus dat het niet alleen van het platform en de "eisen" afhangt (betere standards-compliance, betere portability, etc).
Ik weet iig dat er bij een gebruiker van een groot cluster de Portland Group compilers werden/worden gebruikt, vast ook deels omdat ze nog geregeld met Fortran werken.

En trouwens, "de intel compiler" heb je geen VS.net voor nodig, althans, niet voor elke versie De Linux-versie doet het echt prima zonder VS.net

[Zoijar]

VS.NET2003 werkt hier prima, standaard compliance is (eindelijk!) wel ok nu. Genereert ook wel snelle code met /G7, inlined functies tussen object files, etc.

Comeau + Intel lijkt mij ook de ideale combinatie. De taal ondersteuning van Comeau, en dan de code snelheid van intel. Hoewel op een windows platform VS7.1 misschien toch wel beter/makkelijker is.

De "beste" compiler is moelijk te zeggen lijkt me, ze zijn allemaal "best wel goed".

ACM schreef op 13 maart 2004 @ 13:08:
Is het trouwens niet ook zo dat een compiler ook voor bepaalde toepassingen beter of minder geschikt is?

Of een taal Je kan je wel blindstaren op "de beste" C++ compiler, maar misschien kan je wel beter een of andere parallele taal gebruiken voor je toepassing en een vage onbekende compiler.

[ Voor 32% gewijzigd door Zoijar op 13-03-2004 14:25 ]

[flowerp]

Een geheel nieuwe(?) tak van sport is overigens optimizen voor power consumptie ipv voor performance. Dit is nu voornamelijk van belang in de embedded wereld, maar als ik zo kijk naar de consumptie van desktop systemen zou het mischien geen slechte zaak zijn als dit ook daar zou worden toegepast.

[EfBe]

flowerp schreef op 13 maart 2004 @ 15:40:
Een geheel nieuwe(?) tak van sport is overigens optimizen voor power consumptie ipv voor performance. Dit is nu voornamelijk van belang in de embedded wereld, maar als ik zo kijk naar de consumptie van desktop systemen zou het mischien geen slechte zaak zijn als dit ook daar zou worden toegepast.

Alles op een desktop wat power vreet is virtual: filesystem, memory. Ergo: je kunt dus niet weten of iets uit memcache komt of vanaf het filesystem, je weet ook niet of een mempage in werd geswapped of niet.

Ik begrijp dus ook niet echt wat je bedoelt.

[flowerp]

EfBe schreef op 13 maart 2004 @ 17:43:
[...]


Ik begrijp dus ook niet echt wat je bedoelt.

Mischien ben ik zelf wel te dom of het goed te begrijpen. Ik heb echter wel kennis van traditionele compiler optimalisaties. Nou, een vriend van me is voor zijn afstudeer werk bezig om een aantal voor power efficiente constructies als optimalisaties aan een compiler toe te voegen. Ik weet er het fijnen niet van, maar volgens mij is het iets in de trend dat het bekend is voor elke instructie hoewel power die kost. Zoals je weet kun je een gegeven constructie (bv in intermediate code) op meer dan 1 manier naar assembly vertalen. Je probeert traditioneel dan die set van instructies toe te passen die de meeste performance winst geeft. Meestal komt dat er op neer zo min mogelijk instructies te gebruiken. Nou, die alternatieve aanpak is dus om mogelijke (allemaal semantisch correcte vertalingen) tegen elkaar af te zetten tijden compile time en daarvan de meest optimale kwa power te kiezen. Mischien dat een bepaalde adressing mode erg veel performance winst geeft voor een bepaalde situatie, maar dat een (mogelijk langzamere) andere mode minder power kost. Of, dat een bepaalde serie van instructies goedkoper is in termen van power use omdat de FU's toevallig dicht bij elkaar liggen, of....

Effin, mischien begrijp je dat er mogelijkheden en overwegingen zijn. Zoals gezegd, het fijne weet ik er absoluut niet van en mischien is het bovenstaande wel onzin. Ik zal het er nog eens met die persoon over hebben. (hij zou als het goed is nu ongeveer klaar moeten zijn, dus ben benieuwd wat het gewoden is )

[alienfruit]

Staat gewoon stom dat je perse VC++ nodig hebt om Intel C++ Compiler te kunnen gebruiken. Het zit namelijk bij Borland CBuilderX

[.oisyn]

EfBe schreef op 12 maart 2004 @ 18:13:
Was VTune niet de compiler die de snelst executerende code opleverde op x86?

Nee, VTune is een code profiler van intel

---

mbravenboer schreef op 12 maart 2004 @ 22:32:
En daarom moet je ook kijken wat een compiler doet. De snelste compiler doet helemaal niets. Java wordt bijvoorbeeld ook vrij snel gecompileerd naar bytecode, maar er wordt in feite alleen maar code gecontroleerd en wat identifiers absoluut gemaakt. De runtime interpreteert de resulterende bytecode en JIT wordt er eventueel nog wat echt interessante dingen gedaan door Hotspot compiler.

Wat ik overigens vrij frappant vind is dat de standaard compiler uit de SDK relatief langzaam is. VJ++ (ja, zeg maar niets ) compileert een vrij groot project in slechts enkele seconden, terwijl javac daar toch een heel stuk langer over doet.

---

flowerp schreef op 13 maart 2004 @ 11:24:
[...]


Het was dus inderdaad een beetje als grapje bedoeld, maar omdat jij zegt -kunnen- is dat wat anders als -moeten-. De MSVC signature van main() -kan- een return code terug geven (namelijk int main() bestaat) maar -hoeft- dit niet (void main() bestaat ook, dan geeft het systeem altijd een vaste code terug)

Behalve dan dat void main () niet mag volgens de standaard Een returnstatement in main is echter wel optioneel

---

flowerp schreef op 12 maart 2004 @ 22:56:
[...]

Wat overigens ook zo is, dat nu zo'n lange tijd na het bekend maken van de C++ standaard (1998) er nog steeds geen 100% conforme compiler is. Vooral dat export keyword wil maar niet lukken. (had de EDG compiler niet een beta hiervoor?)

export is in feite ook vrij nutteloos. MS heeft aangegeven het voorlopig iig nog niet te willen implementeren, aangezien er niet echt bepaald voordelen aan zijn, en het wel een enorm werk is om het te implementeren. De voordelen wegen dus bij lange na niet op tegen de nadelen (en veel vraag uit de community is er ook niet echt)

[ Voor 123% gewijzigd door .oisyn op 14-03-2004 00:13 ]

[Verwijderd]

Wanneer ik vroeg achter snelste compiler was het niet het compilen (en linken) itself, maar eerder diegene die het snelste programma levert...

Als ik goed begrepen heb uit bovenstaande posts is dit Intel C++ op Windows (betalend) en gcc op Linux (free)

Klopt dat zo een beetje?

[.oisyn]

Je moet het niet onderverdelen op basis van OS maar op basis van architectuur. Linux draait bijvoorbeeld ook gewoon op de x86, volgens mij werkt de intelcompiler ook onder linux, dus dat is in beide gevallen de snelste compiler.

Gcc ondersteund echter nog veel meer processoren dan alleen de x86

[Soultaker]

En bovendien draaien zowel Windows als Linux (maar vooral de laatste) ook nog op een aantal andere architecturen dan IA-86.

En om hier ook nog even over te zeiken:

Verwijderd schreef op 12 maart 2004 @ 22:44:
Al snapt GCC wel dat er in de POSIX standaarden staat dat programma's errorcodes terug kunnen sturen.

In traditionele C-code wordt die code vaker met exit(int) teruggegeven dan via een return statement vanuit main, zeker als het om een foutmelding gaat. Daar hoeft main() dus helemaal geen int als return type voor te hebben.

[ Voor 66% gewijzigd door Soultaker op 15-03-2004 02:08 ]

[MSalters]

Zoijar schreef op 13 maart 2004 @ 14:23:
VS.NET2003 werkt hier prima, standaard compliance is (eindelijk!) wel ok nu. Genereert ook wel snelle code met /G7, inlined functies tussen object files, etc.

Comeau + Intel lijkt mij ook de ideale combinatie. De taal ondersteuning van Comeau, en dan de code snelheid van intel. Hoewel op een windows platform VS7.1 misschien toch wel beter/makkelijker is.

Intel is net zoals Comeau een EDG-gebaseerde compiler. Alleen is de Intel product cycle wat langer, gezien de hoeveelheid optimziers e.d. die allemaal getest moeten worden met elke nieuwe release e.d. . Over niet al te lange tijd zou je dus ook van Intel een even conformant compiler mogen verwachten, alhoewel Intel wel aangaf dat export nog tricky is. Ze twijfelen o.a. hoe ze daar goede tests voor moeten bouwen, en Intel heeft op dat gebied hogere eisen dan Comeau.

[Verwijderd]

Buiten het feit dat je meestal niet echt de keuze hebt mbt welke compiler je gebruikt, is het misschien ook handig te kijken of een compiler goede warning/error messages uit spit. Sommige compilers geven uitmate slechte warning messages terwijl andere juist weer zeer goede uitspitten (de HP_UX of de sun geeft zelfs referenties naar de C++ standaard als je iets fouts doet). Ook belangrijk is de support die bij een compiler wordt geleverd. Stel je vind een bug, word die dan snel gefixed bijvoorbeeld. Dat soort dingen zijn volgens mij zelfs belangrijker dan de performance van een compiler.

[unclero]

Mijn favoriete C/C++ compilers op het moment zijn:

1) Borland C++ 5.5 (gratis)
2) LCC-Win32 (gratis)
3) Turbo C++ 1.01 (gratis, maar wel DOS)

En oh, de VS linker is volgens mij (meen ik me te herinneren) gratis, hij zat dacht ik bij mijn Windows95... okay, geen goede vergelijking .. Maar in de strijd om de gratis compiler heeft Microsoft ook de Visual C++ tools (dus niet de studio) vrijgegeven.
.NET Framework SDK
Platform SDK

Ik heb voor Borland gekozen vanwege de WinAPI, de MSVC compatibiliteit en het feit dat hij gratis is, maar niet GNU. En daar ging het mij ook om, omdat ik sommige spullen gewoon gesloten wilde houden. (dat ik vroegah met Turbo C heb gewerkt zal ook meespelen )
Verder zou ik LCC nemen, vanwege het feit dat deze zich wat meer aan de ANSI standaarden houd .

En Turbo C is nostalgie

[Macros]

Als je je source compiled met een GNU compiler is je code ook niet ineens gebonden aan GPL hoor.

[ Voor 8% gewijzigd door Macros op 17-03-2004 20:15 . Reden: Refactor GNU to GPL ]

[MSalters]

GNU != GPL