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/

Curious that Intel seems to recommend dynamic linking to get architecture specific libc function implementations. Dynamic linking has considerable overhead.

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?

> 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.

> 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

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

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.

> In Microsoft Windows, one must link against Kernel32.dll

Not kernel32, but ntdll.

FreeBSD is another OS that provides a stable kernel ABI.

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.

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.

Dynamic linking has considerable advantages in the facilities it provides, which seem to outweigh any efficiency concerns, e.g. in HPC.

-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.

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.

Google has FB do LTO on their large code bases.

FB?

OP probably meant Google and FB.

LTO was used extensively at FB when I worked there, a couple of years ago.

> 15,0000 lines

Did you mean 150,000 or 15,000?

15,000, because I'm too poor to buy a new laptop