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

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

#51

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

thayne wrote: post #46

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

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.

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

I already don't run into such cases though? Do you run into cases where changing an overflow to wrap-around (e.g. maybe via unsigned?) makes it suddenly your code work on 2 machines, whereas leaving it as overflow makes it work on 1 machine but not the other?

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

#52

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

ridiculous_fish wrote: post #39

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

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.

Yup, I included set-top into embedded, too.

Also just to be clear I don't say that rust isn't for embedding, just currently development is focused around server (and kinda desktop) usage with some focus on some of the most wide spread embedding targets.

I hope in the future rust will be the go-to alternative for C/C++ in any use-case (at least any which llvm supports). But we are not there yet. But we are slowly getting there step by step.

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

#53

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

thayne wrote: post #49

Reelin wrote: post #34

Earlier quoted context omitted.

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

Bounds checks are absolutely done in release builds. The optimizer is more likely to be able to remove ones that are irrelevant, but the checks are not turned off.

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

#54

Post by cryptonector » Sun, May 10, 2020, 9:47 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++?

Compiler flags are not part of the language, so not portable.

Using a different data type? You'd have to use arbitrary precision numeric data types to avoid this. After all, you can still overflow 64-bit ints.

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

#55

Post by [deleted] » Sun, May 10, 2020, 9:49 PM UTC

ridiculous_fish wrote: post #48

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.

[deleted]

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

#56

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

ridiculous_fish wrote: post #48

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.

Do you mean thar rax is caller-saved?

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

#57

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

steveklabnik wrote: post #50

mehrdadn wrote: post #47

Earlier quoted context omitted.

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.

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

What do you mean? Is Rust's -C overflow-checks just a joke then? https://doc.rust-lang.org/reference/expressions/operator-exp...

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

#58

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

mehrdadn wrote: post #51

thayne wrote: post #46

Earlier quoted context omitted.

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.

> 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. I already don't run into such cases though? Do you run into cases where changing an overflow to wrap-around (e.g. maybe via unsigned?) makes it suddenly your code work on 2 machines, whereas leaving it as overflow makes it work on 1 machine but not the other?

That was the example given in the original article

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

#59

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

mrits wrote: post #14

jefft255 wrote: post #12

Earlier quoted context omitted.

How much active development of new software is being done for MS-DOS? Really curious to know.

I'd hope that he was just joking with that list

I’m sure there’s some POS systems that are maintained on MS DOS.

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

#60

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

thayne wrote: post #58

mehrdadn wrote: post #51

Earlier quoted context omitted.

> 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. I already don't run into such cases though? Do you run into cases where changing an overflow to wrap-around (e.g. maybe via unsigned?) makes it suddenly your code work on 2 machines, whereas leaving it as overflow makes it work on 1 machine but not the other?

That was the example given in the original article

Yes, but I was asking about your experience.