Hacker News Reader

Comment by phicoh | Hacker News Reader

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 they do.

View on HN

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.)

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.

Do you think people understand Rust?

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)

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.

It's easier to understand production Rust than production C

Rust code in unsafe blocks has lots of similar issues with fuzziness around aliasing rules:

https://github.com/rust-lang/unsafe-code-guidelines/blob/mas...

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)

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.

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.

I always thought the main point of the levels was simply compilation speed. That and debuggability.

For the most part yes. O3 also enables (or used to) some optimizations that are not always profitable.

> 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.

-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.

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).

Reply on news.ycombinator.com