[Linux, compileren] Makefile / optimizen

[odysseus]

Eenvoudige vraag misschien, maar ik kom er niet goed uit ...
Ik bedacht Qt eens opnieuw te compileren, extra geoptimaliseerd. Heeft waarschijnlijk weinig nut omdat hij toch al -O2 gebruikt, maar je kunt het natuurlijk altijd eens proberen...maar dan moet je er wel uitkomen hoe je die opties netjes meegeeft. Mijn standaard compile-acties voor Qt:
• Make -f Makefile.cvs
• ./configure opties
• make
Nu zou ik dus iets willen doen wat neerkomt op './configure opties -O3 -mpentium' of soortgelijk. Dat gaat natuurlijk niet, want -O3 is geen optie die configure herkent...kan ik me voorstellen. Maar iets als 'make -O3' werkt ook niet, want make kan natuurlijk nooit weten dat ik bedoel dat hij alle aanroepen van gcc en g++ van die optie vergezeld moet laten gaan...
In een laatste poging om het goed ingesteld te krijgen heb ik naar de Makefiles gekeken. De toplevel makefile heeft geen aparte regel voor de CXXFLAGS of dingen die hetzelfde doen, maar alle Makefiles in de subdirs wel. Als het er niet zo veel waren geweest had ik het nog wel handmatig willen vervangen, maar:

code:

kde3@odysseus:/usr/src/qt-copy$  find . -name Makefile -print | wc -l
    234
kde3@odysseus:/usr/src/qt-copy$

Dat is me iets te veel werk . Natuurlijk kun je een scriptje schrijven dat recursief alle Makefiles afgaat, zoekt naar de regel met CFLAGS of CXXFLAGS en die gaat aanpassen, maar ik heb zomaar het vermoeden dat dit een hele hoop simpeler moet kunnen . Dus: hoe zorg ik dat er Makefiles worden gegenereerd met door mij te bepalen opties?

* odysseus ziet vast ergens een stomme optie over het hoofd, maar goed, als iemand me dat kan vertellen ben ik al dankbaar

