7 ms·

I don't get why people get so upset about C++ optimizations. They are by nature optional. If you think an optimization is dangerous, just disable it. That's why

I don't get why people get so upset about C++ optimizations. They are by nature optional. If you think an optimization is dangerous, just disable it. That's why compilers have optimization levels, so you can select what you're comfortable with.

keldaris 8y ago
Exactly. It's become fashionable to decry the lengths to which C/C++ compilers are able to go in the pursuit of performance because of "safety" issues, but the advantage of letting the programmer fully control every knob in the chain is immense.
- pjmlp 8y ago
  With great power comes great responsibility. I might not code daily in C++ anymore, but it would be nice that the software I rely on, specially in devices I am not able to upgrade, wouldn't suffer from such issues. Butcher knifes are deadly sharp, yet those conscious ones do use proper gloves when handling them.
- dpc_pw 8y ago
  C++ is not "letting the programmer fully control every knob". Quite the opposite. Buggy, insecure, broken software is usually not the intention. The developer wanted one thing, and got something else, because of arcane details of the language. C++ is just a bad programming language, and "but it's powerful" is not invalidating that fact.
  - keldaris 8y ago
    I certainly wouldn't call C++ a good programming language (rather, I would call it the only viable option for most of its usecases, badly designed though it is). However, I will stick by the "letting the programmer fully control every knob" phrase I used. I never claimed it makes it easy and you can make a lot of good arguments regarding better defaults, but it absolutely eschews restricting programmer freedom, at a not inconsiderable price.
    - pjmlp 8y ago
      Ada and Modula-3 are two examples of languages that also let the programmers control every knob, when needed, without exposing the traditional unsafety issues that C++ has inherited from C. But alas, one was too expensive to become mainstream and the other died when Compaq acquired DEC.
      - keldaris 8y ago
        I don't know enough about optimizing Ada code to comment competently on your assertion, but part of the reason it's very hard to compete with C/C++ is simply because of the immense effort that's gone into improving the compilers. These days the only languages that are remotely comparable to C/C++ in terms of performance directly benefit from that effort - they either use the LLVM (Rust, Julia, the LDC compiler for D, etc.) or transpile to C (like Nim). The only real differentiation comes from the semantics they expose and any additional machinery they offer on top of that stack (like the Julia JIT).
        pjmlp 8y ago
        In terms of language features they are safe by default, but do provide enough escape hatch to make it as unsafe as C and C++. The big difference is that you as developer will notice that you are doing something that might eventually blow up, because it is very explicit. For example something like doing a reinterpret_cast would be LOOPHOLE call in Modula-3 and is only allowed inside an UNSAFE MODULE implementation. As for the rest, yes C and C++ have enjoyed 30 years of compiler research, but as Fran Allen puts it, C has brought compiler optimization research back to the pre-history. If you read IBM's research papers on PL.8, the systems programming language used on the RISC project, it already had an architecture similar to what LLVM has. Where the multiple compiler phases were taking care of the optimizations. Then when they decided to go commercial, they rather adopted UNIX as platform. So maybe we would be somewhere else had AT&T been allowed to sell UNIX at the same price as VMS, z/OS and others. As for the LLVM, we aren't going to throw that code away, but as you also assert, it is possible to use safer languages while taking advantage of the optimization work that went into LLVM. That is how I see C and C++'s future, down into a thin infrastructure layer, with userspace mostly written in something else.
  - coliveira 8y ago
    The reason C++ is badly designed is exactly to let programmers control how it operates. I don't subscribe to the philosophy, but I understand it. Trying to denigrate the language because of these choices is, in my view, absurd.
    - WalterBright 8y ago
      > The reason C++ is badly designed is exactly to let programmers control how it operates. The reason is backwards compatibility. C++ has a long history, and mistakes were made in the past including mistakes carried over from C: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html and C++ tries to fold improvements in without breaking compatibility.
