a better comparison [LWN.net]

a better comparison

Posted Oct 6, 2003 20:26 UTC (Mon) by mattdm (subscriber, #18)
Parent article: Gentoo Weekly Newsletter

Is it really the optimization that's causing the speed increase, or is it some other factor? A valid scientific comparison requires only one variable to be changed; therefore, the "control" should be Gentoo built with no optimization, compared against the exact same thing built with various degrees of optimization (i386, PIII, -march=i386 -mcpu=i686, etc.).

(Log in to post comments)

a better comparison

Posted Oct 7, 2003 21:31 UTC (Tue) by torsten (guest, #4137) [Link]

"Is it really the optimization that's causing the speed increase, or is it some other factor?"

While gentoo is famous for its ability to optimize everything, automagically, this is not the factor in load times. What they mentioned in the article is "prelinking", which was originally developed as a technique for glibc-2.3.X, whereby the libraries needed for an executable are "prelinked" and don't have to be resolved at runtime. Basically, the path of the library is stored in the executable. This way, the location of the library doesn't need to be resolved at run time, decreasing load times. If the libraries don't change locations much, it works well. If the libraries do change location, then the program needs to be relinked. If the location of the library is incorrect, then the library loader defaults back to the normal, non-optimized behavior.

The technique was developed at RedHat, as a way to increase KDE load times. Prelinking is a little more complicated than this, and I have difficulty deciphering the website text.

From http://freshmeat.net/projects/prelink/?topic_id=253

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.

a better comparison

Posted Oct 9, 2003 14:31 UTC (Thu) by nix (subscriber, #2304) [Link]

Prelinking doesn't store paths anywhere. Storing the paths of shared libraries in the binary would be a complete waste of time, because the paths are *already* cached in /etc/ld.so.cache.

What prelinking does is tries to find a set of initial load addresses for all the shared libraries on the system such that those addresses are available in every binary that needs those libraries; then it modifies the libraries accordingly. Libraries prepared in this way don't require relocation (or at least not much; C++ code in particular still has two relocations per virtual method table entry) and so startup times are reduced because ld-linux.so.2 doesn't have to do all that relocation at startup time, and memory consumption is reduced because fewer text pages are marked writable.

Downsides:
- obviously binaries you build after running prelink might require relocations, and shared libraries you build after running prelink almost certainly will. But they would have done had you never run prelink at all, so this is not much of a loss.
- prelink modifies system libraries. So their md5sums will change, tripwire and samhain will trip unexpectedly, and if you're doing it while the system is running your memory consumption will go *up* afterwards because all those libraries have changed inode numbers so text page sharing between the pre- and post-relocation copies of the library can't take place.
- dlopen()ed shared libraries can't benefit, because there's no way prelink can tell that they're used (working it out for sure would require solving the halting problem).
- binaries and shared libraries must be linked correctly; e.g. if they use symbols from a library foo, they *must* say -lfoo at link time or prelink will get confused. (Before now, if a library they relied upon themselves pulled in the library they needed, they could just use that; but that is fragile.)

a better comparison

Posted Oct 9, 2003 14:38 UTC (Thu) by nix (subscriber, #2304) [Link]

Note that in this content 'relocation' is talking about *symbols* (i.e. 'changing things in memory so that the program knows what address the library is located at') and *not* 'relocating the libraries' in the sense of moving them around in the filesystem. You can still freely do that after running prelink without losing its benefits.

(And the impetus was finding a way to *reduce* KDE startup times; going to all this effort to make things take longer to start would be rather peculiar.)