5 ms·

Maybe I hyperbolized that a bit. I think there are pros and cons to each approach. The uses cases for static vs dynamic are also different. There are compile ti

Maybe I hyperbolized that a bit. I think there are pros and cons to each approach. The uses cases for static vs dynamic are also different. There are compile time disadvantages to static libraries, and there are security disadvantages to shared libraries. But calling one method better than the other is inane.

Arnt 5y ago
Are you aware of the runtime differences? Both time and space. Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. Compiling with -fPIC reserves one register, which isn't a problem unless you're on a register-starved CPU, which is all of them.
- zozbot234 5y ago
  > Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. You can avoid load-time fixups via prelinking.
- floatboth 5y ago
  > register-starved CPU, which is all of them Really? None of the 64 bit ISAs seem particularly starved, especially not aarch64.
  - kelnos 5y ago
    I think the parent's point is that all registers are precious, and freeing up even one by avoiding dynamic might be worth doing.
  - Arnt 5y ago
    It's not particularly short of registers, but IIRC even aarch64 is short enough that they implemented register renaming. I agree that taking a register away is a much less pressing issue there than on the x86.
    - CalChris 5y ago
      The purpose of register renaming in the AArch64 microarchitectures is to support out-of-order. By comparison, you don't find register renaming in the in-order A53. https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a53 https://en.wikichip.org/wiki/arm_holdings/microarchitectures...
      - Arnt 5y ago
        Suppose you had enough registers, ie. so many that there's no real reason to compilers to save. In that case, you could "support" out-of-order execution by adding a couple sentences to the compiler guidance documentation for your CPU, telling them that they'll get better performance on o-o-o cores if they wait as long as practical with reusing registers.
        CalChris 5y ago
        They've tried variations of this. It takes instruction bits to describe these registers: 32 regs is 5 bits, target + src1 + src2 is 15 bits already. They've tried scratch pads. The Mill CPU's Belt is yet another approach. https://en.wikipedia.org/wiki/Scratchpad_memory https://millcomputing.com/ How to Use 1000 Registers https://caltechconf.library.caltech.edu/200/ 1000 registers would be 10 bits. So they tried register windows. These are all good ideas but they get to compete. So far, I'm a huge AArch64 fan but I now see the purpose of RISC-V. I watched Chris Lattner's ASPLOS talk and it finally clicked. https://www.youtube.com/watch?v=4HgShra-KnY
        Arnt 5y ago
        I know... and it's quite interesting really, but for the purpose of this thread, I think it's safe to say that the CPU-wallahs spend considerable effort on ways to lighten or avoid register pressure, and from that I infer that all of the currently widely used CPUs do have significant pressure. Much more on the x86 than on sane architectures, of course.

Arnt 5y ago

Are you aware of the runtime differences? Both time and space. Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. Compiling with -fPIC reserves one register, which isn't a problem unless you're on a register-starved CPU, which is all of them.

zozbot234 5y ago
> Shared libraries (at least with ELF) requires fixups, which involve COW and a considerable number of per-process pages. You can avoid load-time fixups via prelinking.
floatboth 5y ago
> register-starved CPU, which is all of them Really? None of the 64 bit ISAs seem particularly starved, especially not aarch64.
- kelnos 5y ago
  I think the parent's point is that all registers are precious, and freeing up even one by avoiding dynamic might be worth doing.
- Arnt 5y ago
  It's not particularly short of registers, but IIRC even aarch64 is short enough that they implemented register renaming. I agree that taking a register away is a much less pressing issue there than on the x86.
  - CalChris 5y ago
    The purpose of register renaming in the AArch64 microarchitectures is to support out-of-order. By comparison, you don't find register renaming in the in-order A53. https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a53 https://en.wikichip.org/wiki/arm_holdings/microarchitectures...
    - Arnt 5y ago
      Suppose you had enough registers, ie. so many that there's no real reason to compilers to save. In that case, you could "support" out-of-order execution by adding a couple sentences to the compiler guidance documentation for your CPU, telling them that they'll get better performance on o-o-o cores if they wait as long as practical with reusing registers.
      - CalChris 5y ago
        They've tried variations of this. It takes instruction bits to describe these registers: 32 regs is 5 bits, target + src1 + src2 is 15 bits already. They've tried scratch pads. The Mill CPU's Belt is yet another approach. https://en.wikipedia.org/wiki/Scratchpad_memory https://millcomputing.com/ How to Use 1000 Registers https://caltechconf.library.caltech.edu/200/ 1000 registers would be 10 bits. So they tried register windows. These are all good ideas but they get to compete. So far, I'm a huge AArch64 fan but I now see the purpose of RISC-V. I watched Chris Lattner's ASPLOS talk and it finally clicked. https://www.youtube.com/watch?v=4HgShra-KnY
        Arnt 5y ago
        I know... and it's quite interesting really, but for the purpose of this thread, I think it's safe to say that the CPU-wallahs spend considerable effort on ways to lighten or avoid register pressure, and from that I infer that all of the currently widely used CPUs do have significant pressure. Much more on the x86 than on sane architectures, of course.