[en als laatste vraagje, waarvoor ik eigenlijk even moet RTFM'en wat ik nog niet gedaan heb: welke architecturen/processoren ondersteunt gcc/g++ allemaal bij de optie -m? Antwoorden a la 'RTFM' en 'UTFS' zijn toegestaan .]

[Kippenijzer]

Weet niet of je hier iets aan hebt, maar bij het compilen van een kernel doe ik voor de make opdracht altijd een export make='make -jX' waarbij X een mooi getalletje is wat enigzins afhankelijk is van je hoeveelheid ram. Hij gaat dat X make processen tegelijk draaien, en maakt op die manier efficienter gebruik van je geheugen. Op een bak met 384Mb geheugen doe ik volgens mij iets van -j7 ofzo... Gewoon effe proberen, hij zou dan iig zo'n 98% van je ram voor het compilen moeten gebruiken, en geen swap ruimte, gaat lekker snel met kernel compile (des te beter op SMP systemen )

[odysseus]

Op vrijdag 22 februari 2002 12:08 schreef Kippenijzer het volgende:
Weet niet of je hier iets aan hebt, maar bij het compilen van een kernel doe ik voor de make opdracht altijd een export make='make -jX' waarbij X een mooi getalletje is wat enigzins afhankelijk is van je hoeveelheid ram.

Dat gebruik ik ook, had ik alleen niet vermeld...als ik mijn pc even niet nodig heb make -j16, maar dat is meer om naar mijn loadavg te kijken terwijl ik iets aan het lezen ben of zo dan omdat het echt nuttig is . 'make -j' (zonder argumenten) is ook leuk, maar daar dacht mijn machine iets anders over toen ik het draaide...
Maar helaas, het biedt nog geen oplossing .

[Ronald]

export CFLAGS=-march=pentiumpro -O3 -blahenzo
export CXXFLAGS=$CFLAGS

(mits je bash achtige shell gebruikt)

dit wordt door de meeste ./configure scripts herkend

[Verwijderd]

Op vrijdag 22 februari 2002 12:04 schreef odysseus het volgende:
Nu zou ik dus iets willen doen wat neerkomt op './configure opties -O3 -mpentium' of soortgelijk. Dat gaat natuurlijk niet, want -O3 is geen optie die configure herkent...kan ik me voorstellen.

Is dat geen optie in ./configure Zie ./configure --help

[en als laatste vraagje, waarvoor ik eigenlijk even moet RTFM'en wat ik nog niet gedaan heb: welke architecturen/processoren ondersteunt gcc/g++ allemaal bij de optie -m? Antwoorden a la 'RTFM' en 'UTFS' zijn toegestaan .]

RTFM

-mcpu=i586 -march=i586 optimaliseert voor de pentium.

[odysseus]

Op vrijdag 22 februari 2002 12:17 schreef beelzebubu het volgende:

[..]

Is dat geen optie in ./configure Zie ./configure --help

Nee, daar had ik al naar gekeken...en het is ook geen ongedocumenteerde optie, want gewoon uitproberen werkte ook niet .

RTFM

-mcpu=i586 -march=i586 optimaliseert voor de pentium.

Dan zal ik die in ieder geval meegeven aan g++ zodra ik weet hoe het moet. Heeft g++ ook een optie voor Athlon-optimizing? Dus gebruik maken van 3dNow! of zo? Ik meen dat iemand (deadinspace?) een tijdje geleden zei dat pentium-builder ook voor de athlon kon optimaliseren, maar de documentatie (die overigens bijzonder summier is) zegt daar niets over...

[Ronald]

Op vrijdag 22 februari 2002 12:08 schreef Kippenijzer het volgende:
Weet niet of je hier iets aan hebt, maar bij het compilen van een kernel doe ik voor de make opdracht altijd een export make='make -jX' waarbij X een mooi getalletje is wat enigzins afhankelijk is van je hoeveelheid ram. Hij gaat dat X make processen tegelijk draaien, en maakt op die manier efficienter gebruik van je geheugen. Op een bak met 384Mb geheugen doe ik volgens mij iets van -j7 ofzo... Gewoon effe proberen, hij zou dan iig zo'n 98% van je ram voor het compilen moeten gebruiken, en geen swap ruimte, gaat lekker snel met kernel compile (des te beter op SMP systemen )

Teveel threads maakt het luist langzamer door de overhead van taskswitchen. nuttige vuistregel is make -jn where n = aantal cpu's +1 dacht ik

jodysseus riep:
[en als laatste vraagje, waarvoor ik eigenlijk even moet RTFM'en wat ik nog niet gedaan heb: welke architecturen/processoren ondersteunt gcc/g++ allemaal bij de optie -m? Antwoorden a la 'RTFM' en 'UTFS' zijn toegestaan .]

info gcc bij de -m switches
* Ronald heeft veel ruzie met info en moet info2www maar eens installen

jodysseus riep later:
Dan zal ik die in ieder geval meegeven aan g++ zodra ik weet hoe het moet. Heeft g++ ook een optie voor Athlon-optimizing? Dus gebruik maken van 3dNow! of zo? Ik meen dat iemand (deadinspace?) een tijdje geleden zei dat pentium-builder ook voor de athlon kon optimaliseren, maar de documentatie (die overigens bijzonder summier is) zegt daar niets over..

-mathlon voor gcc3, op gcc2 is het geloof niets meer dan een synonym voor -mpentiumpro

[ACM]

Op vrijdag 22 februari 2002 12:21 schreef nitenite het volgende:
Teveel threads maakt het luist langzamer door de overhead van taskswitchen. nuttige vuistregel is make -jn where n = aantal cpu's +1 dacht ik

Inderdaad, dat is de/een vuistregel

[odysseus]

Op vrijdag 22 februari 2002 12:21 schreef nitenite het volgende:

[..]

Teveel threads maakt het luist langzamer door de overhead van taskswitchen. nuttige vuistregel is make -jn where n = aantal cpu's +1 dacht ik

Ik zet n dan ook alleen zo hoog als ik gewoon tijd genoeg heb, bijvoorbeeld als ik toch weg moet en hij rustig mag ratelen. Meer om te experimenteren dan voor echt serieus gebruik, dat doe ik meestal zelfs uit gewoonte met n=1

info gcc bij de -m switches
* odysseus heeft veel ruzie met info en moet info2www maar eens installen

Heb ik gekeken, maar dat lijkt nogal verouderd te zijn, of ik mis ergens iets. In de manpage staat weinig, in de infopagina staat wel veel over -m maar maar een klein stukje over -m bij intel-architecturen. En dat gaat dan weer niet verder dan 'niet optimaliseren voor de 80486'...dat is wat ouder dan ik in gedachten had .

Overigens werkt je suggestie van hierboven om eerst een export van de C(XX)FLAGS te doen ook niet, ook dat was al geprobeerd . Nog andere ideeen?

[Ronald]

[b]Op vrijdag 22 februari 2002 12:28 schreef odysseus
[..]

Overigens werkt je suggestie van hierboven om eerst een export van de C(XX)FLAGS te doen ook niet, ook dat was al geprobeerd . Nog andere ideeen?

Vaagjes, werkt bij mij meestal wel. voor QT mischien wel niet omdat die geen autoconf script gebruiken, maar hun eigen geval

edit:

QT 3 kijkt er inderdaad niet naar
er is een omweg: ga naar qt..../mkspecs/jouwplatformdir (linux-g++)
edit de qmake.conf
bv:

QMAKE_CFLAGS = -pipe -march=pentiumpro
QMAKE_CFLAGS_RELEASE = -O3

(orgineel is het -pipe en -O2)

dit lijkt te werken, al heb ik QT niet afgecompiled
ik heb gekeken naar QT3, QT2 zal mischien iets soortgelijks werken

[_Squatt_]

Hier staan wat opties voor gcc.

CFLAGS en CXXFLAGS zetten werkt inderdaad niet. En in 'mkspecs/linux-g++/qmake.conf', waar je wat moet editten om Qt ook ge-objprelinked te krijgen, staat wel 'QT_CFLAGS_RELEASE = -O2' maar dat naar '-O3 -march=i686' zetten hielp ook niet.

[Ronald]

Op vrijdag 22 februari 2002 13:09 schreef _Squatt_ het volgende:
Hier staan wat opties voor gcc.

CFLAGS en CXXFLAGS zetten werkt inderdaad niet. En in 'mkspecs/linux-g++/qmake.conf', waar je wat moet editten om Qt ook ge-objprelinked te krijgen, staat wel 'QT_CFLAGS_RELEASE = -O2' maar dat naar '-O3 -march=i686' zetten hielp ook niet.

Heb je wel configure opnieuw gedraaid? - anders pakken die 200 Makefiles de wijzigingen niet op
ik heb uhm een stuk of 4 sources laten compilen en die hadden de gewenste extra flags (/me heeft geen behoefte aan een nieuwe QT)

[_Squatt_]

Op vrijdag 22 februari 2002 13:15 schreef nitenite het volgende:

[..]

Heb je wel configure opnieuw gedraaid? - anders pakken die 200 Makefiles de wijzigingen niet op

Euhm... daar zeg je wat .

Dat zal het inderdaad wel zijn, zo even proberen. _Nog_ een keertje Qt compilen kan geen kwaad .

[odysseus]

Ik heb een regel in mkspecs/linux-g++-objprelink/qmake.conf gewijzigd, dat werkte nog niet. Toen ik daarna de qmake.conf in mkspecs/linux-g++/ wijzigde ging het wel goed...dus hij neemt ze in ieder geval over, dat is al heel wat. Bedankt hiervoor .
Helaas roept dat meteen weer een tweede vraag op: hoe geef ik aan dat object prelinking gebruikt moet worden? Bepaalt Qt dat zelf aan de hand van de compiler? Ik zie namelijk dat zelfs al zodra ik ./configure draai hij gaat kijken in mkspecs/linux-g++/ en niet in linux-g++-objprelink zoals ik graag zou zien. Natuurlijk heb ik aan ./configure de switch -enable-objprelink meegegeven, dus daar ligt het niet aan. Kan gcc 2.95 dit eigenlijk wel, of moet ik dan even gcc 3.x gaan gebruiken?

* odysseus zoekt verder in de gcc-documentatie op gnu.org...nog niets gevonden over object prelinking...

[_Squatt_]

Hmm, ik heb geen eens een dir 'mkspecs/linux-g++-objprelink' !

In de patch van deze pagina staat dat je het volgende moet veranderen:

code:

in 'mkspecs/linux-g++/qmake.conf'

-QMAKE_LINK     = g++
-QMAKE_LINK_SHLIB   = g++
+QMAKE_LINK     = objprelink $(OBJECTS) $(OBJMOC) && g++
+QMAKE_LINK_SHLIB   = objprelink $(OBJECTS) $(OBJMOC) && g++

Je moet dan natuurlijk wel objprelink in je PATH hebben.
De patch zelf werkte bij mij niet, dus moest ik het zelf even aanpassen.


Qt 3 wordt nu overigens met '-O3 -march=i686' gecompileerd, bedankt nitenite!

[Ronald]

* Ronald googled 3 seconden

http://leon.bottou.com/objprelink/howto.html

* Ronald heeft dit niet getest

hier staat ook bij over die obprelink executable

[edit]
* Ronald is slow!

[odysseus]

Hmm, die objprelink-executable heb ik hier nog wel liggen, maar niet in mijn $PATH staan...niet aan gedacht, vorige keer dat ik dergelijke dingen compileerde heb ik nog met de hand objprelink zitten draaien...ik zal het ding eens in mijn PATH zetten en nog eens proberen...resultaten volgen zometeen .

En dat die dir niet in mkspecs staat ligt misschien aan het feit dat ik hier een CVS-editie van Qt heb...misschien zit het er bij de oudere versies nog niet in. In ieder geval is die objprelink-map niet anders dan de gewone g++-directory, met aanvulling van de patch die hierboven al gepost werd.

[Ronald]

Oooi

http://lists.debian.org/debian-kde/2001/debian-kde-200110/msg00299.html

wordt beweerd dat het met recente glibc en binutils geen zin meer heefd

* Ronald gaat binnenkort een verse LFS maken op basis van Glibc 2.2.5 binutils 2.11.2 (is nu glibc2.2.4)

[odysseus]

Die post had ik inderdaad een hele tijd geleden ook gelezen . Heeft nog ergens op een van de nieuwssites gestaan ook geloof ik. Maar trager zal het er alleszins niet op worden en anders kun je in een van de followups zien dat -march / -mcpu wel veel uit kunnen maken, dus dan is het in ieder geval nuttig daarvoor . En om mee te spelen is het natuurlijk altijd leuk...

* odysseus vindt het beschikken over de source van programma's best handig...

[Ronald]

Op vrijdag 22 februari 2002 14:08 schreef odysseus het volgende:

[..]

* odysseus vindt het beschikken over de source van programma's best handig...

No kidding

laat weten wat er uit komt is het wel of niet sneller met de objprelink. welke glibc/binutils draai je ?

[_Squatt_]

Op vrijdag 22 februari 2002 14:02 schreef nitenite het volgende:
Oooi

http://lists.debian.org/debian-kde/2001/debian-kde-200110/msg00299.html

wordt beweerd dat het met recente glibc en binutils geen zin meer heefd

* _Squatt_ gaat binnenkort een verse LFS maken op basis van Glibc 2.2.5 binutils 2.11.2 (is nu glibc2.2.4)

* _Squatt_ heeft een LFS met glibc 2.2.5 / binutils 2.11.2 .

Toch maar eens KDE zonder objprelink compileren om te kijken of dat inderdaad sneller is.

[odysseus]

code:

kde3@odysseus:~$ dpkg -p binutils | grep Version
Version: 2.11.93.0.2-1

Ik heb net uitgevonden waarom hij elke keer maar in linux-g++/ bleef zoeken, terwijl ik wel --enable-objprelink had staan: je moet blijkbaar ook nog een keer '-platform linux-g++-objprelink' meegeven. Hij is nu voor de zoveelste keer projectfiles aan het genereren, als hij klaar is met compileren (of als er weer foutmeldingen zijn) horen jullie het wel .

[edit: ik heb -march=k6 en -mcpu=k6 gebruikt, ik gokte dat dat beter was voor mijn k7 dan -march=i686. Veel verschil zal het niet zijn, misschien is i686 zelfs wel sneller, maar dat merk ik vanzelf...]

[Ronald]

* Ronald googled wat in de rondte

GCC 3:
CFLAGS=-O9 -march=athlon -funroll-all-loops -fomit-frame-pointer -fno-gcse -fstrict-aliasing -fssa

GCC 2.95:
CFLAGS=-O9 -march=pentiumpro -funroll-all-loops -fomit-frame-pointer -fno-gcse -fstrict-aliasing

De athlon is vrij goed in p3 optimized code

http://gcc.gnu.org/ml/gcc/2001-06/msg00422.html

[odysseus]

Hmm, bedankt voor die opties. Ik heb zelf net wat zitten googlen omdat ik constant segfaults krijg van moc bij het compileren...heb net gevonden waar het waarschijnlijk aan ligt, slecht nieuws in ieder geval:

If you
applied the objprelink patch and the build process unexpectedly stops with a
segmentation fault when it runs "moc", that's an indication that prelinking
will not work on your system. I wish I knew what to do about it, but there
is no known fix right now.

_{http://hints.linuxfromscratch.org/hints/kde.txt}

Ik vrees dat ik dus zonder objprelink moet compileren ...jammer, dan kan ik ook niet testen of het nu sneller is of niet . In ieder geval nu maar eens builden met -march=i686 en -On en dan kijken of dat een beetje wil...

* odysseus hoopt stiekem op iemand die nu komt vertellen dat er een fix is voor het probleem met moc...

[Ronald]

nee dat is positief
http://www.google.com/search?hl=en&q=prelink+moc+segfault&btnG=Google+Search
krijg je LFS kde hint slechts

[odysseus]

Nu was mijn Qt klaar met compileren, mooi nog een make install gedraaid in de verwachting dat alles gewoon zou werken...stopt mijn KDE ermee. Elk willekeurig KDE-gerelateerd programma wil niet opstarten met foutmeldingen a la:
programma: relocation error: /usr/local/kde3/lib/libDCOP.so.4: undefined symbol: newData__7QGArray
Ik ben nu kdelibs aan het hercompileren, maar ik heb zo'n idee dat het daar niet aan ligt. Zul je zien dat ik zometeen weer Qt mag gaan compileren...weer een paar uur werk . Iemand die zo even direct weet wat je hiertegen doet? Ik heb deze error wel eens gezien maar ik weet absoluut niet meer in welke context dus dat is een beetje lastig, en google helpt ook al niet echt mee met het vinden van een oplossing.

* odysseus draait nu onder twm...das wel het andere uiterste tegenover KDE .

[Verwijderd]

kan het zo zijn dat Qt simpelweg niet met -O9 gecompileerd kan worden en corrupte binary code aflevert

-O9 vind ik nl. wel erg veel

[odysseus]

Is het natuurlijk ook...maar hoe hoog de optimalisatie ook staat, een compiler zou natuurlijk nooit een corrupte binary of library mogen produceren...ik ben nu KDE nog steeds aan het compileren, eens zien of het dan beter werkt. En als het dan nog niet gaat dan bouw ik Qt gewoon met -O3 en dan KDE nog een keer...tegen morgenavond zou dat wel klaar moeten zijn .

* odysseus hoopt nog altijd op iemand die hem vertelt hoe hij snel en makkelijk die error verhelp...onderwijl dromend over een prachtige quad Xeon die KDE op een half uurtje compileert...

[deadinspace]

Op vrijdag 22 februari 2002 18:23 schreef odysseus het volgende:
Is het natuurlijk ook...maar hoe hoog de optimalisatie ook staat, een compiler zou natuurlijk nooit een corrupte binary of library mogen produceren...

Bij optimalisaties hoger dan -O2 was dat meen ik niet gegarandeerd. En er treden ook wel eens vreemde problemen op bij hoge optimalisaties (Mozilla 0.9.7 in Debian had het meen ik... Die was ineens stabieler toen ze met -O2 compileden ipv -O3 ofzo).
Maar een undefined reference lijkt me als gevolg van te hoge optimalisatie nogal raar...

[Verwijderd]

Op vrijdag 22 februari 2002 19:59 schreef deadinspace het volgende:

[..]

Bij optimalisaties hoger dan -O2 was dat meen ik niet gegarandeerd. En er treden ook wel eens vreemde problemen op bij hoge optimalisaties (Mozilla 0.9.7 in Debian had het meen ik... Die was ineens stabieler toen ze met -O2 compileden ipv -O3 ofzo).
Maar een undefined reference lijkt me als gevolg van te hoge optimalisatie nogal raar...

Met -O9 zou niks me verbazen

[odysseus]

Op vrijdag 22 februari 2002 20:38 schreef beelzebubu het volgende:
Met -O9 zou niks me verbazen

Ik ga er nog altijd vanuit dat het gewoon gaat werken...Qt is nu aan het compileren, KDE is gebeurd...helaas zonder object prelinking, maar wel met -O9. Overigens zou het ook nog best aan g++-3.0 kunnen liggen, er zijn wel meer programma's die daar nogal over vallen. Ik meld zometeen wel of Qt en KDE weer vriendjes zijn en samen hun kunstjes willen opvoeren .

[odysseus]

Werkt nog niet echt zoals ik wil...
Na het compileren van Qt kreeg ik nog steeds dezelfde foutmelding. Ik besloot dat misschien alles weer in de goede volgorde gebouwd moest zijn, dus ik kdesupport weer opnieuw compileren. Nog steeds hetzelfde. Toen kdelibs opnieuw gedaan. Nu veranderde de foutmelding naar een relocation error in libkonq* in plaats van in Qt...dat schiet al op . Ik ben nu kdebase aan het hercompileren, wat ook wel weer even gaat duren, maar daar zit Konqueror in ieder geval in dus misschien dat die dan ook weer wil werken...

* odysseus gaat door in het vooruitzicht van een bloedsnelle desktop (niet meer dan een droom, maar goed, die zijn soms nodig )...

[edit: vergeten te vermelden: Qt-programma's doen het in ieder geval wel, dus ik mag redelijkerwijs aannemen dat Qt met -O9 zonder problemen gecompileerd is . Vandaar mijn hoop dat als ik de rest ook opnieuw compileer met dezelfde opties als Qt dat die dingen dan ook weer werken...]

[odysseus]

Gcc vindt het blijkbaar niet echt leuk om op zo'n manier te compileren...kwam net weer even kijken: Internal Error: Segfault. Please report bug enz...
Vervolgens op goed geluk dezelfde compile nog eens aangezet en nu doet hij hetzelfde bestand wel goed . Ik was al lang blij, maar vreemd blijft het toch...

* odysseus gaat zijn processor zometeen maar eens wat nachtrust laten genieten...dat ding heeft voor vandaag zijn werk wel weer gedaan met pakweg 3 keer Qt compileren, 2 keer alle KDE base-libs en dan nog wat extra spul eromheen (arts, kdenetwork)...

[odysseus]

Kleine tekenen van vooruitgang stapelen zich op . Het werkt nog steeds niet, maar dat is een tweede...
In ieder geval is er nog iemand die dit probleem heeft en die kon het oplossen door niet te optimaliseren en door FAM (lib die events afgeeft zodra er bestanden veranderen) uit te schakelen. Mijn eigen backtrace laat ook zien dat de geoptimaliseerde KDE in FAM crasht. Dat is dus in ieder geval al een workaround die ik kan proberen...daarnaast bleek Pavel Troller een probleem met de nspluginviewer (dat ding dat zorgt voor het gebruik van NS-plugins) te hebben, dat hij uiteindelijk kon oplossen door met een andere libstdc++ te linken. Hij denkt dat dat probleem dezelfde oorzaak heeft als het sycoca-probleem, dus misschien is er binnenkort een patch die het geheel laat werken zoals de bedoeling is...en dat met alle mogelijke optimalisaties .
Ik wil echter voorlopig FAM nog niet uitschakelen omdat de vervanger ervan een hogere load met zich mee brengt. Het schijnt echter ook mogelijk te zijn om dit met de kernel te doen. Heeft iemand toevallig wel eens met imon gewerkt? Dit schijnt in de kernel te zitten, al heb ik het nog nooit gezien daar. Ik moet zelf nog gaan googelen dus links naar websites verwacht ik niet, maar persoonlijke ervaringen van iemand ben ik wel geinteresseerd in .