5 ms·

I would be really interested if you can shed a little light on the following related questions: 1. Do you see the bloat even if you don't use post C++11 featur

I would be really interested if you can shed a little light on the following related questions: 1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard? 2. Do you think it is mostly the compiler that is causing the bloat alone? Or is it stuff from the standard library header files that some how gets linked in (and are not used or needed by your software)?

bluGill 8y ago
I haven't tried c++17 year, but c++98->c++11 did bring about code bloat. However even though we were building the same code base for two different systems, one without a C++11 compiler (thus we could not use c++11 features): it is incorrect to say we were not using C++11. Just turning on C++11 in the compiler brings move to all standard library containers. The header files were not just "somehow" linked in and not used, the additional code was used in many places behind the scene. I haven't done benchmarks on my code, but the general report of those who have is that in exchange for the extra binary size the code runtime was 5% faster. For most people these days that expense is worth it.
- thekingofh 8y ago
  What do you mean by code bloat?
  - bluGill 8y ago
    Binary size after compiled. Also time to build - just turning on C++11 more than doubles the time to run the processor. (I hope C++20 modules fixes this)
cominous 8y ago
1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard? Yes, actually I tried using various C++ snippets and even reported that to the GCC compiler team. It happens with simple stuff like std::string and std::vector. The response was something like, that there really seems to be a bloat, but no performance impact and I guess most users outside of embedded don't care too much about the size of the compiled binary. 2. Do you think it is mostly the compiler that is causing the bloat alone? Or is it stuff from the standard library header files that some how gets linked in (and are not used or needed by your software)? That's actually a very good question I cant give an answer to - meaning I haven't looked specifically into that. As C++17 came to GCC I played with the compiler explorer and observed this by just switching gcc/clang version and -std flag. Actually, you can try it yourself: https://godbolt.org/ https://godbolt.org/
- jchb 8y ago
  Did you try with optimisations enabled? Here is a (trivial) program comparing gcc output between -std=c++14 and -std=c++17: https://godbolt.org/g/VLDhYf https://godbolt.org/g/VLDhYf. Note that the output code size with -std=c++17 is significantly larger without optimisations (default), but it is identical with optimisations turned on!
  - cominous 8y ago
    I used -Os as for any embedded code where I don't care too much about the performance and rather need a compact binary. I would love to post my code snippets from back then, but Im not home currently and the time Im back home I guess nobody will care about this anymore :D. Maybe I put it into an article.
    - gpderetta 8y ago
      If I had to guess, -Os prevents most inlining and in inlining is is pretty much required to remove most of the pure compile time abstraction and indirection that is used even on most trivial C++ libraries. Very likely libstdc++ make significant use of that. The intermediate inline stages greatly expand the code size, until the point level where all the abstraction can be compiled away. I guess that -Os simply settles for a local optimum and gives up inlining early.
    - alexeiz 8y ago
      -Os is pretty much useless. For comparison, I compiled my (reasonably sized) project with -Os and got a 12MB statically linked binary. But with -O3, the binary size is only 4.2MB. Not only -O3 produces faster code but it's also smaller.
      - msla 8y ago
        In modern systems with caches and a typical penalty for going out to RAM, is it still possible for larger code to be faster?

bluGill 8y ago

I haven't tried c++17 year, but c++98->c++11 did bring about code bloat. However even though we were building the same code base for two different systems, one without a C++11 compiler (thus we could not use c++11 features): it is incorrect to say we were not using C++11. Just turning on C++11 in the compiler brings move to all standard library containers. The header files were not just "somehow" linked in and not used, the additional code was used in many places behind the scene. I haven't done benchmarks on my code, but the general report of those who have is that in exchange for the extra binary size the code runtime was 5% faster. For most people these days that expense is worth it.

thekingofh 8y ago
What do you mean by code bloat?
- bluGill 8y ago
  Binary size after compiled. Also time to build - just turning on C++11 more than doubles the time to run the processor. (I hope C++20 modules fixes this)

cominous 8y ago

1. Do you see the bloat even if you don't use post C++11 features but compile using the C++17 standard? Yes, actually I tried using various C++ snippets and even reported that to the GCC compiler team. It happens with simple stuff like std::string and std::vector. The response was something like, that there really seems to be a bloat, but no performance impact and I guess most users outside of embedded don't care too much about the size of the compiled binary. 2. Do you think it is mostly the compiler that is causing the bloat alone? Or is it stuff from the standard library header files that some how gets linked in (and are not used or needed by your software)? That's actually a very good question I cant give an answer to - meaning I haven't looked specifically into that. As C++17 came to GCC I played with the compiler explorer and observed this by just switching gcc/clang version and -std flag. Actually, you can try it yourself: https://godbolt.org/ https://godbolt.org/

jchb 8y ago
Did you try with optimisations enabled? Here is a (trivial) program comparing gcc output between -std=c++14 and -std=c++17: https://godbolt.org/g/VLDhYf https://godbolt.org/g/VLDhYf. Note that the output code size with -std=c++17 is significantly larger without optimisations (default), but it is identical with optimisations turned on!
- cominous 8y ago
  I used -Os as for any embedded code where I don't care too much about the performance and rather need a compact binary. I would love to post my code snippets from back then, but Im not home currently and the time Im back home I guess nobody will care about this anymore :D. Maybe I put it into an article.
  - gpderetta 8y ago
    If I had to guess, -Os prevents most inlining and in inlining is is pretty much required to remove most of the pure compile time abstraction and indirection that is used even on most trivial C++ libraries. Very likely libstdc++ make significant use of that. The intermediate inline stages greatly expand the code size, until the point level where all the abstraction can be compiled away. I guess that -Os simply settles for a local optimum and gives up inlining early.
  - alexeiz 8y ago
    -Os is pretty much useless. For comparison, I compiled my (reasonably sized) project with -Os and got a 12MB statically linked binary. But with -O3, the binary size is only 4.2MB. Not only -O3 produces faster code but it's also smaller.
    - msla 8y ago
      In modern systems with caches and a typical penalty for going out to RAM, is it still possible for larger code to be faster?