6 ms·

It seems to me a flaw in a language and in a compiler if the average programmer has to avoid higher levels of optimizating because it cannot be predicted what t

• Wowfunhappy 5y ago
  What if the only languages/compilers without that "flaw" had similar performance to lower optimization levels? (I don't know if that's the case, but it's what I thought the GP was implying.)
  • phicoh 5y ago
    There is a saying that you can make any program run fast if you don't care about correctness. We have reached the point where C programmers cannot understand the language/compiler anymore. Given that this has been going on for a long time, my hope is that Rust will be the next systems programming language.
    • foxfluff 5y ago
      Do you think people understand Rust?
      • phicoh 5y ago
        Rust can be hard to write, but by and large is not hard to read. Rust does have more abstraction mechanisms than C. So it is possible to go overboard in that area. But that is more a coding style issue. C programs that nest multiple levels of functions pointers can also be hard to understand.
      • pornel 5y ago
        The safe subset of Rust does not permit any UB. This greatly simplifies understanding of UB in the majority of the codebase — because there isn't any. Only when there's an `unsafe` keyword in Rust, you put your "C" hat on. (it was and continues to be a challenge to uphold this guarantee, because UB in LLVM is so ubiquitous, e.g. Rust had to patch up float to int conversions and eliminate no-op loops)
      • duped 5y ago
        It's easier to understand production Rust than production C
    • cma 5y ago
      Rust code in unsafe blocks has lots of similar issues with fuzziness around aliasing rules: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/active_discussion/aliasing.md https://github.com/rust-lang/unsafe-code-guidelines/blob/mas...
• couchand 5y ago
  It doesn't seem like anyone is taking the position here that C is flawless. Rather, the question is, given both its flaws and its ubitquity, is it acceptable to trade off developer head-wall interactions for the possibility of high performance. The only winning move is not to play. (with C)
• foxfluff 5y ago
  I don't see it that way. Isn't that precisely the point of higher levels? Don't go there if you don't know what you're doing. Since we can't magically install knowledge into average programmer's heads, the only other choice would be to have those higher levels not exist because the average programmer will never understand them, and also the compiler can't mind-read the average programmer to understand that what they want isn't exactly what they said they want.
  • fennecfoxen 5y ago
    I think the general problem is that if so much is going to hinge on this, it should be much easier to tell whether or not you know what you're doing. Undefined behavior really wouldn't be a problem if you could spot it reliably (possibly using tools, like the compiler toolchain itself). This loose mapping between four optimization levels and a variety of obscure language situations is invisible and situated only in a handful of top engineers' memories. That's not a great way to run a language if you actually care about the correctness of programs written in that language.
  • immibis 5y ago
    I always thought the main point of the levels was simply compilation speed. That and debuggability.
    • gpderetta 5y ago
      For the most part yes. O3 also enables (or used to) some optimizations that are not always profitable.
  • wongarsu 5y ago
    > Isn't that precisely the point of higher levels? I used to think that higher levels are for giving the compiler more time to think so it can come up with a better result (and for somewhat specifying the desired space-performance tradeoff). In my mind the "don't do it if you don't know what you are doing"-things were seperate flags, like -ffast-math. Obviously I eventually learned that bad things can happen, but "just build prod with -O2" still seems to be what almost everyone does.