[C++] Compileersnelheid g++

[Verwijderd]

Heeft iemand nog algemene tips om de compileersnelheid van mijn project wat te versnellen?
Het maakt veelvuldig gebruik van de Standard Template Library en daardoor krijg ik veel typecastfouten. Die fouten wil ik voortaan sneller kunnen verbeteren.

Ik hoef nu geen optimization, ik wil gewoon snel laten compileren !
Tot nu toe heb in de manual van g++ alleen -fsave-memoized gevonden..

Heeft iemand nog nuttige (Makefile.am) tips, of een link naar een andere compiler die brakke code kan genereren in ruil voor snelle compilatie ?

[Pooh]

g++ is aardig snel toch? 'k Snap niet zo goed dat je echt problemen hebt (of je moet elke keer je hele project op nieuw moeten compileren, maar normaalgesproken komt dat niet zoveel voor). Hoe groot zijn je files?

[Verwijderd]

Ik moet hier op werk de komende tijd blijven developen op een oude sun solaris machine, omdat er gewerkt moet worden met oude interface kaarten van eigen makelij.
Daarnaast gebruik ik STL om minder coredumps of segfaults te krijgen, gaat goed, maar die templates compileren een stuk trager en geven veel meer foutmeldingen (wat weer goed is want dat voorkomt runtime problemen). Maar ik wil sneller langs die foutmeldingen komen door wat sneller te kunnen compileren.

Misschien kan iemand een soort development compiler vinden?

[Soultaker]

Poohbear schreef op 18 september 2002 @ 14:32:
g++ is aardig snel toch? 'k Snap niet zo goed dat je echt problemen hebt (of je moet elke keer je hele project op nieuw moeten compileren, maar normaalgesproken komt dat niet zoveel voor). Hoe groot zijn je files?

g++ is echt ranzig traag; zeker wanneer je de Microsoft C++ compiler gewend bent. Ook het compileren van enkele bestanden gaat tergend langzaam. Het vervelende is ook dat je zelfs de meest simpele foutmeldingen (van de klase puntkomma vergeten) pas na secondenlang wachten krijgt.

Helaas ken ik er geen oplossing voor. Zorgvuldig programmeren is het devies, zodat compileren niet vaker hoeft dan strikt noodzakelijk is. Probeer ook meerdere fouten in één keer op te lossen alvorens opnieuw te compileren.

Voor grote builds (van meerdere bestanden dan wel) kan het helpen om meerdere jobs tegelijk te starten, om zo de CPU en beschikbare I/O bronnen beter te benutten. Dat gaat met "make -j4", voor bijvoorbeeld 4 jobs, onder de meeste Unix-varianten. Voor het compileren van afzonderlijke bestanden schiet je hier echter niets mee op.

[Verwijderd]

MAKEFLAGS -j in Makefile.am gezet, hij doet nu meerdere jobs tegelijk maar het is er nog niet sneller op geworden...

[Verwijderd]

Soultaker schreef op 18 september 2002 @ 14:41:
g++ is echt ranzig traag; zeker wanneer je de Microsoft C++ compiler gewend bent. Ook het compileren van enkele bestanden gaat tergend langzaam. Het vervelende is ook dat je zelfs de meest simpele foutmeldingen (van de klase puntkomma vergeten) pas na secondenlang wachten krijgt.

Vlam vlam.

Voor grote builds (van meerdere bestanden dan wel) kan het helpen om meerdere jobs tegelijk te starten, om zo de CPU en beschikbare I/O bronnen beter te benutten. Dat gaat met "make -j4", voor bijvoorbeeld 4 jobs, onder de meeste Unix-varianten. Voor het compileren van afzonderlijke bestanden schiet je hier echter niets mee op.

Een optie die ook nog wel eens wil helpen is -pipe. Normaal worden alle object files als echte temporaries geschreven, zo vermijd je deze disk i/o.

[Sjaaky]

Compilen op een snelle machine en runnen op de trage machine met de interfacekaarten.
Of bepaalde gedeelten van de code compileren op een snelle machine alleen om de syntaxfouten eruit te halen en daarna compileren op de sun solaris.

[Zoijar]

Hmmm ik heb echt geen moiete met gcc op solaris hoor. Source file van over de 1000 regels is vrijwel meteen klaar...

[Verwijderd]

Hierzo ook geen problemen. Ik vind g++ best wel rulen...

[ Voor 0% gewijzigd door Verwijderd op 18-09-2002 17:49 . Reden: typo ]

[.oisyn]

Verwijderd schreef op 18 september 2002 @ 15:15:
[...]


Vlam vlam.

