Announcement

Collapse
No announcement yet.

GCC 11 Now Defaults To C++17 Dialect By Default

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • someone
    replied
    Originally posted by pal666 View Post
    old code will use newer standard library, which will use newer language features which usually speed up compiling
    That's not true. The newer standard library doesn't usually use newer language features, because it has to still be compatible with C++11 and C++14 too, e.g. GCC doesn't use explicit(bool) for tuple constructors, and it doesn't use if constexpr in C++17 even when that would be faster to compile than old fashioned tag dispatching with lots of overloads.

    Compiling as a new standard definitely CAN make compilation slower, and it DOES. C++11 added dozens of new constructors to containers and tuple, and that makes overload resolution noticably slower even if you don't use any of those new constructors. C++17 adds even more new things to headers, which takes longer to parse even if you don't use them.

    Leave a comment:


  • archibald
    replied
    Originally posted by carewolf View Post
    Nope.. Try it Play round here on godbolt.org, and try to get const and constexpr to produce different code with optimizing compilers
    I've had a play around and take your point. I find it hard to reason about code once the optimiser gets involved, since it gets to change so much that the original code ends up quite detached from what's executed.

    Originally posted by discordian View Post
    Everything can slow down compilation, but constexpr often does the opposite. Evaluation is usually alot faster than multiple optimization passes and heuristics.
    Yeah, "able to slow down compilation" is a fairly weak statement - I was trying to say that whilst it might be possible for it to slow it down (perhaps at lower optimisation levels though?) the benefits are concrete.
    Last edited by archibald; 30 June 2020, 09:47 AM.

    Leave a comment:


  • discordian
    replied
    Originally posted by archibald View Post

    I'm sorry to say but you're mistaken here - constexpr is a keyword that allows compile-time evaluation: https://en.cppreference.com/w/cpp/language/constexpr. It can indeed slow down compilation time, but it results in runtime speedups and compile-time checking of results, so the tradeoff is generally considered worth it.
    Everything can slow down compilation, but constexpr often does the opposite. Evaluation is usually alot faster than multiple optimization passes and heuristics. Compiletime evaluation reduces code to a number early.

    And c++14/17 greatly improved writing such code, with C11 you were limited and often had to resort to recursion. So easier, faster to evaluate and optimize code with higher standards

    Leave a comment:


  • carewolf
    replied
    Originally posted by archibald View Post

    I'm sorry to say but you're mistaken here - constexpr is a keyword that allows compile-time evaluation: https://en.cppreference.com/w/cpp/language/constexpr. It can indeed slow down compilation time, but it results in runtime speedups and compile-time checking of results, so the tradeoff is generally considered worth it.
    Nope.. Try it Play round here on godbolt.org, and try to get const and constexpr to produce different code with optimizing compilers

    Leave a comment:


  • carewolf
    replied
    Originally posted by Mangix View Post
    I was under the impression that constexpr enables compile time evaluation.
    No, it enforces compile time evaluation is possible (consteval enforces that it is also done) and allows the usage where compile time evaluation is required (in template arguments), but compilers have always tried to evaluate as much as possible at compile time, there just wasn't any cross-platform way to rely on it being done at compile time before constexpr. Compilers as much as 30 years ago already did extensive compile time evaluation of constants and expressions based on constants. Might be much older than that. Even modern C has keywords that relies on compile time evaluation (such as _Static_assert, see https://en.cppreference.com/w/c/language/_Static_assert)

    Leave a comment:


  • klapaucius
    replied
    Originally posted by Mangix View Post

    With higher standards, more and more stuff becomes constexpr, making compilation slower.

    Not the only reason but that's one of them.
    But I see no point in compiling, e.g. a C++11 project with the default standard (in this case C++17). You're likely to see warnings about deprecated stuff, or even failures due to removed constructs. Whether it is slower even with flag -std=c+11 is another story, although I can't imagine why. Maybe because the header files are exactly the same, after all, only with more guards discriminating between standards and dialects..?
    Last edited by klapaucius; 29 June 2020, 06:00 AM.

    Leave a comment:


  • archibald
    replied
    Originally posted by carewolf View Post

    That doesn't make anything slower. Constexpr is only a helper for the programmer to ensure they program in a way that can be const propagated, a compiler does const propagation in any case.

    The only difference C++17 makes is allow you to use those expressions in new places, but if you have code that compiled with C++14 you are not doing that. So you are just getting the const propagation that has always taken place.
    I'm sorry to say but you're mistaken here - constexpr is a keyword that allows compile-time evaluation: https://en.cppreference.com/w/cpp/language/constexpr. It can indeed slow down compilation time, but it results in runtime speedups and compile-time checking of results, so the tradeoff is generally considered worth it.
    Last edited by archibald; 29 June 2020, 03:25 AM.

    Leave a comment:


  • Mangix
    replied
    I was under the impression that constexpr enables compile time evaluation.

    Leave a comment:


  • carewolf
    replied
    Originally posted by Mangix View Post

    With higher standards, more and more stuff becomes constexpr, making compilation slower.

    Not the only reason but that's one of them.
    That doesn't make anything slower. Constexpr is only a helper for the programmer to ensure they program in a way that can be const propagated, a compiler does const propagation in any case.

    The only difference C++17 makes is allow you to use those expressions in new places, but if you have code that compiled with C++14 you are not doing that. So you are just getting the const propagation that has always taken place.
    Last edited by carewolf; 29 June 2020, 02:06 AM.

    Leave a comment:


  • Mangix
    replied
    Originally posted by carewolf View Post

    Why on earth would it take longer? It is not extra optimization passes, just some more stuff allowed. Stuff already parsed with lower standard limits so that the compiler can output helpful error messages.
    With higher standards, more and more stuff becomes constexpr, making compilation slower.

    Not the only reason but that's one of them.

    Leave a comment:

Working...
X