Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debunking that C++ is faster and safer than Rust

viva64.com

Post reply on HN
Print view View original

21–30 of 84 posts

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

#21

Post by saagarjha »

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

Embedded sounds like a great domain for Rust that it sadly often cannot really be used in.

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

#23

Post by dathinab »

mschuetz wrote: post #5
brenden2 wrote: post #2

Strictly speaking it's the compiler that generates faster code.

You'll never get faster code out of JS, though. Language design matters a lot.

Well, there are some close to native code speeds for some (very constrained) use-cases.

They way it's done is that if you use a certain stile of C the compiler will speculative do assumptions about the code allowing it to basically add all the C optimizations. Except that it always has to check if the assumptions are uphold and then fallback and that because it's a JIT it has much less time to optimize the code and do cross-code-section optimizations.

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

#25

Post by jacobush »

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

Rust is promoted all the time as the sensible choice for embedded work instead of C or C++.

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

#26

Post by steveklabnik »

jacobush wrote: post #25
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...

Rust is promoted all the time as the sensible choice for embedded work instead of C or C++.

The thing is “embedded” is an extremely broad space. There’s a bunch of Rust stuff going on in some corners, and absolutely none in others.

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

#27

Post by acqq »

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 have to be calculated. For the stack itself to get to be aligned, only the register has to be updated, surely nothing has to be pushed.

So something else must have been happening there, and I don't have time to analyze what, but I'm sure push is surely not necessary for alignment alone.

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

#28

Post by monocasa »

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

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.

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

#29

Post by mehrdadn »

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?

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

#30

Post by saagarjha »

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?

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.)
Post reply on HN