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

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

#31

Post by oconnor663 » Sun, May 10, 2020, 8:50 PM UTC

mehrdadn wrote: post #29

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…

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

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

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

#32

Post by ridiculous_fish » Sun, May 10, 2020, 8:54 PM UTC

Here's a case I stumble on: Rust seems to generate unnecessary branches. Compare copying an optional range:

C++: https://godbolt.org/z/VCf638

Rust: https://rust.godbolt.org/z/jRFiw_

I think the key difference here is that C++ allows specializing optional on trivial types - can anyone shed more light?

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

#33

Post by mehrdadn » Sun, May 10, 2020, 8:55 PM UTC

oconnor663 wrote: post #31

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?

> 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 what happens in that case regardless except in like 0.01% of the time when they're writing some kind of bit manipulation magic, and in those rare cases they can handle them in C++ too, with a custom wrapper or an unsigned type or something.

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

#34

Post by Reelin » Sun, May 10, 2020, 8:56 PM UTC

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, I guess you could do many of the same things in unsafe blocks and they could cause problems just as easily. If they end up breaking things no one will blame the language because the tin was clearly labeled.

I do prefer language designs that make it possible to write things that are safe by default. It just seems like many problems are misattributed to undefined behavior but are actually due to systemic issues in the design of the language.

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

#35

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

saagarjha wrote: post #30

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?

I mean, if you're doing two's complement arithmetic as the example relies on then it's certainly useful. If you want any other behavior, then it is not. (Rust's differing behavior between different optimization levels IMO makes it basically impossible to use usefully, FWIW.)

How likely is that "if", though? How often when you see signed multiplication in code do you find people are actually paying attention to the negative results and planning around 2's complement behavior? I know there are occasions in which people do this, but it's so incredibly rare compared to when they multiply two numbers. And on the rare occasions when the bit patterns actually matter to them and they're paying attention, it's not like they have no way to solve the problem in C++.

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

#36

Post by pitaj » Sun, May 10, 2020, 9:05 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…

It may just be for alignment. A push may be just (having a specific case in the CPU) as fast as updating the SP.

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

#37

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

mehrdadn wrote: post #29

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…

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

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

#38

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

kibwen wrote: post #3

This is an endlessly perplexing headline, as its core assertion, "C++ is faster and safer than Rust", is what the body of the article spends its whole time attempting to refute. A more accurate title for the content of this article would be "Debunking the myths that Rust is not safer or as fast as C++".

Clickbait for software engineers.

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

#39

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

dathinab wrote: post #16

aninteger wrote: post #4

This article is a bit click-baity. It's more about busting myths by a particular C++ programmer against rust. Anyway for a truth (well maybe it is a myth?) that we can't bust yet... Rust is simply not available on all platforms that C++ is. Two platforms that I think are missing: * 16-bit MS-DOS * 32-bit PowerPC (Linux)

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

Depends what you mean by "embedded," but almost every set-top box and TV has a 32 bit ARM SOC. These run software under active development: web browsers, Netflix, etc.

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

#40

Post by dang » Sun, May 10, 2020, 9:14 PM UTC

kibwen wrote: post #3

This is an endlessly perplexing headline, as its core assertion, "C++ is faster and safer than Rust", is what the body of the article spends its whole time attempting to refute. A more accurate title for the content of this article would be "Debunking the myths that Rust is not safer or as fast as C++".

Ok, we've debunked the title above.