4 ms·

I assume the 70MB binary statically links in all kinds of assets that blow up the file size, static arrays of pre-calculated data etc. There's no way it compile

by w0utert 13y ago

I assume the 70MB binary statically links in all kinds of assets that blow up the file size, static arrays of pre-calculated data etc. There's no way it compiles to 70MB of assembly. The code size would still be massively bigger than the CPU code cache, but the working set that actually matters for performance does not have to have any relation to the size of the total code itself, as long as time-critical sections are small and localized.

sharpneli 13y ago
Considering the massive size increase due to debug symbols I'd guess that a sizable part of the 70MB indeed is assembly, at least 20MB and probably even more. C++ templates, while being absolutely lovely to write and use, tend to do that. Every single different type you instantiate the template into produces a separate compiled copy of the whole template. Write a sorting function and use it for 5 types -> you get the same sort in assembler 5 times with differences that relate to the types they use, alongside with 5 massive symbol names (C++ template symbols tend to be really large).
- exDM69 13y ago
  > Write a sorting function and use it for 5 types -> you get the same sort in assembler 5 times with differences that relate to the types they use, alongside with 5 massive symbol names (C++ template symbols tend to be really large). To be fair, this is also why the performance of C++ std::sort beats C qsort hands down. Calling the comparator function with a function pointer is expensive compared to doing an integer comparison. Additionally, the boundary between translation units (ie. object files) inhibits a lot of optimization that could otherwise take place (and does in the C++ case, when the function calls are inlined). There are also techniques to avoid C++ template bloat, such as type erasure. Although this makes the template code only a thin shim that provides type safety.
- sanxiyn 13y ago
  If functions really are same in assembly (e.g. type sizes are same) LLVM's mergefunc pass actually can merge them, leaving only a single copy. http://llvm.org/docs/Passes.html http://llvm.org/docs/Passes.html

by w0utert 13y ago

sharpneli 13y ago

Considering the massive size increase due to debug symbols I'd guess that a sizable part of the 70MB indeed is assembly, at least 20MB and probably even more. C++ templates, while being absolutely lovely to write and use, tend to do that. Every single different type you instantiate the template into produces a separate compiled copy of the whole template. Write a sorting function and use it for 5 types -> you get the same sort in assembler 5 times with differences that relate to the types they use, alongside with 5 massive symbol names (C++ template symbols tend to be really large).

exDM69 13y ago
> Write a sorting function and use it for 5 types -> you get the same sort in assembler 5 times with differences that relate to the types they use, alongside with 5 massive symbol names (C++ template symbols tend to be really large). To be fair, this is also why the performance of C++ std::sort beats C qsort hands down. Calling the comparator function with a function pointer is expensive compared to doing an integer comparison. Additionally, the boundary between translation units (ie. object files) inhibits a lot of optimization that could otherwise take place (and does in the C++ case, when the function calls are inlined). There are also techniques to avoid C++ template bloat, such as type erasure. Although this makes the template code only a thin shim that provides type safety.
sanxiyn 13y ago
If functions really are same in assembly (e.g. type sizes are same) LLVM's mergefunc pass actually can merge them, leaving only a single copy. http://llvm.org/docs/Passes.html http://llvm.org/docs/Passes.html