5 ms·

On single user systems, sure. However multi user systems can benefit greatly from dynamic linking; some highly multi user systems become impossible to create at

by tssge 2y ago

On single user systems, sure. However multi user systems can benefit greatly from dynamic linking; some highly multi user systems become impossible to create at all with only static linking (RAM demand becomes too great). Dynamic linking also leads to better CPU cache utilization and thus higher performance; provided if multiple applications are actually utilizing the dynamically linked library. While RAM is somewhat abundant these days, L1/L2/L3 cache on your CPU most definitely isn't. Application startup times are also of higher performance when part of the code is already in memory. EDIT: Let me elaborate a bit on what I mean by "benefiting greatly" with a real world example. I have a system with around 300 tenants with a minimum of 500 PHP processes online at any given time. A single PHP process is able to load 70MB worth of dynamically linked libraries (PHP extensions) if so chosen by the tenant. I'll just skip libc and other such libraries to give static linking a chance. With dynamic linking, the maximum memory requirement is 70MB for said extensions. With static linking, the maximum memory requirement is 35GB for said extensions. Dynamic linking thus leads to 99,8% cost saving on memory usage. Bear in mind this is at minimum load: static linking requirements will scale linearly with load. Not to even get started on the performance benefits this brings...

gpm 2y ago
Are these extensions standard across your users, or are they user supplied? If the former is the case, in a world where dynamic linking wasn't "the way things were done", you'd just just statically link them all into the PHP interpreters binary, and then only run the code to actually start them for the users that want them. Linux shares memory between the different instances of the same executable the same way it does between different instances of a shared library, there should be no difference in cost. Today, I doubt php supports this, particularly the "only run the code to actually start them" part, but in principle it's a lot simpler than dynamic linking to do that. If the latter is the case, how are you getting any savings today?
- tssge 2y ago
  >Are these extensions standard across your users, or are they user supplied? These extensions are standard PHP extensions, so they are the same for each process and user. Extensions like MySQL driver, Postgres driver, ImageMagick bindings and such. You are correct that no savings would be possible if these were different across each user.
  - a1369209993 2y ago
    > These extensions are standard PHP extensions, so they are the same for each process and user. Then with static linking, the maximum memory requirement is 70MB for said extensions (statically linked into the PHP executable).
    - tssge 2y ago
      Are you basically saying there is no difference in memory usage when comparing static linking and dynamic linking? Any links to more info on the matter? I tested this on the machine with a static executable I compiled it looks to me that memory is not shared when statically linked. I thought the point of dynamic linking anyways was to save memory by sharing it (and disk space, though these days we have more than enough for executable code). Though it could be just that I misunderstand the output of smaps_rollup.
      - rcxdude 2y ago
        Multiple executions of the same executable will share the code pages, so assuming all the users are executing the same binary on disk, the memory should be shared. Shared libraries only give you additional deduplication in the case that multiple binaries are loading the same shared libraries.
      - rfoo 2y ago
        > Are you basically saying there is no difference in memory usage when comparing static linking and dynamic linking? In your case, yes, there is (almost [1]) no difference at all. If you have 500 different PHP binaries (say, different version of PHP) with same set of extension `.so`-s shared between them (is this even possible?? but let's assume it is), then your example works. [1] Almost, because if you also linked libc statically (not recommended as glibc is specifically designed to be hostile to static linking), you can't share libc with other processes (e.g. nginx, systemd, etc) so you need ~2MB more memory, this is still paid only once, not multiplied by how many php binary you run, though.
        2y ago
cryptonector 2y ago
When the changes to Solaris 10 got pushed that removed static link archives for the OS/Net core, and which replaced all the statically-linked /bin executables with dynamically-linked versions, boot times improved drastically owing to less I/O being needed because of the sharing.

by tssge 2y ago

gpm 2y ago

Are these extensions standard across your users, or are they user supplied? If the former is the case, in a world where dynamic linking wasn't "the way things were done", you'd just just statically link them all into the PHP interpreters binary, and then only run the code to actually start them for the users that want them. Linux shares memory between the different instances of the same executable the same way it does between different instances of a shared library, there should be no difference in cost. Today, I doubt php supports this, particularly the "only run the code to actually start them" part, but in principle it's a lot simpler than dynamic linking to do that. If the latter is the case, how are you getting any savings today?

tssge 2y ago
>Are these extensions standard across your users, or are they user supplied? These extensions are standard PHP extensions, so they are the same for each process and user. Extensions like MySQL driver, Postgres driver, ImageMagick bindings and such. You are correct that no savings would be possible if these were different across each user.
- a1369209993 2y ago
  > These extensions are standard PHP extensions, so they are the same for each process and user. Then with static linking, the maximum memory requirement is 70MB for said extensions (statically linked into the PHP executable).
  - tssge 2y ago
    Are you basically saying there is no difference in memory usage when comparing static linking and dynamic linking? Any links to more info on the matter? I tested this on the machine with a static executable I compiled it looks to me that memory is not shared when statically linked. I thought the point of dynamic linking anyways was to save memory by sharing it (and disk space, though these days we have more than enough for executable code). Though it could be just that I misunderstand the output of smaps_rollup.
    - rcxdude 2y ago
      Multiple executions of the same executable will share the code pages, so assuming all the users are executing the same binary on disk, the memory should be shared. Shared libraries only give you additional deduplication in the case that multiple binaries are loading the same shared libraries.
    - rfoo 2y ago
      > Are you basically saying there is no difference in memory usage when comparing static linking and dynamic linking? In your case, yes, there is (almost [1]) no difference at all. If you have 500 different PHP binaries (say, different version of PHP) with same set of extension `.so`-s shared between them (is this even possible?? but let's assume it is), then your example works. [1] Almost, because if you also linked libc statically (not recommended as glibc is specifically designed to be hostile to static linking), you can't share libc with other processes (e.g. nginx, systemd, etc) so you need ~2MB more memory, this is still paid only once, not multiplied by how many php binary you run, though.
      - 2y ago

cryptonector 2y ago

When the changes to Solaris 10 got pushed that removed static link archives for the OS/Net core, and which replaced all the statically-linked /bin executables with dynamically-linked versions, boot times improved drastically owing to less I/O being needed because of the sharing.