3 ms·
Can you clarify how using dynamic linking would be better for the cache? The amount of code that's in memory/cached would be the same, no?
by uluyol 6y ago
Can you clarify how using dynamic linking would be better for the cache? The amount of code that's in memory/cached would be the same, no?
- atq2119 6y agoLLVM is both a library and a collection of many tools building on that library. Static linking means that almost all of the library code is linked into all of those tools. That's extremely wasteful, especially for debug builds. Luckily, shared library builds of LLVM are easy. And gp might want to invest in a Threadripper. It's possible to compile all of LLVM in a few minutes nowadays :)
- schlupa 6y agoI do not choose the hardware (big bureaucratic organization). I will try the LLVM_LINK_LLVM_DYLIB and LLVM_BUILD_LLVM_DYLIB options next time. By default it builds static binaries and libraries requiring gigabytes of disk space.
- schlupa 6y agoA shared object, even if mapped in 300 running apps will be loaded only once in physical memory (at least for the code segment). Statically built binaries will have each another copy of the code that will be loaded every time the binary is started. So it will be loaded in memory 300 times. I just checked the size of the clang-10 binary that was built. It is fucking 1.9 GB big (gcc 9.2 on the same machine is 6.1 MB).
- jcelerier 6y ago> It is fucking 1.9 GB big (gcc 9.2 on the same machine is 6.1 MB). but you're comparing a debug, unstripped with a release, stripped build ! (also, 6.1 mb seems low for GCC ? the main GCC binary is cc1plus, not gcc / g++)
- schlupa 6y agoThat's what building from source builds by default. I limited the build to X86, I don't need the cross compiling capacity There's probably a combination of options that will reduce the sizes and such, but by default it's gigabyte big binaries statically linked.