6 ms·

Forgetting about Rust for a second. Talking about dynamically linked libs in general. Dynamic linking was an optimization which came about when memory was expe

Forgetting about Rust for a second. Talking about dynamically linked libs in general. Dynamic linking was an optimization which came about when memory was expensive. Memory is no longer expensive. Is 1.3GB (or even 13GB) a lot on your hardware[1]? According to "Do not prematurely optimize": Pretending we never had dynamic linking, and given today's hardware constraints[2], as a community would we choose to reimplement and universally adopt this optimization? [1] Keep in mind that a single "modern" application, on average, weighs in the 10s of MBs or GBs. [2] I'm talking about the general case, for the majority of OS distributions, ignoring the relatively exceptional case of embedded systems, which do in-fact still need it.

Retra 10y ago
Yes, we would. Not because it's 'premature optimization', but because it's easy optimization. "Do not prematurely optimize" is not a software design rule, it's a time-management rule. Dynamic linking has software design impacts.
- kbenson 10y ago
  > "Do not prematurely optimize" is not a software design rule, it's a time-management rule. No, it's both. Optimization often affects the cost of later decisions, and the reason not to prematurely optimize is because it can easily take you to a local optimum which is not very optimal at all. This is a perfect example of that, as the GP comment point out. If memory is not constrained as it was when this trade-off became common, it may not have become prevalent. Static binaries are faster (the degree to which depending on a lot of factors), while dynamic binaries are smaller on disk and in memory, if the shared libraries are already used elsewhere. Modern optimizations at the OS level for forking and threading should make consideration of those negligible.
  - Retra 10y ago
    Dynamic linking wasn't invented as a premature optimization though. And if it didn't exist today, it would still not be premature to invent it, because dynamic linking does not only concern how large and fast your program is, but also how it is interacted with. So here is my point: optimization that can affect the relevant interfaces of your software is not premature because deciding on the interfaces your software exposes is not premature.
    - kbenson 10y ago
      You are choosing to focus on the "premature optimization" wording, which is fair, it was said. I'm focusing on "as a community would we choose to reimplement and universally adopt this optimization?" (emphasis mine). I think it would be implemented, I do not know of any evidence that makes me believe it would become universally adopted given modern resources.
      - Retra 10y ago
        What do you mean by 'universally adopted?' Available on all platforms? Default linking strategy? All code is dynamically linked?
        kbenson 10y ago
        I'm not sure exactly what was originally meant, I interpreted it as how currently dynamic linking is the norm, is used in every mainstream OS and most the applications run on them, and all the major mobile platforms. If we had to make a choice right now without the history of dynamic linking behind us, would we still choose to use it for the majority of platforms?
        yazaddaruvala 10y ago
        FWIW: You appropriately articulated how I meant 'universally adopted'. Nit: "Use it for the majority of platforms [and/or for the majority of applications]?"
- robryk 10y ago
  Is it really easy? It brings with it many versioning problems.
yongjik 10y ago
Main memory is cheap but slow. Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. Even latest desktop processors have a L3 cache of only a few MB.
- tatterdemalion 10y ago
  But static linking could mean that function will be inlined.
  - adrianratnapala 10y ago
    It means that function might be inlined. And sufficiently aggressive inlining will increase the program size further. This might or might not be compensated for by the increase in instruction-pointer locality.
  - angry_octet 10y ago
    Inlining saves time lost due to jumping about, but it can cost time if it causes code replication (same as loop unrolling), because it can bloat the hot code to larger than the smallest cache. So the arguments against inlining apply even more strongly when talking about every program being statically linked, the same code (standard library) will exist in memory in many places, and will get dumped and reloaded to L2/L3 every process swap. Nothing slower than having to wait for something to be faulted in.
    - majewsky 10y ago
      > Nothing slower than having to wait for something to be faulted in. There is something slower. When your executables are so large that you have to hit the swap drive on process swaps.
- netheril96 10y ago
  > Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. I am under the impression that when process switches the CPU caches are flushed.
