3 ms·

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.

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.