Re: Changes in dpkg Pre-Depends
Jonathan Nieder <jrnieder@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: