Jonathan Nieder <jrnie...@gmail.com> writes: > Russ Allbery wrote:
>> That being said, a 5% performance gain from using statically linked >> non-PIC code doesn't strike me as very compelling even for older systems. > Thank you for your candor; even a hunch like this one is the sort of thing > I was interested to hear. > I got the 6-7% difference (I rounded down) using dynamically linked > non-PIC code. I measured it that way because it seemed more like an > apples-to-apples comparison. [1] Well, by doing that I think you're losing a few of the variables. There are two slowdowns in using dynamic linking: relocation processing on loading the shared library, and the PIC code penalty. The latter is the worst on i386 because it eats a register and the i386 is register-starved; however, you do lose a bit of time just from using dynamic libraries at all since you have to do processing at runtime that you can otherwise do at compile time. But over the course of a longish compression or decompression, it probably doesn't matter very much. > I am a bit disappointed: I was hoping to learn some more concrete > reasons to avoid this sort of use of static linking, but most of the > responses were snarks. Thanks at least for setting me straight. You have a pretty good understanding for the tradeoffs, I think. Non-PIC code is faster on i386, at the cost of being a bit more annoying to maintain and not following the same procedure used on other architectures. And, of course, consuming a bit more disk space, not reusing the shared library among multiple processes, and not allowing the shared library to be upgraded independently from the binary. My personal feeling is that, except for performance-critical code, there's no argument: just go with PIC shared libraries and don't worry about it. It saves effort and all the platforms are the same, which avoids weird i386-only bugs (or vice versa). But you're dealing with one of the few cases of legitimately performance-critical code where it may be worthwhile to care. 5% isn't very much. 10% feels like more. Over 5% and below 10% feels like grey area territory to me. That's all just rough feel. Note, btw, that for some algorithms, you might gain significant speed, more than the PIC difference, by being able to compile for more capable processors (enabling SSE2 can make a huge difference, for instance). Shared libraries let you do that, by building multiple copies of the shared library and installing them into the capability-based library paths. OpenSSL does this. If you link statically, you can't do this and therefore lose the ability to have an SSE2-specific version of the library. But that's additional build system effort to build multiple versions of the library and can be annoying to manage. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocjflf8a....@windlord.stanford.edu
