[linux] prelink, de moeite waard?

[sebas]

prelink is a program which modifies ELF shared libraries and ELF dynamically linked binaries, so that the time which dynamic linker needs for their relocation at startup significantly decreases and also due to fewer relocations the run-time memory consumption decreases too (especially number of unshareable pages). Such prelinking information is only used if all its dependent libraries have not changed since prelinking, otherwise programs are relocated normally.

Ik heb een aantal dingen over prelinking gelezen, maar voordat ik me eraan waag heb ik nog een aantal vraagjes, dingen die uit de info die ik heb niet helemaal duidelijk werden:

Wat is ongeveer de status van prelink, hoe stabiel is het, hoe groot is de kans dat ik strax enorm aan het vloeken ben omdat ik me systeem vernield heb?
Zijn er mensen die het gebruiken, wat zijn de ervaringen ermee?
Hoe gebruiken jullie het? (cronjobje om de locaties van de libs te refreshen, na elke install? bijv)
Wat levert het daadwerkelijk op, voor welke applicaties heb je er echt wat aan?
Hoe eenvoudig is het te herstellen als je dat prelinking toch niet wilt? gewoon uninstallen en verdergaan? of mis ik dan iets?

Ik heb de volgende documenten wat beter bekeken:
man prelink
http://freshmeat.net/projects/prelink/?topic_id=253
http://klecker.debian.org/~chris/prelink/

Zijn er nog meer goede resources?

En tenslotte een wat algemenere vraag: Raden jullie het echt aan of is het de moeite op dit moment nog niet echt waar?

Ik draai gnome2 op debian unstable op een tbird 1.4 en heb 1gb ddr erinzitten, mag ik er een echt merkbare snelheidswinst van verwachten? Veelgebruikte apps zijn mozilla, phoenix, en diverse gtk1 en gtk2 apps zoals anjuta, xchat enz.

[Wilke]

Gentoo prelinking guide met ook wat probleempjes die je tegen kunt komen.

Ik probeer momenteel uit te vinden of het de moeite waard is, maar aangezien mijn processor niet zo opschiet duurt het nog even voordat ik er iets zinnigs over kan zeggen.

In principe kun je prelinking ongedaan maken, maar als je je systeem in een niet-werkende toestand hebt gebracht door prelinken moet je natuurlijk een boot-diskette hebben om dit uberhaupt te kunnen doen. Veel meer dan dat kan er niet foutgaan, als ik die Gentoo pagina moet geloven.

Nog iets belangrijks: je kunt het dus alleen toepassen op dingen die met glibc 2.3.1 en de nieuwste binutils gecompileerd/gelinkt zijn. Dat betekent dus dat het een goed idee is alles opnieuw te compileren/installeren tegen die nieuwe binutils/gcc, of je moet heel erg gaan uitkijken wat je prelinkt en wat niet.

Oh ja: sommige libs schijnen te crashen, bv. libXinerama.a (hoort bij QT), dat komt meestal omdat het 'shared libs' zijn maar (per ongeluk) niet gecompileerd met -fPIC zoals dat hoort.

[ Voor 10% gewijzigd door Wilke op 12-01-2003 15:36 ]

[_Squatt_]

Zie deze post voor wat cijfers.

Prelinken is prima terug te draaien. De LFS hint over prelink heeft ook nog wat praktische info.

Wilke schreef op 12 januari 2003 @ 15:35:
Oh ja: sommige libs schijnen te crashen, bv. libXinerama.a (hoort bij QT), dat komt meestal omdat het 'shared libs' zijn maar (per ongeluk) niet gecompileerd met -fPIC zoals dat hoort.

libXinerama hoort bij XFree (dacht ik), maar Qt linkt daartegen (als je wilt). En als libXinerama niet PIC is, dan kan Qt ook niet geprelinkt worden, en dan dus ook alle libs/programma's die tegen Qt linken niet. Niet handig als je KDE geprelinkt wil hebben .

Bij mijn eerste poging was zlib niet met -fPIC gecompileerd -> Dat blijkt dus een nogal veel gebruikte lib te zijn Dus dat moest ik even rechtzetten voor prelinken zin had.

[ Voor 64% gewijzigd door _Squatt_ op 12-01-2003 15:50 ]

[_JGC_]

/usr/bin/ld renamen naar /usr/bin/ld.orig, vervolgens een executable shellscript aanmaken op de oude locatie met dit erin:

code:

#!/bin/sh
/usr/bin/ld.orig -z combreloc "%@"

Persoonlijk compileer ik liever met combreloc dan zooi als objprelink. Combreloc vereist helemaal geen aanpassing aan de code, objprelink mag je gaan hacken in de code, wat nogal eens misgaat. Heb tot nu toe nog geen enkele misser gehad met combreloc.

[_Squatt_]

_JGC_ schreef op 12 January 2003 @ 15:46:
/usr/bin/ld renamen naar /usr/bin/ld.orig, vervolgens een executable shellscript aanmaken op de oude locatie met dit erin:
[...]

Bij de nieuwere binutils staat combreloc standaard aan, en is dit dus niet meer nodig.