hoezo? Het is gewoon een feit
En gcc is zeker een goede compiler, maar gewoonweg te traag (op win32 iig)

Ik had voor ons gameboy projectje 2 compilers tot mijn beschikking: de gnu c compiler die ARM7TDMI machinecode uitpoept en de compiler van Arm zelf

Bij gebrek aan een binary naar object converter converteerden we dus alle data (graphics en dat soort dingen) naar arrays in C-code. Aangezien dat nogal grote tabellen worden is het handig als dat snel te compileren valt

En waar de Arm compiler er een halve seconde over deed, deed gcc er 10 (!!!) seconde over. Dat is dus echt geen pretje

[Verwijderd]

.oisyn schreef op 18 september 2002 @ 17:54:
hoezo? Het is gewoon een feit
En gcc is zeker een goede compiler, maar gewoonweg te traag (op win32 iig)

En zo worden persoonlijke ervaringen en waardeoordelen alweer feiten, de oorzaak van 99% van alle flames op het internet.

En waar de Arm compiler er een halve seconde over deed, deed gcc er 10 (!!!) seconde over. Dat is dus echt geen pretje

gcc is een portable compiler, je kunt hem zo porten naar andere platforms. Het nadeel van dat geport is dat gcc op sommige platforms trager is dan op het native (*nix) platform. Als je compilers fair wilt vergelijken zul je ze op hun native platforms moeten bekijken, en dan zie je dat er niet zoveel verschil bestaat (tenzij je optimizing aanzet: gcc heeft een veel krachtiger optimizer dan msvc, hij ondersteunt bv. type-based alias detection, en dat kost nu eenmaal tijd).

Dan heb je nog het punt van standard-compliance, en de parsing-tijd die dat met zich meebrengt. Zo kan bv. een compiler die member-templates implementeert nooit sneller parsen dan een compiler die dat niet doet.

[Verwijderd]

Ik ben nu overgegaan op de strategie van Sjaaky, compilen op een snelle machine en zodra ik reference (link)errors krijg (die machine mist een hoop libs) link ik op de oude machine.

[.oisyn]

[nohtml]

Verwijderd schreef op 18 september 2002 @ 18:17:
[...]


En zo worden persoonlijke ervaringen en waardeoordelen alweer feiten, de oorzaak van 99% van alle flames op het internet.

een waardeoordeel is altijd persoonlijk. Volgens jou kun je dus ook geen feiten geven dmv benchmarks.

Fijn, dan noem je het geen feit, maar nog steeds is gcc op win32 langzamer. En door dat te zeggen is het niet meteen een flame

gcc is een portable compiler, je kunt hem zo porten naar andere platforms. Het nadeel van dat geport is dat gcc op sommige platforms trager is dan op het native (*nix) platform.

