Hacker News Reader

Comment by pcwalton | Hacker News Reader

> C needs to cut down on the instances of undefined behavior

As someone who's worked on compilers a good bit, I disagree (and this is my favorite meme to argue against lately). You need that undefined behavior for performance.

> For instance, if you overflow an integer, the compiler should not be allowed to assume that code branch is unreachable, or to conjure nasal demons.

You need to be careful to not destroy loop trip count detection.

> Instead the result should be an implementation-defined integer

Not good enough. Loop trip count detection destroyed.

> jump to an implementation-defined exception handling routine.

Unacceptable for performance. Probably a 3x loss.

View on HN

I think that the reason people want this stuff is that they don't understand how much effort it takes to prove that underlying UB is not triggered in a branch and optimize out checks. Code size would explode, too; decimating the usefulness of embedded platforms, and eviscerating instruction caches. In that way, it would also be an ecological disaster.

I'm curious to learn more about your position -- have you written it down in more detail elsewhere? Rust doesn't have this kind of undefined behavior AFAIK? Are you arguing that C and C++ should have it, but Rust doesn't need to even though it's competing perf-wise with C and C++ in this space?

https://doc.rust-lang.org/reference.html#behavior-not-consid...

>• Integer overflow

> ◦ Overflow is considered "unexpected" behavior and is always user-error, unless the wrapping primitives are used. In non-optimized builds, the compiler will insert debug checks that panic on overflow, but in optimized builds overflow instead results in wrapped values. See RFC 560 for the rationale and more details.

(also important to note that when they say "RFC 560", they are referring to Rust RFCs and not IETF RFCs)

> Are you arguing that C and C++ should have it, but Rust doesn't need to even though it's competing perf-wise with C and C++ in this space?

Yes. Other languages like Swift generally don't need it either.

The big wins from exploiting undefined behavior in C come from mistakes that C's designers made in 1978: signed int being the easiest thing to use for loops over array indices, the any-pointer-can-alias-anything-else style, the uselessness of const for optimization, and null pointers. Rust (and e.g. Swift, for the most part) made none of these choices, and so they can reap the benefits of aggressive compiler optimizations without the undefined behavior.

(Digression: I can't blame C's designers for these mistakes, of course: it was 1978! But I think that in 2016 we should just accept that there were things we didn't do right in 1978, because we didn't know as much then as we do now. In most other engineering industries the idea that we made mistakes 35 years ago and that modern designs are better is uncontroversial, but for some reason in computing we have rose-colored glasses for the early days of Unix. Everyone wants to blame the compiler authors because they don't want to admit C has flaws!)

These issues don't necessarily apply to other languages. I believe that if you design a language optimally you don't need to fall back on undefined behavior to get good performance. But I don't believe C is that language, and I think attempts to dial back undefined behavior without changing C are missing the point.

Wow, if what you say is true, that's even more of a benefit for a language like Rust. Memory safety is awesome, but keeping the same performance while removing undefined behavior is huge.

Another question: how do "unsafe Rust" (ie. Rust inside unsafe blocks) and C compare in this sense? If satisfying the borrow checker for some bit of code is too hard, is writing in unsafe Rust better/safer than C?

Currently, the aliasing rules for unsafe code are "any pointers can alias"—i.e. no type based alias analysis (TBAA), a.k.a. strict-aliasing. (This is because LLVM has no concept of TBAA at the IR level; it's something the frontend supplies explicitly.) There is an open question as to how much this will affect our ability to perform alias-based optimizations, given that a lot of our primitives are implemented with unsafe code under the hood. I'm optimistic that it can be solved (although some others on the team, like Niko, are less optimistic).

Meanwhile, Java runs pretty fast.

Java doesn't suffer from these a bunch of these limitations, though, especially around aliasing. That makes a big difference. (Though signed indexing is still an issue in Java, unfortunately…)

Reply on news.ycombinator.com