markus2012 10y ago
Memory is terribly expensive and I have to fight all of the other developers/product folks/upper management for every byte in my environment (hundreds of thousands of servers). I have no choice but to use DSOs for our Rust code.
rtpg 10y ago
Dynamic linking also lets you update libraries due to things like security issues, it's not just a memory thing. Kinda agree on the space thing too (plus much less chance for things like buffer overflows..)
- kbenson 10y ago
  This was a much more powerful reason before things like docker became common, and methodologies adapted to provide updates for docker images, which for this purpose are functionally identical to a static binary. At least I hope "methodologies adapted", I don't use docker images, so that's an assumption on my part, but I feel it's a fairly safe bet.
  - cyphar 10y ago
    Docker images don't have a nice way of updating without "rebuilding everything". There's a tool called zypper-docker that does allow you to update images, but there's no underlying support for rebasing (updating) in Docker. I was working on something like that for a while, but it's non-trivial to make it work properly.
    - kbenson 10y ago
      Hmm, I assumed it would be something along the lines of the images being fairly static, and updated as a whole, and you just apply your configs and data, possibly through mount points.
      - cyphar 10y ago
        I was responding to the comment that security updates to libraries make it harder to update static binaries. Docker has revived the problem, and there isn't a way of nicely updating images without rebuilding them (which in turn means you have to do a rollout of the new images). While it's not a big deal, it causes some issues that could be avoided.
        10y ago
santaclaus 10y ago
> Is 1.3GB (or even 13GB) a lot on your hardware On my phone or tablet, that is most definitely a lot.
mcguire 10y ago
A library update would require rebuilding every application that uses the library. A change to libc would require effectively reinstalling the OS. At that point, an extra 1.3GB would just be icing on the download.
jeffdavis 10y ago
Dynamic linking offers modularity and separation of concerns. I don't really care which point-release of zlib my program is linked with, I just want to decompress stuff. If someone finds a bug (or exploit), I am not the best person to quickly realize it and release an update -- the maintainer of zlib, and the packagers, and OS distributions, and sysadmins are in a much better position. But if it's statically linked, then developers have to be involved. You could say that we could invent a mechanism to allow sysadmins to rebuild with patched libraries, but then we'd still need to reinvent all of the versioning and other headaches of dynamic libraries. I think dynamic libraries are kind of like microservices. Sure, they can break stuff, but they allow higher degrees of complexity to still be manageable.
bjourne 10y ago
Dynamic linking certainly has no technical advantages like lower memory/disk usage or faster processing. Its main advantage, which has been cited before, is that it forces cohesion in the Linux community. E.g if an author of a program finds a problem in the dynamic library he or she is using, the problem is forced to be solved upstream, benefitting all users of the library. If instead static linking was the norm, it is much more likely that the author would just solve the problem for him or herself and the solution would never reach the wider community. In the best of worlds, we would have static linking everywhere but the "social contract" of dynamic linking would be enforced just as strongly.

Retra 10y ago

Yes, we would. Not because it's 'premature optimization', but because it's easy optimization. "Do not prematurely optimize" is not a software design rule, it's a time-management rule. Dynamic linking has software design impacts.

kbenson 10y ago
> "Do not prematurely optimize" is not a software design rule, it's a time-management rule. No, it's both. Optimization often affects the cost of later decisions, and the reason not to prematurely optimize is because it can easily take you to a local optimum which is not very optimal at all. This is a perfect example of that, as the GP comment point out. If memory is not constrained as it was when this trade-off became common, it may not have become prevalent. Static binaries are faster (the degree to which depending on a lot of factors), while dynamic binaries are smaller on disk and in memory, if the shared libraries are already used elsewhere. Modern optimizations at the OS level for forking and threading should make consideration of those negligible.
- Retra 10y ago
  Dynamic linking wasn't invented as a premature optimization though. And if it didn't exist today, it would still not be premature to invent it, because dynamic linking does not only concern how large and fast your program is, but also how it is interacted with. So here is my point: optimization that can affect the relevant interfaces of your software is not premature because deciding on the interfaces your software exposes is not premature.
  - kbenson 10y ago
    You are choosing to focus on the "premature optimization" wording, which is fair, it was said. I'm focusing on "as a community would we choose to reimplement and universally adopt this optimization?" (emphasis mine). I think it would be implemented, I do not know of any evidence that makes me believe it would become universally adopted given modern resources.
    - Retra 10y ago
      What do you mean by 'universally adopted?' Available on all platforms? Default linking strategy? All code is dynamically linked?
      - kbenson 10y ago
        I'm not sure exactly what was originally meant, I interpreted it as how currently dynamic linking is the norm, is used in every mainstream OS and most the applications run on them, and all the major mobile platforms. If we had to make a choice right now without the history of dynamic linking behind us, would we still choose to use it for the majority of platforms?
        yazaddaruvala 10y ago
        FWIW: You appropriately articulated how I meant 'universally adopted'. Nit: "Use it for the majority of platforms [and/or for the majority of applications]?"
