Hi Russ, 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] 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. Kind regards, Jonathan [1] Details: Default preset, using the command xz --stdout zlib-1.2.3.7.tar >/dev/null xz is run in place in the build tree, which means there is also some overhead (though I doubt it is noticeable) from the libtool wrapper script. The “xz in cache” numbers involve running “xz --version” twice before each run to get xz and the libraries it needs into the cache. All numbers are best-of-3, so not precise at all. PIC (s) no PIC (s) difference as % of PIC hot cache: 9.034 8.386 7 cold cache: 9.480 8.931 6 xz in cache: 9.110 8.440 7 /proc/cpuinfo tells me the CPU is Intel family 6, model 8, 601.363 MHz, cache size 128 KB. (model 8 seems to mean it has 256 KB on-die L2.) -- 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/20100223225221.ga8...@progeny.tock