Static linking allows LTO with aggressive inlining and is therefore able to achieve far superior performance beyond just the startup time. Arguing that dynamic vs. static has better RAM utilization or not is pointless because nowadays we have plenty of RAM but single core performance is stagnating for almost a decade already. Moores law might give us more transistors but single thread performance is still more or less bound by the clock and transistor switching frequency. Sooner or later static linking will become the only way to move forward and the conveniences dynamic linking offers will not be worth the costs.
Dynamic linking
51–60 of 249 posts
Re: Dynamic linking
#52Say we have program X with dependency Y. X+Y is either dynamic or static. X can either have responsive maintainers or unresponsive maintainers. Y can either change to fix a bug or change to add a bug. (With Heartbleed, I remember our server was fine because we were on some ancient version of OpenSSL.) Here are the scenarios: - dynamic responsive remove bug: Positive/neutral. Team X would have done it anyway. - dynami…
Sure, but I think the most important reason people have in mind when they argue for dynamic linking is that they will receive upstream bugfixes. I don't think your eight cases are equally important.
You are of course right, though, and writing it down like this can be useful.
Re: Dynamic linking
#53> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. That's correct, but also very misleading and leads to the wrong conclusion. The dynamically linked library has references to itself, externally visible or not. It would be wrong to claim that Application.run(); only uses a single symbol of a library. > A good linker will remove unused symbols. With LTO or -f{fu…
> I believe that this the reason why static libraries are usually shipped as separate object files (.o) within ar archives (.a), as those were only linked in on demand.
Yep. One function per C/obj file for smallest static binary possible.
Re: Dynamic linking
#54Earlier quoted context omitted.
> First, this analysis was done on Arch Linux, a source-based distribution. Since you know at compile time what your environment is, I would expect the benefits to be smaller. And of course, this means you're willing to do a lot of recompiles. I run Gentoo as my Linux box. It takes a long time to compile stuff as it is (and I have a 22 core machine). Being forced to compile a lot more because everything is linked sta…
Running Gentoo and complaining about long compile times is like cutting off your leg and complaining that walking hurts.
> Running Gentoo and complaining about long compile times is like cutting off your leg and complaining that walking hurts.
I fail to see the relevance of this comparison.
It's more like wearing fitted clothing and (rationally) objecting to requiring a visit to your tailor every time you change your socks.
Re: Dynamic linking
#55ldd won’t get you all the programs that dynamically load with dlopen... but these are still interesting results.
Re: Dynamic linking
#56Static linking allows LTO with aggressive inlining and is therefore able to achieve far superior performance beyond just the startup time. Arguing that dynamic vs. static has better RAM utilization or not is pointless because nowadays we have plenty of RAM but single core performance is stagnating for almost a decade already. Moores law might give us more transistors but single thread performance is still more or les…
> Arguing that dynamic vs. static has better RAM utilization or not is pointless because nowadays we have plenty of RAM ...
Using more RAM means having lower cache hit ratios. If dynamic linking means using less RAM, you win. But it's not a clear-cut thing -- it will depend a lot on the surrounding ecosystem.
In any case, for C, the problem with static linking is about semantics. Until those are fixed I'll be resolutely against static linking for C, and for everything else, well, do whatever performs best.
Re: Dynamic linking
#57Earlier quoted context omitted.
What do you mean by "source-based distribution"?
One without packages shipped as prebuilt binaries: Gentoo [1] would be a good example. You compile every binary yourself (sometime you can use prebuilt binaries for the biggest software, if you are so inclined and the distro allows it). [1] https://www.gentoo.org/
Doesn't arch use AUR / pacman for binaries / package management? I wasn't aware that like Gentoo you had to compile most software
Re: Dynamic linking
#58these benchmarks dont seem to take into account page cache
Re: Dynamic linking
#59> On average, dynamically linked executables use only 4.6% of the symbols on offer from their dependencies. That's correct, but also very misleading and leads to the wrong conclusion. The dynamically linked library has references to itself, externally visible or not. It would be wrong to claim that Application.run(); only uses a single symbol of a library. > A good linker will remove unused symbols. With LTO or -f{fu…
Also, how many symbols it uses is relevant for the time linking takes, but not for memory usage.
Worse, I think it would have been easier to measure the size in bytes of binaries, or, with a bit more effort, resident memory size.
Re: Dynamic linking
#60Earlier quoted context omitted.
Run htop or similar, sort by "shared memory" column and see how much more memory you'd need per process if shared linking did not exist. I think the author's using a wrong method to make a point. Dynamic linking feels out of place for most long-running server-side apps (typical SaaS workload). One can argue that in a mostly CLI-environment there's also not much benefit. But even an empty Ubuntu desktop runs ~400 proc…
That is an extremely misleading figure. Shared memory is page-aligned entire libraries dropped into RAM. Statically linking would, as the article shows, only use on average about 4% of the symbols available from the libraries, and the majority of this would not end up in RAM with your statically linked binary. And if you used a more selective approach, dynamically linking to no more than perhaps a dozen high-impact l…
@ddevault: performance is only part of the story. The poverty of semantics of C static linking is atrocious -- it could be fixed, but until it is we should not statically link C programs.