Hacker News Reader

Comment by pclmulqdq | Hacker News Reader

Idiomatic "low level" rust clocks in at about 10-50% slower than hand-coded C every time I try it. It is also about 10x easier to write the Rust code. Unsafe is just required a lot of the time. Sometimes it's code size or struct size just being larger to express a similar concept. To get back your performance you have to do things that are un-idiomatic (but you have to do in C anyway).

View on HN

That is an unbelievable claim.

1. Rust structs are generally smaller due to layout optimization.

2. A 10-50% difference is well within the “are you measuring debug builds?” territory.

I’m curious what code you are writing that requires unsafe all the time? I do a lot of low-level optimization, and unsafe is barely ever actually needed.

It sounds like you work with people who don't really know C. Understanding how to pack a struct is a pretty basic skill. Write an optimized database or network stack without unsafe for me.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I did not say “never”, I said “barely ever”.

I’m not really sure what your point is by linking the benchmarks game. I mean, it’s a fun activity, but this is saying nothing about C vs. Rust. It may or may not be saying something about GCC vs. LLVM.

I also did not say "always," I said "every time I try it." The benchmarks game is a public example of this, with well-optimized implementations in all languages.

Why can't people just take the win of "10% slower, 10x easier"?

Rust versus C clang :-)

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

It takes some hubris to post "rust is consistently 10% slower than C" take and back it up with a page which shows a result 6:4 in Rusts favor.

I said "every time I try it" and I said "idiomatic Rust." The fast rust implementations are consistently starred there, indicating use of hand SIMD or unsafe or others. If you read them, they are not very idiomatic.

Also note that 3 of 4 comparisons in favor of Rust are marked "contentious" for using different algorithms with different limitations - they are not equivalents. The last one is k-nucleotide, which is a very algorithmically heavy problem where nobody has given optimized C and Rust has won at producing a decently optimized thing quickly. Note that the fastest C++ implementation handily beats Rust on that one, also.

I know what you said. I just don't think it was interesting. If by idiomatic rust, you mean generic "unoptimized" Rust being slower than optimized C, then yeah. No shit.

On a similar note, I don't think it's worth talking about C as if the only C being written is highly optimized hand rolled assembly style of C. That's one in a thousand projects.

Now, as for the benchmarks game, you mean 3 of 6 comparisons in favor of Rust. Rust is winning the benchmarks against C there.

I had a look and the top Rust and C entries are using the same pcre2 library in regex-redux. Same for pidigits where both libraries are using GMP.

The only library difference I can see is that the C entries are using OpenMP and both Rust entries are using Rayon. Now, you could claim that using Rayon gives Rust an unfair advantage. But an entirely userland library beating an industry standard with support from compilers is not a good look for C.

It just fundamentally does not make sense to compare languages by comparing codegen backends. GCC and LLVM do not produce the same code for equivalent code, especially when optimizations are applied. It's an apples-to-oranges comparison.

Using Clang instead of GCC, the comparison becomes slightly better, at least for microbenchmarks that don't rely too much on libraries.

These benchmarks are still useful from a practical viewpoint - answering the question "what's the expected performance bracket of using language X in real projects today". But it doesn't say anything fundamental about the language design or even the quality of the implementation.

Show examples please.

Reply on news.ycombinator.com