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

Ask HN: What is the state of C++ vs. Rust?

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 156 posts

Re: Ask HN: What is the state of C++ vs. Rust?

#111

Post by burntsushi »

bjourne wrote: post #90

C is still significantly faster than Rust which follows that C++ is too. So unless Rust is able to produce binaries on all major platforms that are as fast as C++, people who need to squeeze out as much performance as possible are not going to drop the language.

> So unless Rust is able to produce binaries on all major platforms that are as fast as C++, people who need to squeeze out as much performance as possible are not going to drop the language.

I guess you missed this in the sibling, but ripgrep does this today, and it works on Windows, Mac and Linux, and should be as fast or faster than GNU grep. See benchmarks: http://blog.burntsushi.net/ripgrep/#single-file-benchmarks See binaries: https://github.com/BurntSushi/ripgrep/releases

Re: Ask HN: What is the state of C++ vs. Rust?

#112

Post by bjourne »

steveklabnik wrote: post #109
bjourne wrote: post #102

Earlier quoted context omitted.

It is not already faster and there are benchmarks that proves that. Check out of the The Computer Language Benchmarks Game, for example. Lots of language communities make the claim that "their" language either is or will eventually be faster than C. Haskell, Julia, Go, Java, Swift... But the proof of the pudding is in the eating and so far none of these safer languages has beaten C.