robryk 10y ago
Is it really easy? It brings with it many versioning problems.

yongjik 10y ago

Main memory is cheap but slow. Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. Even latest desktop processors have a L3 cache of only a few MB.

tatterdemalion 10y ago
But static linking could mean that function will be inlined.
- adrianratnapala 10y ago
  It means that function might be inlined. And sufficiently aggressive inlining will increase the program size further. This might or might not be compensated for by the increase in instruction-pointer locality.
- angry_octet 10y ago
  Inlining saves time lost due to jumping about, but it can cost time if it causes code replication (same as loop unrolling), because it can bloat the hot code to larger than the smallest cache. So the arguments against inlining apply even more strongly when talking about every program being statically linked, the same code (standard library) will exist in memory in many places, and will get dumped and reloaded to L2/L3 every process swap. Nothing slower than having to wait for something to be faulted in.
  - majewsky 10y ago
    > Nothing slower than having to wait for something to be faulted in. There is something slower. When your executables are so large that you have to hit the swap drive on process swaps.
netheril96 10y ago
> Having a frequently called function in a shared library vs. statically linked code could mean the difference of the code executing from CPU's cache or from main memory. I am under the impression that when process switches the CPU caches are flushed.

markus2012 10y ago

Memory is terribly expensive and I have to fight all of the other developers/product folks/upper management for every byte in my environment (hundreds of thousands of servers). I have no choice but to use DSOs for our Rust code.

rtpg 10y ago

Dynamic linking also lets you update libraries due to things like security issues, it's not just a memory thing. Kinda agree on the space thing too (plus much less chance for things like buffer overflows..)

kbenson 10y ago
This was a much more powerful reason before things like docker became common, and methodologies adapted to provide updates for docker images, which for this purpose are functionally identical to a static binary. At least I hope "methodologies adapted", I don't use docker images, so that's an assumption on my part, but I feel it's a fairly safe bet.
- cyphar 10y ago
  Docker images don't have a nice way of updating without "rebuilding everything". There's a tool called zypper-docker that does allow you to update images, but there's no underlying support for rebasing (updating) in Docker. I was working on something like that for a while, but it's non-trivial to make it work properly.
  - kbenson 10y ago
    Hmm, I assumed it would be something along the lines of the images being fairly static, and updated as a whole, and you just apply your configs and data, possibly through mount points.
    - cyphar 10y ago
      I was responding to the comment that security updates to libraries make it harder to update static binaries. Docker has revived the problem, and there isn't a way of nicely updating images without rebuilding them (which in turn means you have to do a rollout of the new images). While it's not a big deal, it causes some issues that could be avoided.
      - 10y ago

santaclaus 10y ago

> Is 1.3GB (or even 13GB) a lot on your hardware On my phone or tablet, that is most definitely a lot.

mcguire 10y ago

A library update would require rebuilding every application that uses the library. A change to libc would require effectively reinstalling the OS. At that point, an extra 1.3GB would just be icing on the download.

jeffdavis 10y ago

Dynamic linking offers modularity and separation of concerns. I don't really care which point-release of zlib my program is linked with, I just want to decompress stuff. If someone finds a bug (or exploit), I am not the best person to quickly realize it and release an update -- the maintainer of zlib, and the packagers, and OS distributions, and sysadmins are in a much better position. But if it's statically linked, then developers have to be involved. You could say that we could invent a mechanism to allow sysadmins to rebuild with patched libraries, but then we'd still need to reinvent all of the versioning and other headaches of dynamic libraries. I think dynamic libraries are kind of like microservices. Sure, they can break stuff, but they allow higher degrees of complexity to still be manageable.

bjourne 10y ago

Dynamic linking certainly has no technical advantages like lower memory/disk usage or faster processing. Its main advantage, which has been cited before, is that it forces cohesion in the Linux community. E.g if an author of a program finds a problem in the dynamic library he or she is using, the problem is forced to be solved upstream, benefitting all users of the library. If instead static linking was the norm, it is much more likely that the author would just solve the problem for him or herself and the solution would never reach the wider community. In the best of worlds, we would have static linking everywhere but the "social contract" of dynamic linking would be enforced just as strongly.