Persoonlijk compileer ik liever met combreloc dan zooi als objprelink. Combreloc vereist helemaal geen aanpassing aan de code, objprelink mag je gaan hacken in de code, wat nogal eens misgaat. Heb tot nu toe nog geen enkele misser gehad met combreloc.

prelink is wat anders dan objprelink, en gaat prima samen met combreloc. Geen gehack in de code voor nodig.

[Wilke]

_Squatt_ schreef op 12 January 2003 @ 15:43:
libXinerama hoort bij XFree (dacht ik), maar Qt linkt daartegen (als je wilt). En als libXinerama niet PIC is, dan kan Qt ook niet geprelinkt worden, en dan dus ook alle libs/programma's die tegen Qt linken niet. Niet handig als je KDE geprelinkt wil hebben .

Argh...ja, je hebt vast gelijk, het hoort bij XFree maar QT (bv.) gebruikt het.

Da's fijn, kan ik straks ook XFree nog een keertje opnieuw gaan compileren


Edit: Hmmm, nou vraag ik me toch af of je gelijk hebt, want die Gentoo prelinking page zegt:

For the QT library libXinerama.a either add myconf="-no-xinerama ${myconf}" somewhere at the beginning of the src_compile function in /usr/portage/x11-libs/qt/qt-3.x.x.ebuild of your QT ebuild or add -fPIC to your CFLAGS while emerging QT.

van zlib en nog wat andere libs heeft Gentoo inmiddels versies waarbij dat -fPIC al wel aangezet is (waarschijnlijk een Makefile-patch van het jaar 0, 3 seconden werk ofzo.. maar ja, het moet wel even gedaan worden )

[ Voor 20% gewijzigd door Wilke op 12-01-2003 15:56 ]

[sebas]

Ik maak uit http://objprelink.sourceforge.net/objprelink.html op dat prelink en objprelink[2] / combreloc van elkaar compleet onafhankelijke dingen zijn. Klopt dat?

Ik draai trouwens geen gentoo, dus ik denk dat 'alles recompilen' even geen optie is.
In hoerverre kan ik er verder van uitgaan dat mijn systeem aan de eisen voor prelinking voldoet?

Ik maak trouwens wel gebruik van xinerama.

[Wilke]

Nou ja, of je moet zelf dat 'even recompilen' doen, of jouw distro moet dat al voor je gedaan hebben, en dan moet je dus packages installen die allemaal stuk voor stuk met glibc 2.3.1 + gcc 2.3.1 gecompileerd zijn. Je zegt 't maar

[sebas]

Dat wil ik dus graag weten. ... immers luidde mijn vraag of er mensen zijn die ervaring hebben hiermee, en of ik het op mijn systeem zomaar kan installeren.

_{gcc 2.3.1 trouwens?}

[AlterEgo]

Ik heb een gentoo machine geprelinked. Daarmee heb ik me aan de eerder genoemde gentoo guide gehouden (dus het een en ander aan hercompileren).
Het is wel de moeite waard: het opstarten van konqueror/mozilla/openoffice versnelt merkbaar.
Twee mitsen:
> Nvidia: je moet de zaak prelinken zonder de OpenGL-settings van nvidia (Xfree kiezen voordat je begint met prelinken).
> Foldingathome kan geen data fetch als prelinking aanstaat: de client loopt wel, maar data ophalen gaat pas na een prelink -ua.Paardenmiddel om dit probleem te omzeilen

[Wilke]

Ehhh.. gcc 3.2.1 doe maar

gcc (GCC) 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[balk]

Ik heb gewoon die gentoo handleiding gevolgd, wat dingen opnieuw gecompileerd en gezorgd dat ik voldoende schijfruimte had. Ik weet niet wat het minimum is maar een paar GB leek me genoeg

Het ging vrij vlot en zonder echte problemen. Ik heb geen cronjobje oid draaien. Ik hoop dat portage binnenkort geautomatiseerde prelink update ondersteund.

Wat de voordelen betreft: kde progs starten allemaal wat sneller op

[koffiedrinker]

Met de Gentoo Prelinking Guide in de hand heb ik ook alles geprelinked.
En de grotere programma's (mozilla, nautilus, kde in het algemeen) starten inderdaad een stuk sneller op.
De winst was bij mij echt aanzienlijk (AMD 900 Mhz T.bird).
ik vond het de moeite meer dan waard, maar opstartsnelheid blijft natuurlijk wel subjectief .

[blouweKip]

Net ook gedaan (gentoo 1.4rc1), werkt prima (wel ff nvidia opengl uitgezet tijfdens het prelinken), ff zlib enzo opnieuw gecompiled en klaar...

Voelt iig sneller

[Wilke]

Ook gedaan, het was een geklooi, maar uiteindelijk is het geluk. Heb nu (tijdelijk) geen Xinerama, maar dat moet wel weer gaan werken, maar wat vervelender is: ook geen NVidia OpenGL. Dat is statisch gelinkt o.i.d. in ieder geval wil qt-mt dan niet geprelinked worden, heel irritant.

