HN

Comments (28)

• Menu

  yjftsjthsd-h
  > I had observed binaries beyond 25GiB, including debug symbols. How is this possible? These companies prefer to statically build their services to speed up startup and simplify deployment. Statically including all code in some of the world’s largest codebases is a recipe for massive binaries.I am very sympathetic to wanting nice static binaries that can be shipped around as a single artifact[0], but... surely at some point we have to ask if it's worth it? If nothing else, that feels like a little bit of a code smell; surely if your actual executable code doesn't even fit in 2GB it's time to ask if that's really one binary's worth of code or if you're actually staring at like... a dozen applications that deserve to be separate? Or get over it the other way and accept that sometimes the single artifact you ship is a tarball / OCI image / EROFS image for systemd[1] to mount+run / self-extracting archive[2] / ...[0] Seriously, one of my background projects right now is trying to figure out if it's really that hard to make fat ELF binaries.[1] https://systemd.io/PORTABLE_SERVICES/[2] https://justine.lol/ape.html > "PKZIP Executables Make Pretty Good Containers"
• Menu

  10000truths
  Debug symbol size shouldn't be influencing relocation jump distances - debug info has its own ELF section.Regardless of whether you're FAANG or not, nothing you're running should require an executable with a 2 GB large .text section. If you're bumping into that limit, then your build process likely lacks dead code elimination in the linking step. You should be using LTO for release builds. Even the traditional solution (compile your object files with -ffunction-sections and link with --gc-sections) does a good job of culling dead code at function-level granularity.
• Menu

  stncls
  > The simplest solution however is to use -mcmodel=large which changes all the relative CALL instructions to absolute JMP.Makes sense, but in the assembly output just after, there is not a single JMP instruction. Instead, CALL <immediate> is replaced with putting the address in a 64-bit register, then CALL <register>, which makes even more sense. But why mention the JMP thing then? Is it a mistake or am I missing something? (I know some calls are replaced by JMP, but that's done regardless of -mcmodel=large)
• yablak
  > We would like to keep our small code-model. What other strategies can we pursue?Move all the hot BBs near each other, right?Facebook's solution: https://github.com/llvm/llvm-project/blob/main/bolt%2FREADME...Google's:https://lists.llvm.org/pipermail/llvm-dev/2019-September/135...
• Menu

  doubletwoyou
  25 GiB for a single binary sounds horrifyingat some point surely some dynamic linking is warranted
• anon
  undefined
• Menu

  a_t48
  I've seen terrible, terrible binary sizes with Eigen + debug symbols, due to how Eigen lazy evaluation works (I think). Every math expression ends up as a new template instantiation.
• Menu

  gerikson
  The HN de-sensationalize algo for submission titles needs tweaking. Original title is simply "Huge Binaries".