4 ms·

-flto is great if your project is less than 15,0000 lines. Otherwise, -Ofast in conjunction with -flto creates a single threaded link time step that's longer th

-flto is great if your project is less than 15,0000 lines. Otherwise, -Ofast in conjunction with -flto creates a single threaded link time step that's longer than half a minute, and it only goes up from there

vii 6y ago
The gold linker and now lld can do LTO pretty fast across huge codebases: this breaks down the techniques used https://archive.fosdem.org/2019/schedule/event/llvm_lld/ https://archive.fosdem.org/2019/schedule/event/llvm_lld/ Curious that Intel seems to recommend dynamic linking to get architecture specific libc function implementations. Dynamic linking has considerable overhead.
- btown 6y ago
  I’m curious why this is necessary nowadays. Why not just ship a multi architecture static libc that chooses implementation at runtime? Branch prediction should make that practically zero cost, and with cache sizes at all levels I doubt binary size would have an impact. Are there other reasons?
  - nicoburns 6y ago
    > Are there other reasons? I think some systems don't have a stable kernel interface. The system-provided libc is that interface. On Linux I believe that this is possible (and fairly common using the MUSL libc), but that glibc doesn't support static linking and many people want to use glibc for performance and compatibility reasons.
    - roblabla 6y ago
      > I think some systems don't have a stable kernel interface. The system-provided libc is that interface. In fact, a lot of systems don't have a stable kernel interface, Linux is the exceptions here. In Microsoft Windows, one must link against Kernel32.dll to communicate with the kernel. On OpenBSD, the libc provides the stable syscall interface (and in fact the kernel will refuse syscalls from outside the libc as a security measure, see [0]). MacOS and Solaris are two other OSes where, if I understand correctly, syscall ABI is not guaranteed and must go through a common library. Go used to embed syscalls, and ran into a lot of problems because of this. [0]: https://marc.info/?l=openbsd-tech&m=157488907117170&w=2 https://marc.info/?l=openbsd-tech&m=157488907117170&w=2
      - voldacar 6y ago
        I get that openbsd is obsessed with security, but this still makes me a little sad. C is very old, and it should be possible to create programs and programming languages that have no idea what C is or what libc is. Forcing all programs to communicate with the OS via libc seems wrong
        roblabla 6y ago
        On one hand, from an idealistic point of view, I agree, and am a very, very big believer of having actual, carefully designed ABIs for kernel (and inter-process) communications. On the other hand, the structures required to do syscalls via libc/kernel32 are generally simple enough that it's not a huge deal, and the difference between doing a raw syscall and doing a function call is unlikely to actually matter. Fun fact/pet peeve: on android, if you want to communicate with most services, you need to go through Binder. While the low-level Binder ABI is stable, the services written on top of it aren't, and often change in backwards-incompatible ways. This includes core services like SurfaceFlinger (necessary to draw on the screen). This means that it's generally impossible to create purely native software on android - you always have to call into Java to talk to those services.
      - moonchild 6y ago
        > In Microsoft Windows, one must link against Kernel32.dll Not kernel32, but ntdll. FreeBSD is another OS that provides a stable kernel ABI.
  - xxpor 6y ago
    The L1 icache on most Arm chips is still fairly tiny. For example on the Snapdragon 865, it's only 64k. An i7-8700k (already 3 years old) on the other hand has 192k.
    - kjs3 6y ago
      That's pretty meaningless. The effect of cache is very processor and ISA specific and has a log tail of value (as in, depending on the processor, X amount of cache may get you a 50% speedup, but 2 times X might only give you 60% so is the cost/benefit trade-off worth it). It's plausible that the i7 needs 3 times the cache to get the same benefit and the 64k in the 865. N.B. I don't know for sure that that is the case.
- gnufx 6y ago
  Dynamic linking has considerable advantages in the facilities it provides, which seem to outweigh any efficiency concerns, e.g. in HPC.
google234123 6y ago
Google has FB do LTO on their large code bases.
- sp332 6y ago
  FB?
  - woadwarrior01 6y ago
    OP probably meant Google and FB. LTO was used extensively at FB when I worked there, a couple of years ago.
jhallenworld 6y ago
-flto is great at the other end of the spectrum- tiny systems. With "-Os -lto", much unused code from newlib is deleted, allowing the rest to fit in a tiny Cortex-M0 system. In the old days, each function of the C library was in its own object file in the library, but these days this appears to not be the case. But -lto gives the same effect.
- bigdict 6y ago
  I use it too for embedded. Functions get inlined, fewer registers get saved unnecessarily in functions. I also use “-fdata-sections -ffunction-sections” with “-Wl,--gc-sections” to prune unused sections. There is some evidence this can actually increase your code size sometimes: https://stackoverflow.com/a/29951897 https://stackoverflow.com/a/29951897.
