Debunking that C++ is faster and safer than Rust • Hacker News Board

Re: Debunking that C++ is faster and safer than Rust

#41

Post by nicoburns » Sun, May 10, 2020, 9:16 PM UTC

mehrdadn wrote: post #33

oconnor663 wrote: post #31

Earlier quoted context omitted.

> what the practical benefit is in having it wrap around There's a pretty big practical difference between "getting an unexpected numerical result" and "letting an attacker steal my TLS keys and mine bitcoins on my machine."

How sure are you that that getting an unexpected numerical result isn't going to let an attacker take over your machine? In most code I see the behavior is just undefined and not paid attention to by the programmer, regardless of what the compiler is doing. A huge fraction of the time you'll just step out of the bounds of an array, just deterministically instead of nondeterministically. People don't pay attention to…

> A huge fraction of the time you'll just step out of the bounds of an array, just deterministically instead of nondeterministically.

Well arrays are bounds checked by default in Rust, so you can't do that one. You're more likely to hit a crash, which I think is decidedly better than the compiler deciding to optimise out or rewrite your function because it contained UB.

Re: Debunking that C++ is faster and safer than Rust

#42

Post by dataflow » Sun, May 10, 2020, 9:18 PM UTC

steveklabnik wrote: post #37

mehrdadn wrote: post #29

Earlier quoted context omitted.

> the example which benefits from the way that Rust chooses to define it I'm actually struggling to see what the practical benefit is in having it wrap around. The program is still producing garbage at that point, which you're not handling, so why not let the compiler just forget about that case just like you already did?

The practical benefit is not in the wrapping specifically. The difference is in it being UB vs not UB; that is, overflow is a "program error" not UB, and so the language defines how implementations must handle this error. You aren't supposed to rely on this semantic, as it's an error. If the checks get cheap enough, rustc will also check in release.

I mean, the post seemed to be arguing that the wrap-around is somehow beneficial, so I'm not sure you're saying the same thing. But if all you want is check + crash when that happens then can't you just use a compiler flag or a different data type or something else for that in C++?

Re: Debunking that C++ is faster and safer than Rust

#43

Post by dathinab » Sun, May 10, 2020, 9:27 PM UTC

monocasa wrote: post #28

dathinab wrote: post #16

Earlier quoted context omitted.

Is anyone besides embedded doing _any_ 32-bit dev outside of maintaining legacy code? I mean 64-bit PowerPc is by now around 17 Years old and even 15 years ago some of the most widespread users of PowerPc (Xbox) switched to using 64 bit PowerPc architecture...

Xbox 360 still ran in 32bit mode with the exception of the hypervisor. No use of 64bit pointers on a system with a max of 1GB of RAM other than just wasting cache space, and there's no real other benefit tacked on like you see in other 64-bit archs.

Thanks I didn't know this. I just looked up since when PowerPc 64-bit is a think.

Re: Debunking that C++ is faster and safer than Rust

#44

Post by mehrdadn » Sun, May 10, 2020, 9:28 PM UTC

nicoburns wrote: post #41

mehrdadn wrote: post #33

Earlier quoted context omitted.

How sure are you that that getting an unexpected numerical result isn't going to let an attacker take over your machine? In most code I see the behavior is just undefined and not paid attention to by the programmer, regardless of what the compiler is doing. A huge fraction of the time you'll just step out of the bounds of an array, just deterministically instead of nondeterministically. People don't pay attention to…

> A huge fraction of the time you'll just step out of the bounds of an array, just deterministically instead of nondeterministically. Well arrays are bounds checked by default in Rust, so you can't do that one. You're more likely to hit a crash, which I think is decidedly better than the compiler deciding to optimise out or rewrite your function because it contained UB.

> Well arrays are bounds checked by default in Rust, so you can't do that one.

But that's my entire point. If you're observing a benefit here, it's decidedly not due to the wrap-around, but due to other features (like bounds checking), and the argument should be that those features make Rust better than C++. It seems strange to give praise to the multiplication wrap-around instead.

Re: Debunking that C++ is faster and safer than Rust

#45

Post by steveklabnik » Sun, May 10, 2020, 9:33 PM UTC

dataflow wrote: post #42

steveklabnik wrote: post #37

Earlier quoted context omitted.

The practical benefit is not in the wrapping specifically. The difference is in it being UB vs not UB; that is, overflow is a "program error" not UB, and so the language defines how implementations must handle this error. You aren't supposed to rely on this semantic, as it's an error. If the checks get cheap enough, rustc will also check in release.

