5 ms·

I have seen a binary that is approximately 1.1GB of text. That is without debug symbols. With debug symbols it would hit GDB address space overflow bugs all the

I have seen a binary that is approximately 1.1GB of text. That is without debug symbols. With debug symbols it would hit GDB address space overflow bugs all the time. You have not seen what 30 year old engineering software houses can produce. And this is not the largest software by any chance. Also, sibling comments argue that kernel samepage merging can help avoid the bloat of static linking. But here what you argue will make every copy of the shared libraries oh-so-slightly-different and therefore prevent KSM from working at all. Really, no one is thinking this through very well. Even distributions that do static linking in all but name (such as NixOS) do still technically use dynamic linking for the disk space and memory savings.

packetlost 2y ago
Your poor I$. The fact of the matter is outside of GPU drivers and poorly designed GUI applications, that's an extreme statistical outlier.
- lostmsu 2y ago
  You mean GPU libraries, right? Just watch how these become used in every other app over the next few years. And yes, the fact that you won't use those apps does not make it easier for the rest of us.
- AshamedCaptain 2y ago
  Sum the GPU driver and the mandatory LLVM requirement that comes with it, and you already have almost half a gigabyte of text per exec. No wonder that your logic forces you to literally dismiss all GUI applications as "extreme statistical outliers" out of hand. For the record, the 1.1GB executable I'm thinking about is a popular _terminal-only_ simulation package. No GUI.
  - nightowl_games 2y ago
    Can't you just tell us what it is?
  - packetlost 2y ago
    Most applications do not use CUDA (I assume that's what you're referring to) and the ones that do only need to pull in the runtime (libcudart_static, in this case) which is nowhere near as big. You don't link all of LLVM into a CUDA application lol
    - AshamedCaptain 2y ago
      For the record any application using shader definitely needs "all of LLVM", and most Gtk+ applications are using shaders due to the ill-conceived notion that GPUs are faster at 2d acceleration. So yes, all GUI apps are linking in all of the graphics driver and all of LLVM.
      - packetlost 2y ago
        Right, but they don't do so using the default loader, it looks like they likely do it via dlopen or similar runtime dynamic linking. If you compile the binaries statically, it wouldn't effect that. I did a little math using a common GTK application as an example: nautilus. Using `ldd` and several shell utilities, if you were to statically link it it clocks in at around 80MB in binary size, but that would be worst case without LTO. FWIW I think graphics stacks are one of the few places where dynamic linking is still highly relevant.
sunshowers 2y ago
Some programs are definitely that complicated, and it's a horrible idea for them to use dynamic binding! The test matrix is absurdly large. (You are testing the software you ship as you ship it, aren't you?)
- AshamedCaptain 2y ago
  By the same logic, you also would have to test the software with every display resolution / terminal width in existance. You are testing the software you ship as you ship it, aren't you? Abstractions are a thing in computer science. Abstracting at the shared library layer makes as much sense as abstracting in the RPC layer (which your software is most likely going to be obligated to do) or abstracting at the ISA level (which your software IS obligated to do). Your software has as many chances to break from a library change as it does from a display driver change or from a screen resolution change or from a processor upgrade. Why the first would bloat the "testing matrix" but not the later is over me, and already shows a bias against dynamic linking: you assume library developers are incapable of keeping an ABI but that the CPU designers are. (Anecdotally, as a CPU designer, I would rather trust the library developers..)
  - sunshowers 2y ago
    In practice, I've seen breakage from shared library updates be much more common than breakage from display resolutions. Many modern software development paradigms are simply not compatible with ABIs or dynamic binding. Dynamic binding also likely means you're leaving a bunch of performance on the table, since inlining across libraries isn't an option.
    - AshamedCaptain 2y ago
      > In practice, I've seen breakage from shared library updates be much more common than breakage from display resolutions. You'd be surprised, specially when I'm thinking 30 year old software. Again, usually I can patch around it thanks to dynamic linking... > Many modern software development paradigms are simply not compatible with ABIs or dynamic binding This is nonsense. > Dynamic binding also likely means you're leaving a bunch of performance on the table, since inlining across libraries isn't an option. Again, why set the goalpost here and not say ISA level or any other abstraction layer? I could literally make the same argument to any of these levels (e.g. "you are leaving a bunch of performance on the table" by not specializing your ISA to your software). How much are you really leaving? And how much would you pay if you remove the abstraction? What are the actual pros/cons?