- vvanders 8y ago
  > but the advantage of letting the programmer fully control every knob in the chain is immense. That's actually not completely true. Take the restrict keyword for instance. Super painful to use in C/C++ and very dangerous. In Rust since the language has constrains around single mutable pointers they can turn it on globally and you get it "for free". If I recall correctly it's going live in one of the upcoming stable releases. Sometimes constraints can actually let you get better performance than a wild-west of pointers everywhere.
  - shepmaster 8y ago
    > going live in one of the upcoming stable releases If I remember correctly, it was originally enabled but had to be disabled because LLVM had some bugs around how it was handled. These arose because `restrict` is comparatively rarely used in C / C++ code. https://github.com/rust-lang/rust/issues/31681 https://github.com/rust-lang/rust/issues/31681
    - steveklabnik 8y ago
      Turning it back on landed in master a little over a month ago; meaning it will be in Rust 1.28, the next release.
  - keldaris 8y ago
    Of all the sharp tools in C, restrict is one of the last things I'd call dangerous (restrict is not a standard keyword in C++, by the way, although most compilers support it as an extension). It's completely opt-in, relatively rarely used, and to even think of using it you have to be already thinking about aliasing issues. If you write a function using restrict and suddenly completely change your intent mid way, I really don't think that's a language design issue. Of course it's still a sharp tool and explicitly meant as such - as a last resort for cases where you can't rely on the compiler to infer the right thing on its own.
    - vvanders 8y ago
      Sure but my point wasn't about the ergonomics of restrict, more that having a wild-west of pointers means that some performance optimizations are now off the table vs languages that are a bit more constrained in how they approach data access patterns.
petermcneeley 8y ago
The presentation in question answers this quite clearly. The changes in code produced by optimization can produce subtle changes in behavior. Having debugged opt only production issues (C++) I am well aware that you cannot simply "select what you're comfortable with".
vvanders 8y ago
When it takes me a week to track down what optimization caused that's when I take issue with it. Having had to chase down stray aliased pointers in something marked restrict I can tell you it's not trivial to root-cause.
- geezerjay 8y ago
  > in something marked restrict In C++ there is no restrict keyword. So either you're using and abusing compiler-specific behavior that you decided to do so without any test at all or you're confusing programming languages. Either way, you're trying to pin the blame on C++ for something that has nothing to do with C++.
  - hellofunk 8y ago
    Most or all C++ compilers support the restrict keyword, therefore it can be used in the C++ language, even if it is not officially in the standard.
  - SlowRobotAhead 8y ago
    I think you went a little too fast to not realize "restrict" is a keyword in C99.
slavik81 8y ago
The code emitted at -O0 on GCC is practically pessimized. It looks nothing like what a human being would write.
- saagarjha 8y ago
  GCC a couple dozen optimizations even at -O0.
justicezyx 8y ago
You know, people is very impressed with my c++ code during interview, because learning and using language is itself an achievement. That speaks of the complexity of C++. When you say: "you can select what you're comfortable with", I am guessing that you are not using c++ in production environment. That is not a questioning, but to point out that if that's true, you generally have no experience to support such claims.
- coliveira 8y ago
  You guessed wrong. I have supported large C++ codebases and while C++ is not an easy language, it gives you the tools to do what you want in millions of different situations. This diversity seems to be bad until you really need something that the language provides. That's why C++ is, and will continue to be, used in so many environments.