I mean, the post seemed to be arguing that the wrap-around is somehow beneficial, so I'm not sure you're saying the same thing. But if all you want is check + crash when that happens then can't you just use a compiler flag or a different data type or something else for that in C++?

I’m not saying that the wrapping behavior is beneficial. I’m saying that having it be not UB is beneficial.

Re: Debunking that C++ is faster and safer than Rust

#46

Post by thayne » Sun, May 10, 2020, 9:34 PM UTC

dataflow wrote: post #42

steveklabnik wrote: post #37

Earlier quoted context omitted.

The practical benefit is not in the wrapping specifically. The difference is in it being UB vs not UB; that is, overflow is a "program error" not UB, and so the language defines how implementations must handle this error. You aren't supposed to rely on this semantic, as it's an error. If the checks get cheap enough, rustc will also check in release.

I mean, the post seemed to be arguing that the wrap-around is somehow beneficial, so I'm not sure you're saying the same thing. But if all you want is check + crash when that happens then can't you just use a compiler flag or a different data type or something else for that in C++?

It is beneficial that the behavior is defined, and therefore consistent. So you don't run into cases where it works on your laptop, but not on your server. Also, in this particular case, overflowing is probably not terrible, since you are computing a hash code. The worst case is that the distribution may not be as even as you hoped.

Re: Debunking that C++ is faster and safer than Rust

#47

Post by mehrdadn » Sun, May 10, 2020, 9:36 PM UTC

steveklabnik wrote: post #45

dataflow wrote: post #42

Earlier quoted context omitted.

I mean, the post seemed to be arguing that the wrap-around is somehow beneficial, so I'm not sure you're saying the same thing. But if all you want is check + crash when that happens then can't you just use a compiler flag or a different data type or something else for that in C++?

I’m not saying that the wrapping behavior is beneficial. I’m saying that having it be not UB is beneficial.

But if all you want is check + crash when that happens then can't you just use a compiler flag or a different data type or something else for that in C++?

Re: Debunking that C++ is faster and safer than Rust

#48

Post by ridiculous_fish » Sun, May 10, 2020, 9:38 PM UTC

acqq wrote: post #27

Just looking from afar, I don't have time to analyze every other claim, but this one: > Both C++ and Rust have generated identical assembly listings; both have added push rbx for the sake of stack alignment. Q.E.D. seems to be completely wrong: a decent compiler is able to align the stack without "touching" it. For the variables inside of the function to be pushed to the aligned stack position, only different offsets…

You are correct, it has nothing to do with alignment. rbx is a callee-saved register, so the callee saves it.

Re: Debunking that C++ is faster and safer than Rust

#49

Post by thayne » Sun, May 10, 2020, 9:41 PM UTC

Reelin wrote: post #34

saagarjha wrote: post #19

> As you can see, the documented behavior and the absence of undefined behavior due to signed overflows do make life easier. Not having undefined behavior does make life easier, but having it be defined and then giving the example which benefits from the way that Rust chooses to define it is not really fair. > With less effort, Rust generates less assembly code. And you don't need to give any clues to the compiler by…

> Not having undefined behavior does make life easier I have mixed feelings about this. It seems like many examples of undefined behavior are things that don't make sense to do (ie ought to result in an error) which would often be undecidable at compile time. Runtime error checks would incur performance penalties so it's up to to programmer to include them. The borrow checker is an obvious advantage here. Beyond that…

> Runtime error checks would incur performance penalties

Which is why in rust, there are many runtime checks done in debug builds but not in release builds. (Including checking for wraparound and bounds checks).

The idea being that automated tests should catch the errors, assuming you wrote good tests.

Re: Debunking that C++ is faster and safer than Rust

#50

Post by steveklabnik » Sun, May 10, 2020, 9:41 PM UTC

mehrdadn wrote: post #47

steveklabnik wrote: post #45

Earlier quoted context omitted.

I’m not saying that the wrapping behavior is beneficial. I’m saying that having it be not UB is beneficial.

But if all you want is check + crash when that happens then can't you just use a compiler flag or a different data type or something else for that in C++?

Different type? Sure. Disadvantage is that it’s not pervasive. Compiler flag? Probably, I am not an expert on compiler flags that change language semantics; we don’t do that in Rust, but I know C and C++ compilers do.