vandaar dat ik er ook win32 bij zette. Ik lees nu trouwens pas dat ie op een sun bak ontwikkelt (stond niet in z'n startpost). Daar las ik dus net overheen

Als je compilers fair wilt vergelijken zul je ze op hun native platforms moeten bekijken, en dan zie je dat er niet zoveel verschil bestaat (tenzij je optimizing aanzet: gcc heeft een veel krachtiger optimizer dan msvc, hij ondersteunt bv. type-based alias detection, en dat kost nu eenmaal tijd).

het spijt me zeer, maar msvc produceert echt wel snellere x86 code dan gcc (msvc gaat in veel gevallen zelfs de compiler van intel voorbij)

Dan heb je nog het punt van standard-compliance, en de parsing-tijd die dat met zich meebrengt. Zo kan bv. een compiler die member-templates implementeert nooit sneller parsen dan een compiler die dat niet doet.

Implementeren is wat anders dan een feature opnemen in de grammatica.
En in mijn gba voorbeeldje compileerde ik overigens c-code, niet c++.

Het is overigens algemeen bekend dat de compilatiestappen van gcc niet de optimaalste zijn (moet je maar eens een paar C(++) compilerbouw discussies gaan
lezen)

en op terug te komen op MSVC: vc7 kan de volledige standaard C++ taal parsen

[Zoijar]

.oisyn schreef op 18 september 2002 @ 18:45:
en op terug te komen op MSVC: vc7 kan de volledige standaard C++ taal parsen

Daar denk MS zels volgens mij anders over Of bedoel je misschien dat de compiler het wel kan parsen, maar niet correct interpreteert?

Bv.:
http://msdn.microsoft.com...lianceissuesinvisualc.asp

Dus hoeveel waarde moet ik nu hechten aan de rest van je "feiten"?

[.oisyn]

[nohtml]

Zoijar schreef op 18 september 2002 @ 19:34:
[...]


Daar denk MS zels volgens mij anders over Of bedoel je misschien dat de compiler het wel kan parsen, maar niet correct interpreteert?

dat bedoel ik inderdaad
mietje kwam namelijk met het argument dat een compiler langzamer is als hij meer features ondersteunt. Dat is natuurlijk logisch, want er staat meer in de grammatica en dus worden er grotere parse tabellen gegenereerd. Echter gaat dat voor MSVC niet op omdat het wel geparsed wordt, maat die extra features zijn niet geimplementeerd. Hij geeft dan ook een error (met uitzondering van de function exception specification, die wel gewoon geparsed wordt maar de argumenten worden niet gebruikt)

[Soultaker]

Verwijderd schreef op 18 september 2002 @ 18:17:
gcc is een portable compiler, je kunt hem zo porten naar andere platforms. Het nadeel van dat geport is dat gcc op sommige platforms trager is dan op het native (*nix) platform. Als je compilers fair wilt vergelijken zul je ze op hun native platforms moeten bekijken, en dan zie je dat er niet zoveel verschil bestaat

Ik heb ervaring met gcc onder FreeBSD en Linux en de Microsoft C/C++ compiler onder Windows (verschillende versies; maakt allemaal niet zoveel uit). Over het C-compiler-deel (gcc, dus eigenlijk) heb ik niet te klagen, maar de C++ compiler is onder FreeBSD en Linux (ik merk daar overigens geen verschil tussen) echt merkbaar veel trager dan de Microsoft compiler onder Windows. Zelfs als de Microsoft compiler optimaliseert en G++ niet, is de eerste nog veel sneller.

Het is dus geen ongefundeerde flame. Ik wil niet beweren dat de GNU compiler slecht is (of slechter dan de Microsoft compiler), want ik maak er met veel plezier gebruik van, maar feit is dat de lage snelheid een nadeel is waar je rekening mee moet houden bij het ontwikkelen. Het is dus terecht dat de topicstarter constateert dat de GNU compiler traag is en zich afvraagt of daar wat aan te doen is.

[Zoijar]

.oisyn schreef op 18 september 2002 @ 19:35:

dat bedoel ik inderdaad
mietje kwam namelijk met het argument dat een compiler langzamer is als hij meer features ondersteunt. Dat is natuurlijk logisch, want er staat meer in de grammatica en dus worden er grotere parse tabellen gegenereerd. Echter gaat dat voor MSVC niet op omdat het wel geparsed wordt, maat die extra features zijn niet geimplementeerd. Hij geeft dan ook een error (met uitzondering van de function exception specification, die wel gewoon geparsed wordt maar de argumenten worden niet gebruikt)

Hmmm... ik durf hier niet veel met zekerheid over te zeggen, maar, in principe maken grotere parse tabellen een compiler niet echt langzamer volgens mij. Dat is juist de hele rede dat je parse tabellen maakt, dat je in vrijwel lineare snelheid kan parsen. Het genereren zal wel langer duren, maarja, dat is dus al gedaan

Volgens mij zit de compile snelheids factor juist in optimalisatie algorithmen ed. Afsluitingen berekenen etc. En als het zo is dat VC7 een aantal template features gewoon negeerd, dan kan ik me voorstellen dat die daardoor een stuk sneller door de code heen kan gaan.

Dit stukje ook nog wel leuk hehe:

In terms of C++ compliance Stanley admits that the latest release (Visual C++ 7.0) isn’t quite there, but the substantial work that has been carried out on the underlying implementation means that moving towards a more comprehensively compliant implementation is within reach. He’ll be pushing forward with compliance especially in the area of templates.

Even though Visual C++ 7.0 does not have the full range of features that Stanley would like to see implemented, he says it is still by far the most compliant implementation of C++ that Microsoft have released. It’s not 100% perfect, but it’s still an excellent compiler with high compliance to the standards. Areas that still have issues are fully documented in the VS.NET documentation in the article titled "Standard Compliance Issues in Visual C++".

Microsoft’s goal is to have a ‘competitively compliant’ compiler – meaning it won’t be 100% compliant. There are a couple of features of the ANSI/ISO standard (for instance the ‘export’ keyword as applied to template classes) that won’t be implemented because they are considered by Microsoft to be obscure and, at this stage, theoretical. Microsoft is however working to ensure that Visual C++ will compile the most popular libraries such as Boost, Blitz, Loki and a fully compliant version of STL. The emphasis is on a level of compliance that allows popular libraries to be compiled, not 100% compliance.

Vooral de regel met "because they are considered by Microsoft to be obscure", had ik echt zoiets van "en dat bepalen zij?"

Om nog ff op het topic terug te komen... Als ik het goed begrijp gebruik je gcc om grote tabellen met grafische data om te zetten naar een gameboy formaat? En dan klagen dat gcc zo traag is? Misschien is het beestje daar ook niet echt voor ontwikkeld. M'n formule 1 kar gaat zo traag. Meneer wat doet U er dan mee? Nou, ik hou ervan om over woestijn bergen te crossen.

[Soultaker]

Zoijar schreef op 18 september 2002 @ 19:58:
Om nog ff op het topic terug te komen... Als ik het goed begrijp gebruik je gcc om grote tabellen met grafische data om te zetten naar een gameboy formaat?

.oysin had het over gameboy tabellen. De topicstarter niet.

[.oisyn]

[nohtml]

Zoijar schreef op 18 september 2002 @ 19:58:
[...]


Hmmm... ik durf hier niet veel met zekerheid over te zeggen, maar, in principe maken grotere parse tabellen een compiler niet echt langzamer volgens mij. Dat is juist de hele rede dat je parse tabellen maakt, dat je in vrijwel lineare snelheid kan parsen. Het genereren zal wel langer duren, maarja, dat is dus al gedaan

nou ja de tabellen moeten ook doorzocht worden. En als ik eens een kijkje neem in een source file gegenereerd door bison dan zie ik daar een enorme switch statement staan

Volgens mij zit de compile snelheids factor juist in optimalisatie algorithmen ed. Afsluitingen berekenen etc. En als het zo is dat VC7 een aantal template features gewoon negeerd, dan kan ik me voorstellen dat die daardoor een stuk sneller door de code heen kan gaan.

er zijn welgeteld 3 features die ze negeren: out of class template definitions, partial template specialization en partial ordening of function templates. Ik zie niet in hoe een van deze 3 iets te maken zou hebben met optimalizaties.
Sowieso hebben templates an sich niets te maken met optimalizaties: een template kun je zien als een soort van preprocessor-macro, behalve dat het wel geparsed wordt, en na de parse-stap de argumenten worden ingevuld.

Als je het dan naar de sematic analyser stuurt dan is het niets meer dan een stuk code waarbij alle generieke argumenten zijn vervangen door de daadwerkelijke argumenten, en vanaf dat moment bestaat er ook geen verschil meer tussen template code en gewone code.

Maar goed, dit stukje is 100% IMHO, ik weet verder niet hoe de compiler er daadwerkelijk mee omgaat

Vooral de regel met "because they are considered by Microsoft to be obscure", had ik echt zoiets van "en dat bepalen zij?"

waarom mag MS niet zelf bepalen wat ze obscuur vinden en wat niet? Niet dat ik het met ze eens ben overigens Ik ben maar al te blij dat de template features in mijn favo compiler enorm zijn uitgebreid, en dat er nu maar een paar dingen zijn die niet compliant zijn. En het doet me deugd te lezen: Microsoft is however working to ensure that Visual C++ will compile the most popular libraries such as Boost, Blitz, Loki and a fully compliant version of STL

Om nog ff op het topic terug te komen... Als ik het goed begrijp gebruik je gcc om grote tabellen met grafische data om te zetten naar een gameboy formaat?

het is niet mijn topic

[.oisyn]

Soultaker schreef op 18 september 2002 @ 20:06:
[...]

.oysin

swap (y, i)

[Soultaker]

.oisyn schreef op 18 september 2002 @ 20:26:
swap (y, i)

Oh ja. Syrro!

[mbravenboer]

.oisyn: Sowieso hebben templates an sich niets te maken met optimalizaties: een template kun je zien als een soort van preprocessor-macro, behalve dat het wel geparsed wordt, en na de parse-stap de argumenten worden ingevuld.

Templates kunnen natuurlijk wel voor een behoorlijke explosie van de hoeveelheid code zorgen. Dit is voor vrijwel alle latere fasen extra veel werk: semantische analyse, type-checking, optimalisatie, instructie selectie enz enz: alles wordt in principe een x aantal keren gedaan als het template x maal wordt ingevuld met concrete parameters.

(dit verhaal heeft niets met de compileersnelheid van g++ te maken en is zeker geen argument voor of tegen wat dan ook ).

[MSalters]

.oisyn schreef op 18 september 2002 @ 20:19:

er zijn welgeteld 3 features die ze (MS VC) negeren: out of class template definitions, partial template specialization en partial ordening of function templates. Ik zie niet in hoe een van deze 3 iets te maken zou hebben met optimalizaties.

Het beruchte export vergeten? Dat is natuurlijk de oorzaak van extreme complexiteit bij optimalisaties - zonder de concrete template parameters kun je het rustig vergeten dat je een gecompileerd template kunt optimizen - er is nog niet eens code beschikbaar!

Daarnaast is er ook nog het subtiele probleem dat de MS implementaties nog lang niet altijd direct foutloos zijn. Deze nog bekend?

code:

template <typename T> void foo( ) { T t; }

MSVC6 mikte hier op een na alle instantiaties van weg omdat'ie alle foo<T>s als identieke functies zag. (Ik ben nog niet zo bekend met de VC7 bugs)

[.oisyn]

MSalters: hmmm ok maar wat heeft (afgezien van export, waarvan ik me ook afvraag of de topicstarter dat gebruikt) dat met de compileersnelheid te maken?

[Verwijderd]

Nog even een opmerking over gcc vs. msvc (ik moest helaas weg)

Ik geeft grif toe dat msvc strakkere C-code genereert dan gcc, en daar is ook een logische verklaring voor: enkele belangrijke optimalisaties zoals tree-based inlining worden bij gcc niet door de C frontend maar wel door de C++ frontend toegepast. Als je echter complexe C++ code bekijkt levert gcc (vanaf 3.0) bijna altijd strakkere resultaten dan msvc. En zoals als gezegd, hoe zwaarder een compiler optimaliseert, hoe trager hij wordt.

(Zie hier voor een beschrijving van de gcc 3.0 passes, ik kan helaas geen online documentatie over de msvc passes vinden.)

[MSalters]

.oisyn schreef op 18 september 2002 @ 23:09:
MSalters: hmmm ok maar wat heeft (afgezien van export, waarvan ik me ook afvraag of de topicstarter dat gebruikt) dat met de compileersnelheid te maken?

De 10% lastige gevallen van een feature veroorzaken 90% van de compileertijd; als je een feature voor 90% implementeert kan je't compileren in 10% van de tijd (90-10 regel).
Bv. partial template specialization maakt name lookup/overloading langzamer, omdat de compiler template declaraties moet gaan instantieren tijdens function overloading.

[abeker]

Bij gebrek aan een binary naar object converter converteerden we dus alle data (graphics en dat soort dingen) naar arrays in C-code. Aangezien dat nogal grote tabellen worden is het handig als dat snel te compileren valt

Ooit gehoord van objcopy? Komt standaard mee met de gnu c-compiler. En als je iets NIET moet dan is het wel binaries omzetten naar tabellen. Voor elke element in tabel wordt er een regel in de assembly output gemaakt, dus als je een binary van 100kB omzet naar een tabel, dan wordt dat later omgezet naar 100.000 regels in de assembly output (ouch!).

En waar de Arm compiler er een halve seconde over deed, deed gcc er 10 (!!!) seconde over. Dat is dus echt geen pretje

Deze vergelijk slaat hopelijk niet op je vorige voorbeeld, tenminste als je voor de ARM-compiler de binaries niet naar tabellen hebt omgezet maar met incbin geinclude hebt... Ik vind de snelheid van de gnu-c compiler best meevallen, compilatie gaat toch lekker snel (als je geen fikse tabellen gebruikt ), zeker als je bedenkt dat ik ook nog cygwin gebruik. Met de ARM-compiler heb ik zelf geen ervaring, dus daar ga ik ook niks over zeggen...

[.oisyn]

[nohtml]

abeker schreef op 19 september 2002 @ 14:58:
Ooit gehoord van objcopy?

nope

Komt standaard mee met de gnu c-compiler. En als je iets NIET moet dan is het wel binaries omzetten naar tabellen. Voor elke element in tabel wordt er een regel in de assembly output gemaakt, dus als je een binary van 100kB omzet naar een tabel, dan wordt dat later omgezet naar 100.000 regels in de assembly output (ouch!).

Dat lijkt me echt onzin. En als gcc het zo oplost dan hebben ze er niet veel van begrepen. Tabellen kun je regelrecht als data in de data section zetten.
Overigens maakte het niet veel uit, de ARM compiler produceerde ook stuk snellere code dan gcc

Deze vergelijk slaat hopelijk niet op je vorige voorbeeld, tenminste als je voor de ARM-compiler de binaries niet naar tabellen hebt omgezet maar met incbin geinclude hebt...

ik heb idd wel naar die incbin feature gekeken, maar er was iets mee... ik weet niet meer wat, maar uiteindelijk was het gewoon handiger om die tabellen te genereren