abra529 6y ago
> 15,0000 lines Did you mean 150,000 or 15,000?
- glouwbug 6y ago
  15,000, because I'm too poor to buy a new laptop

vii 6y ago

The gold linker and now lld can do LTO pretty fast across huge codebases: this breaks down the techniques used https://archive.fosdem.org/2019/schedule/event/llvm_lld/ https://archive.fosdem.org/2019/schedule/event/llvm_lld/ Curious that Intel seems to recommend dynamic linking to get architecture specific libc function implementations. Dynamic linking has considerable overhead.

btown 6y ago
I’m curious why this is necessary nowadays. Why not just ship a multi architecture static libc that chooses implementation at runtime? Branch prediction should make that practically zero cost, and with cache sizes at all levels I doubt binary size would have an impact. Are there other reasons?
- nicoburns 6y ago
  > Are there other reasons? I think some systems don't have a stable kernel interface. The system-provided libc is that interface. On Linux I believe that this is possible (and fairly common using the MUSL libc), but that glibc doesn't support static linking and many people want to use glibc for performance and compatibility reasons.
  - roblabla 6y ago
    > I think some systems don't have a stable kernel interface. The system-provided libc is that interface. In fact, a lot of systems don't have a stable kernel interface, Linux is the exceptions here. In Microsoft Windows, one must link against Kernel32.dll to communicate with the kernel. On OpenBSD, the libc provides the stable syscall interface (and in fact the kernel will refuse syscalls from outside the libc as a security measure, see [0]). MacOS and Solaris are two other OSes where, if I understand correctly, syscall ABI is not guaranteed and must go through a common library. Go used to embed syscalls, and ran into a lot of problems because of this. [0]: https://marc.info/?l=openbsd-tech&m=157488907117170&w=2 https://marc.info/?l=openbsd-tech&m=157488907117170&w=2
    - voldacar 6y ago
      I get that openbsd is obsessed with security, but this still makes me a little sad. C is very old, and it should be possible to create programs and programming languages that have no idea what C is or what libc is. Forcing all programs to communicate with the OS via libc seems wrong
      - roblabla 6y ago
        On one hand, from an idealistic point of view, I agree, and am a very, very big believer of having actual, carefully designed ABIs for kernel (and inter-process) communications. On the other hand, the structures required to do syscalls via libc/kernel32 are generally simple enough that it's not a huge deal, and the difference between doing a raw syscall and doing a function call is unlikely to actually matter. Fun fact/pet peeve: on android, if you want to communicate with most services, you need to go through Binder. While the low-level Binder ABI is stable, the services written on top of it aren't, and often change in backwards-incompatible ways. This includes core services like SurfaceFlinger (necessary to draw on the screen). This means that it's generally impossible to create purely native software on android - you always have to call into Java to talk to those services.
    - moonchild 6y ago
      > In Microsoft Windows, one must link against Kernel32.dll Not kernel32, but ntdll. FreeBSD is another OS that provides a stable kernel ABI.
- xxpor 6y ago
  The L1 icache on most Arm chips is still fairly tiny. For example on the Snapdragon 865, it's only 64k. An i7-8700k (already 3 years old) on the other hand has 192k.
  - kjs3 6y ago
    That's pretty meaningless. The effect of cache is very processor and ISA specific and has a log tail of value (as in, depending on the processor, X amount of cache may get you a 50% speedup, but 2 times X might only give you 60% so is the cost/benefit trade-off worth it). It's plausible that the i7 needs 3 times the cache to get the same benefit and the 64k in the 865. N.B. I don't know for sure that that is the case.
gnufx 6y ago
Dynamic linking has considerable advantages in the facilities it provides, which seem to outweigh any efficiency concerns, e.g. in HPC.

google234123 6y ago

Google has FB do LTO on their large code bases.

sp332 6y ago
FB?
- woadwarrior01 6y ago
  OP probably meant Google and FB. LTO was used extensively at FB when I worked there, a couple of years ago.

jhallenworld 6y ago

-flto is great at the other end of the spectrum- tiny systems. With "-Os -lto", much unused code from newlib is deleted, allowing the rest to fit in a tiny Cortex-M0 system. In the old days, each function of the C library was in its own object file in the library, but these days this appears to not be the case. But -lto gives the same effect.

bigdict 6y ago
I use it too for embedded. Functions get inlined, fewer registers get saved unnecessarily in functions. I also use “-fdata-sections -ffunction-sections” with “-Wl,--gc-sections” to prune unused sections. There is some evidence this can actually increase your code size sometimes: https://stackoverflow.com/a/29951897 https://stackoverflow.com/a/29951897.

abra529 6y ago

> 15,0000 lines Did you mean 150,000 or 15,000?

glouwbug 6y ago
15,000, because I'm too poor to buy a new laptop