4 ms·

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 instal

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.
- astrange 5y ago
  -O3 mostly is “try harder” but in practice it is more about using more experimental/dangerous techniques than thinking harder. That’s because, basically, compiler optimizations aren’t as important as people think and there aren’t amazing insights you can come to by thinking harder. If there were, it’d be better for the compiler to tell the programmer about them rather than rediscover them every compilation.
mpweiher 5y ago
Nope. That optimisations must not change the visible behavior (except for running time) of a program was the cardinal rule of optimisation. Then it got flushed down the toilet. (With the trick of retroactively redefining the behavior to be undefined in the first place and thus all bets being off).

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.

astrange 5y ago
-O3 mostly is “try harder” but in practice it is more about using more experimental/dangerous techniques than thinking harder. That’s because, basically, compiler optimizations aren’t as important as people think and there aren’t amazing insights you can come to by thinking harder. If there were, it’d be better for the compiler to tell the programmer about them rather than rediscover them every compilation.

mpweiher 5y ago

Nope. That optimisations must not change the visible behavior (except for running time) of a program was the cardinal rule of optimisation. Then it got flushed down the toilet. (With the trick of retroactively redefining the behavior to be undefined in the first place and thus all bets being off).