gok 8y ago
Regardless of optimization level, the effects of undefined behavior are not optional. Adjusting the optimization level of the compiler does not adjust the semantics of the language as far as the compiler is worried. If you're worried about an optimization changing the functionality of your program, you really should be adjusting the feature/dialect settings (for clang/GCC this means the -f flags, not the -O flags)
WalterBright 8y ago
In my older compilers, I had a cornucopia of optimization levers for the various optimizations. I discovered that the number of people who understood how to use those levers, let alone were interested in them, or cared, was zero. Including myself. People just want to "optimize" the code. (Also, different optimizations can have surprising effects when combined that isn't clear at all from the individual levers.)
ur-whale 8y ago
>you can select what you're comfortable with On a large codebase this is very hard to do, and introduces an additional layer of complexity for very little reward.
oconnor663 8y ago
One downside to disabling optimizations is that it confuses the meaning of "valid C++". If your code is only correct with optimizations X, Y, and Z disabled, is it "valid C++"? Or is it "invalid C++, but valid C++-noX-noY-noZ"? Do the definitions of X, Y, and Z necessarily tie your project to a specific compiler?
- keldaris 8y ago
  That's not a hard question. If your code only works without certain optimizations, it's either not valid (as in, standards-compliant) C++ or you've found a compiler bug. That doesn't necessarily make it bad - you may have a good reason to write non-portable code for a specific platform and a specific compiler, but it's not conformant to the language standard.
- jolmg 8y ago
  The compiler does not necesarily dictate what is valid c++. If code doesn't work with optimizations enabled, it could either be a bug in the code where its expectations coincided with the compiler's behaviour on something that is undefined in the language when optimizations were turned off or it could be a bug in the compiler where it applied the optimizations incorrectly. There is no "invalid C++, but valid C++-noX-noY-noZ". It's one or the other. The former is a bug in the code; the latter is a bug in the compiler.

keldaris 8y ago

Exactly. It's become fashionable to decry the lengths to which C/C++ compilers are able to go in the pursuit of performance because of "safety" issues, but the advantage of letting the programmer fully control every knob in the chain is immense.

pjmlp 8y ago
With great power comes great responsibility. I might not code daily in C++ anymore, but it would be nice that the software I rely on, specially in devices I am not able to upgrade, wouldn't suffer from such issues. Butcher knifes are deadly sharp, yet those conscious ones do use proper gloves when handling them.
dpc_pw 8y ago
C++ is not "letting the programmer fully control every knob". Quite the opposite. Buggy, insecure, broken software is usually not the intention. The developer wanted one thing, and got something else, because of arcane details of the language. C++ is just a bad programming language, and "but it's powerful" is not invalidating that fact.
- keldaris 8y ago
  I certainly wouldn't call C++ a good programming language (rather, I would call it the only viable option for most of its usecases, badly designed though it is). However, I will stick by the "letting the programmer fully control every knob" phrase I used. I never claimed it makes it easy and you can make a lot of good arguments regarding better defaults, but it absolutely eschews restricting programmer freedom, at a not inconsiderable price.
  - pjmlp 8y ago
    Ada and Modula-3 are two examples of languages that also let the programmers control every knob, when needed, without exposing the traditional unsafety issues that C++ has inherited from C. But alas, one was too expensive to become mainstream and the other died when Compaq acquired DEC.
    - keldaris 8y ago
      I don't know enough about optimizing Ada code to comment competently on your assertion, but part of the reason it's very hard to compete with C/C++ is simply because of the immense effort that's gone into improving the compilers. These days the only languages that are remotely comparable to C/C++ in terms of performance directly benefit from that effort - they either use the LLVM (Rust, Julia, the LDC compiler for D, etc.) or transpile to C (like Nim). The only real differentiation comes from the semantics they expose and any additional machinery they offer on top of that stack (like the Julia JIT).
      - pjmlp 8y ago
        In terms of language features they are safe by default, but do provide enough escape hatch to make it as unsafe as C and C++. The big difference is that you as developer will notice that you are doing something that might eventually blow up, because it is very explicit. For example something like doing a reinterpret_cast would be LOOPHOLE call in Modula-3 and is only allowed inside an UNSAFE MODULE implementation. As for the rest, yes C and C++ have enjoyed 30 years of compiler research, but as Fran Allen puts it, C has brought compiler optimization research back to the pre-history. If you read IBM's research papers on PL.8, the systems programming language used on the RISC project, it already had an architecture similar to what LLVM has. Where the multiple compiler phases were taking care of the optimizations. Then when they decided to go commercial, they rather adopted UNIX as platform. So maybe we would be somewhere else had AT&T been allowed to sell UNIX at the same price as VMS, z/OS and others. As for the LLVM, we aren't going to throw that code away, but as you also assert, it is possible to use safer languages while taking advantage of the optimization work that went into LLVM. That is how I see C and C++'s future, down into a thin infrastructure layer, with userspace mostly written in something else.
- coliveira 8y ago
  The reason C++ is badly designed is exactly to let programmers control how it operates. I don't subscribe to the philosophy, but I understand it. Trying to denigrate the language because of these choices is, in my view, absurd.
  - WalterBright 8y ago
    > The reason C++ is badly designed is exactly to let programmers control how it operates. The reason is backwards compatibility. C++ has a long history, and mistakes were made in the past including mistakes carried over from C: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html and C++ tries to fold improvements in without breaking compatibility.
vvanders 8y ago
> but the advantage of letting the programmer fully control every knob in the chain is immense. That's actually not completely true. Take the restrict keyword for instance. Super painful to use in C/C++ and very dangerous. In Rust since the language has constrains around single mutable pointers they can turn it on globally and you get it "for free". If I recall correctly it's going live in one of the upcoming stable releases. Sometimes constraints can actually let you get better performance than a wild-west of pointers everywhere.
- shepmaster 8y ago
  > going live in one of the upcoming stable releases If I remember correctly, it was originally enabled but had to be disabled because LLVM had some bugs around how it was handled. These arose because `restrict` is comparatively rarely used in C / C++ code. https://github.com/rust-lang/rust/issues/31681 https://github.com/rust-lang/rust/issues/31681
  - steveklabnik 8y ago
    Turning it back on landed in master a little over a month ago; meaning it will be in Rust 1.28, the next release.
- keldaris 8y ago
  Of all the sharp tools in C, restrict is one of the last things I'd call dangerous (restrict is not a standard keyword in C++, by the way, although most compilers support it as an extension). It's completely opt-in, relatively rarely used, and to even think of using it you have to be already thinking about aliasing issues. If you write a function using restrict and suddenly completely change your intent mid way, I really don't think that's a language design issue. Of course it's still a sharp tool and explicitly meant as such - as a last resort for cases where you can't rely on the compiler to infer the right thing on its own.
  - vvanders 8y ago
    Sure but my point wasn't about the ergonomics of restrict, more that having a wild-west of pointers means that some performance optimizations are now off the table vs languages that are a bit more constrained in how they approach data access patterns.

petermcneeley 8y ago

The presentation in question answers this quite clearly. The changes in code produced by optimization can produce subtle changes in behavior. Having debugged opt only production issues (C++) I am well aware that you cannot simply "select what you're comfortable with".

vvanders 8y ago

When it takes me a week to track down what optimization caused that's when I take issue with it. Having had to chase down stray aliased pointers in something marked restrict I can tell you it's not trivial to root-cause.

geezerjay 8y ago
> in something marked restrict In C++ there is no restrict keyword. So either you're using and abusing compiler-specific behavior that you decided to do so without any test at all or you're confusing programming languages. Either way, you're trying to pin the blame on C++ for something that has nothing to do with C++.
- hellofunk 8y ago
  Most or all C++ compilers support the restrict keyword, therefore it can be used in the C++ language, even if it is not officially in the standard.
- SlowRobotAhead 8y ago
  I think you went a little too fast to not realize "restrict" is a keyword in C99.

slavik81 8y ago

The code emitted at -O0 on GCC is practically pessimized. It looks nothing like what a human being would write.

saagarjha 8y ago
GCC a couple dozen optimizations even at -O0.

justicezyx 8y ago

You know, people is very impressed with my c++ code during interview, because learning and using language is itself an achievement. That speaks of the complexity of C++. When you say: "you can select what you're comfortable with", I am guessing that you are not using c++ in production environment. That is not a questioning, but to point out that if that's true, you generally have no experience to support such claims.

coliveira 8y ago
You guessed wrong. I have supported large C++ codebases and while C++ is not an easy language, it gives you the tools to do what you want in millions of different situations. This diversity seems to be bad until you really need something that the language provides. That's why C++ is, and will continue to be, used in so many environments.

gok 8y ago

Regardless of optimization level, the effects of undefined behavior are not optional. Adjusting the optimization level of the compiler does not adjust the semantics of the language as far as the compiler is worried. If you're worried about an optimization changing the functionality of your program, you really should be adjusting the feature/dialect settings (for clang/GCC this means the -f flags, not the -O flags)

WalterBright 8y ago

In my older compilers, I had a cornucopia of optimization levers for the various optimizations. I discovered that the number of people who understood how to use those levers, let alone were interested in them, or cared, was zero. Including myself. People just want to "optimize" the code. (Also, different optimizations can have surprising effects when combined that isn't clear at all from the individual levers.)

ur-whale 8y ago

>you can select what you're comfortable with On a large codebase this is very hard to do, and introduces an additional layer of complexity for very little reward.

oconnor663 8y ago

One downside to disabling optimizations is that it confuses the meaning of "valid C++". If your code is only correct with optimizations X, Y, and Z disabled, is it "valid C++"? Or is it "invalid C++, but valid C++-noX-noY-noZ"? Do the definitions of X, Y, and Z necessarily tie your project to a specific compiler?

keldaris 8y ago
That's not a hard question. If your code only works without certain optimizations, it's either not valid (as in, standards-compliant) C++ or you've found a compiler bug. That doesn't necessarily make it bad - you may have a good reason to write non-portable code for a specific platform and a specific compiler, but it's not conformant to the language standard.
jolmg 8y ago
The compiler does not necesarily dictate what is valid c++. If code doesn't work with optimizations enabled, it could either be a bug in the code where its expectations coincided with the compiler's behaviour on something that is undefined in the language when optimizations were turned off or it could be a bug in the compiler where it applied the optimizations incorrectly. There is no "invalid C++, but valid C++-noX-noY-noZ". It's one or the other. The former is a bug in the code; the latter is a bug in the compiler.