packetlost 2y ago

Your poor I$. The fact of the matter is outside of GPU drivers and poorly designed GUI applications, that's an extreme statistical outlier.

lostmsu 2y ago
You mean GPU libraries, right? Just watch how these become used in every other app over the next few years. And yes, the fact that you won't use those apps does not make it easier for the rest of us.
AshamedCaptain 2y ago
Sum the GPU driver and the mandatory LLVM requirement that comes with it, and you already have almost half a gigabyte of text per exec. No wonder that your logic forces you to literally dismiss all GUI applications as "extreme statistical outliers" out of hand. For the record, the 1.1GB executable I'm thinking about is a popular _terminal-only_ simulation package. No GUI.
- nightowl_games 2y ago
  Can't you just tell us what it is?
- packetlost 2y ago
  Most applications do not use CUDA (I assume that's what you're referring to) and the ones that do only need to pull in the runtime (libcudart_static, in this case) which is nowhere near as big. You don't link all of LLVM into a CUDA application lol
  - AshamedCaptain 2y ago
    For the record any application using shader definitely needs "all of LLVM", and most Gtk+ applications are using shaders due to the ill-conceived notion that GPUs are faster at 2d acceleration. So yes, all GUI apps are linking in all of the graphics driver and all of LLVM.
    - packetlost 2y ago
      Right, but they don't do so using the default loader, it looks like they likely do it via dlopen or similar runtime dynamic linking. If you compile the binaries statically, it wouldn't effect that. I did a little math using a common GTK application as an example: nautilus. Using `ldd` and several shell utilities, if you were to statically link it it clocks in at around 80MB in binary size, but that would be worst case without LTO. FWIW I think graphics stacks are one of the few places where dynamic linking is still highly relevant.

sunshowers 2y ago

Some programs are definitely that complicated, and it's a horrible idea for them to use dynamic binding! The test matrix is absurdly large. (You are testing the software you ship as you ship it, aren't you?)

AshamedCaptain 2y ago
By the same logic, you also would have to test the software with every display resolution / terminal width in existance. You are testing the software you ship as you ship it, aren't you? Abstractions are a thing in computer science. Abstracting at the shared library layer makes as much sense as abstracting in the RPC layer (which your software is most likely going to be obligated to do) or abstracting at the ISA level (which your software IS obligated to do). Your software has as many chances to break from a library change as it does from a display driver change or from a screen resolution change or from a processor upgrade. Why the first would bloat the "testing matrix" but not the later is over me, and already shows a bias against dynamic linking: you assume library developers are incapable of keeping an ABI but that the CPU designers are. (Anecdotally, as a CPU designer, I would rather trust the library developers..)
- sunshowers 2y ago
  In practice, I've seen breakage from shared library updates be much more common than breakage from display resolutions. Many modern software development paradigms are simply not compatible with ABIs or dynamic binding. Dynamic binding also likely means you're leaving a bunch of performance on the table, since inlining across libraries isn't an option.
  - AshamedCaptain 2y ago
    > In practice, I've seen breakage from shared library updates be much more common than breakage from display resolutions. You'd be surprised, specially when I'm thinking 30 year old software. Again, usually I can patch around it thanks to dynamic linking... > Many modern software development paradigms are simply not compatible with ABIs or dynamic binding This is nonsense. > Dynamic binding also likely means you're leaving a bunch of performance on the table, since inlining across libraries isn't an option. Again, why set the goalpost here and not say ISA level or any other abstraction layer? I could literally make the same argument to any of these levels (e.g. "you are leaving a bunch of performance on the table" by not specializing your ISA to your software). How much are you really leaving? And how much would you pay if you remove the abstraction? What are the actual pros/cons?