Uiteindelijk vond ik hier de gouden tip om dat te fixen: Prelink, nvidia, qt and opengl-update tip.

Dus, wat cijfertjes dan maar:

Voor:

32137:
32137: runtime linker statistics:
32137: total startup time in dynamic loader: 2037300312 clock cycles
32137: time needed for relocation: 2030450063 clock cycles (99.6%)
32137: number of relocations: 28883
32137: number of relocations from cache: 54962
32137: time needed to load objects: 4859821 clock cycles (.2%)
mcop warning: user defined signal handler found for SIG_PIPE, overriding
32137:
32137: runtime linker statistics:
32137: final number of relocations: 46353
32137: final number of relocations from cache: 109482

Na:

2369: runtime linker statistics:
32369: total startup time in dynamic loader: 5781913 clock cycles
32369: time needed for relocation: 1530687 clock cycles (26.4%)
32369: number of relocations: 0
32369: number of relocations from cache: 1814
32369: time needed to load objects: 3828928 clock cycles (66.2%)
32369:
32369: runtime linker statistics:
32369: final number of relocations: 10513
32369: final number of relocations from cache: 56334

[odysseus]

Kun je eens een benchmark draaien waarbij je zorgt dat er nog geen Qt/KDE-libs geladen zijn en vervolgens een prelinked en een gewone binary start? Dan kun je echt het verschil in laadtijd zien - daar ben ik eigenlijk wel benieuwd naar. Je ziet op veel sites die relocation-counts wel staan, maar dat zegt niet alles over real-world verschillen .

[AlterEgo]

Wilke schreef op 14 januari 2003 @ 19:26:... maar wat vervelender is: ook geen NVidia OpenGL. ...

Jawel hoor: voordat je Tuxracer gaat spelen typ je even opengl-update nvidia, en je hebt weer gewoon opengl accelleratie.
Opengl-update xfree is alleen nodig voor het prelinken zelf.

[deadinspace]

Ik heb zelf een paar dagen geleden alle binaries op mijn laptop (celly-500) geprelinked uit nieuwsgierigheid.

Hoewel de resultaten meetbaar zijn is het allesbehalve schokkend. Ik heb met twee programma's eenvoudige benchmarks uitgevoerd. Ik heb aterm en galeon voor en na het prelinken 100 keer gestart en daarbij gemeten hoelang het starten van de applicatie duurde. De voor-waarden van de na-waarden aftrekken geeft dan de opstarttijd-winst in seconden.

Voor aterm scheelde het 0.011 seconde. Nou is aterm maar tegen weinig libs gelinkt, dus een kleine winst was te verwachten, maar toch is het jammerlijk weinig. Aterm start ik vaak op, dus een kortere opstarttijd zou nuttig geweest zijn.
Voor galeon is het minder interessant, omdat ik die doorgaans maar enkele keren per maand start. Galeon is wel tegen aanzienlijk meer libs gelinkt, dus daar viel een grotere snelheidswinst te verwachten. En jawel: 0.13 seconde. Dat is iets significanter, maar nog steeds niet veel.

Dus volgens mijn benchmarks scheelt het niet heel veel. Altijd leuk meegenomen, en het prelinken is absoluut niet moeilijk (en ging ook niet fout hier), maar ook niets om je echt druk over te maken.

Merk wel op dat er zwaardere applicaties zijn, die tegen meer libs gelinkt zijn. Met die applicaties zal het uiteraard meer schelen (hoe meer relocaties er uitgevoerd moeten worden, hoe meer winst).

Ook is er iets als obj-prelinking wat niet hetzelfde is als "gewone" prelinking. obj-prelinking heeft afaik alleen betrekking op C++ programma's en kan afaik bovenop prelinking worden toegepast.
Omdat de KDE de voornaamste berg C++ progsels is en ik geen KDE gebruik heb ik daar verder weinig over opgezocht en niet mee geexperimenteerd.

[Verwijderd]

ik heb hier 2.4.20 met kde 3.1rc6 draaien, geprelinkt en met -O3 en -fomit-frame-pointer gecompiled. En, dualboot, een 2.4.19 met preempt, kde 3.0.5a, niet geprelinkt en gewoon met -O3 gecompiled.

De geprelinkte setup is zeer veel sneller. Konqueror en ook KDM starten bijna 3x zo snel op (gewoon meteen) en alles voelt sneller. Ook als er zware compiles lopen blijft het systeem vlot reageren, vlot starten etc. (Verbazend omdat ik nu geen preempt heb).

[Verwijderd]

het schijnt overigens dat vooral C++ apps veel voordeel van het prelinken hebben.

[deadinspace]

Verwijderd schreef op 14 January 2003 @ 23:34:
ik heb hier 2.4.20 met kde 3.1rc6 draaien, geprelinkt en met -O3 en -fomit-frame-pointer gecompiled. En, dualboot, een 2.4.19 met preempt, kde 3.0.5a, niet geprelinkt en gewoon met -O3 gecompiled.

Met dezelfde gcc versie of niet?

[Verwijderd]

nee, de eerste met 3.2 en de tweede met 3.2.1