There's been a lot of variance on the benchmark game lately since things are so close; a couple of months ago, Rust was #2 overall, beating out C++ and just a tad slower than C. The areas where Rust lost the most were because explicit SIMD isn't stable yet. We also upgrade LLVM regularly, and that can cause some fluctuations from time to time. (Rust is currently beating C on one benchmark, within a few tenths of a se…

But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is still significantly faster than Rust which follows that C++ is too" That is still true because we are discussing the current state of the languages and what you wrote does not affect that.

Btw, the last time this topic was discussed we measured the performance using a microbenchmark. Here is the C version: https://gist.github.com/bjourne/4599a387d24c80906475b26b8ac9... None of the Rust aficionados were able to produce a Rust program (using the nightly build of Rust even) that came close.

Re: Ask HN: What is the state of C++ vs. Rust?

#113

Post by jdright »

StavrosK wrote: post #69
computerphage wrote: post #59

Earlier quoted context omitted.

First of all, I agree that cargo blows the C/C++ tools out of the water in terms of ease of use. But I think it's even easier than newer stuff too. It's by far the best dependency manager I've used. I haven't used pip-tools, but I have used pip, npm, bower, and other more modern dependency mangers that work for non-systems programming languages. Cargo has never given me any trouble. Pip has occasionally given me weir…

Hmm, I've had problems with npm too, but none with pip. The trick there is to make sure you're working in the virtualenv of your project, by activating it or using something like virtualfish or the bash equivalent (virtualenv-wrapper, I think).

One problem with pip is that it requires tricks. But seriously, I avoid using python mostly due the headache when trying to use pip. But I'm sure without pip python would be a real hell.

Re: Ask HN: What is the state of C++ vs. Rust?

#114

Post by Const-me »

the_why_of_y wrote: post #107
bjourne wrote: post #102

Earlier quoted context omitted.

It is not already faster and there are benchmarks that proves that. Check out of the The Computer Language Benchmarks Game, for example. Lots of language communities make the claim that "their" language either is or will eventually be faster than C. Haskell, Julia, Go, Java, Swift... But the proof of the pudding is in the eating and so far none of these safer languages has beaten C.

While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics.

Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

Re: Ask HN: What is the state of C++ vs. Rust?

#115

Post by burntsushi »

Const-me wrote: post #114
the_why_of_y wrote: post #107

Earlier quoted context omitted.

While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

Rust's regex library uses manually vectorized code to speed up its search algorithms, so it follows that Rust's type system is more than OK with such things.

Re: Ask HN: What is the state of C++ vs. Rust?

#116

Post by steveklabnik »

bjourne wrote: post #112
steveklabnik wrote: post #109

Earlier quoted context omitted.

There's been a lot of variance on the benchmark game lately since things are so close; a couple of months ago, Rust was #2 overall, beating out C++ and just a tad slower than C. The areas where Rust lost the most were because explicit SIMD isn't stable yet. We also upgrade LLVM regularly, and that can cause some fluctuations from time to time. (Rust is currently beating C on one benchmark, within a few tenths of a se…

But the OP asked "What is the state of C++ vs. Rust?" and I answered "C is still significantly faster than Rust which follows that C++ is too" That is still true because we are discussing the current state of the languages and what you wrote does not affect that. Btw, the last time this topic was discussed we measured the performance using a microbenchmark. Here is the C version: https://gist.github.com/bjourne/4599a…

Yes, but you then also went on to say that no language will ever do it. Rust _has_ consistently beaten C on many of these benchmarks in the past, and continues to remain very close in the ones that it's not.

I actually don't think microbenchmarks are a good way to think about performance anyway. There's two reasons:

First, Rust's safety guarantees let you get away with more dangerous things. Consider scoped threads, or non-atomic reference counting.[1] You _could_ write this in C, and you'd do so for a microbenchmark, but not for a real codebase, as it's far too dangerous. Or, you might do it, but end up with bugs that you don't detect, that aren't there in the Rust version.

1: http://blog.faraday.io/saved-by-the-compiler-parallelizing-a...

Secondly, microbenchmarks are often "can the best person at language X write something faster than the best person at language Y"? I don't think that's nearly as interesting as "When an average programmer of languages X and Y write a program, which is faster?" Rust's default patterns and style is already extremely fast. It's not a guarantee, mind you, but for real-world usage, it's the average case that matters more.

Re: Ask HN: What is the state of C++ vs. Rust?

#117

Post by steveklabnik »

Const-me wrote: post #114
the_why_of_y wrote: post #107

Earlier quoted context omitted.

While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

LLVM already auto-vectorizes sometimes, and you can still drop down to `unsafe` to write explicit SIMD (though it's not yet stable).

Re: Ask HN: What is the state of C++ vs. Rust?

#118

Post by taneq »

vvanders wrote: post #75
blub wrote: post #57

Earlier quoted context omitted.

I specifically said industry because projects come and go. Yes, there are dozens of companies doing some project in Rust. That's true for almost any programming language. I am guessing that it's going to be another 5-10 years until I would need to seriously consider learning Rust, assuming it will be able to break into the mainstream. Safety-wise it could make sense for my industry, which seems to be overwhelmed by C…

Industry is great if you want to make safe, slow bets. PG's essay on lisp is a great example of why you may not want to follow industry. However, the point I was making is there's not a binary switch between C/C++/Rust. There's a great interop/FFI story that allows a targeted/gradual adoption.

I know it's kind of hallowed ground around here, but IMO that essay has one of the highest ratios of survivor bias to good advice that I've ever seen.

Re: Ask HN: What is the state of C++ vs. Rust?

#119

Post by Const-me »

burntsushi wrote: post #115
Const-me wrote: post #114

Earlier quoted context omitted.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

Rust's regex library uses manually vectorized code to speed up its search algorithms, so it follows that Rust's type system is more than OK with such things.

They were lucky. Those regexps were OK only using a single register representation, u8x16. That’s not always the case.

To write efficient SSE code, you need to understand __m128i is a just a hardware register, and use whatever representation you need for particular instruction.

Example: http://stackoverflow.com/a/17355341/126995 The SSE2 code is impossible to translate to Rust, because _mm_sub_epi8 views the registers as std::simd::i8x16, while the subsequent _mm_srli_epi64 views the same registers as std::simd::i64x2

Re: Ask HN: What is the state of C++ vs. Rust?

#120

Post by the_why_of_y »

Const-me wrote: post #114
the_why_of_y wrote: post #107

Earlier quoted context omitted.

While you can write very fast code in C, that doesn't imply that if you spend the same amount of effort solving the same problem in C and in Rust, the C version will be faster, because Rust's type system lets you write programs that exploit traditionally error-prone things like unique ownership and multi-threading in much less development and debugging time than C.

Very fast code in C often means manually vectorized code, written in SSE/AVX/Neon intrinsics. Rust type system prevents same for Rust. Those __m128 values are just raw bytes, different SIMD instructions view them as different types, and Rust's type system ain't OK with that.

So very fast code in C is not actually C code, but written in a non-standard extended C dialect that is also platform specific - thanks for clarifying.

I'm curious if there is a way to limit the entries in the Benchmark Game to just those that actually use only the language standards, where those exist...

Post reply on HN