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

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

381–390 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#381

Post by pjscott »

creato wrote: post #274
pjscott wrote: post #106

Earlier quoted context omitted.

It's not entirely surprising that a carefully-optimized C program using explicit SSE intrinsics, plus a fancy trick involving a low-precision square root instruction fixed up with two iterations of Newton's method, would be fast. :-) What impresses me is that the Rust version didn't do any of that stuff, just wrote very boring, straightforward code -- and got the same speed anyway. Some impressive compilation there!

I would be shocked if those two programs performed the same. C and Rust are using the same compiler backend, better aliasing information probably isn't going to make that big of a difference. Are you sure the rust performance data isn't for one of the other implementations that use the same crufty tricks as the C version? e.g.: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... , https://benchmarksgame-t…

It's pretty startling, but yes, that non-crufty version is "Rust #8" that tops the n-body performance lists:

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

It looks like the autovectorizer did a really good job on this one.

Re: Rust is now overall faster than C in benchmarks

#382

Post by igouy »

ghostwriter wrote: post #359
gameswithgo wrote: post #183

Earlier quoted context omitted.

and its a bad metaphor. there are many reasonable comparisons to be made between any two things even when both are not fruits

Technically speaking, there are limits and you cannot compare incomparable. You can find distinctions between two phenomena, a.k.a. inherent traits that make them different-by-definition from one another, but you cannot compare (liken, collate, contrast) them in any meaningful way. Like, what's the outcome of comparing "soft" with "warm"? And hence, comparing apples to apples are not pointless, quite contrary - they…

> Like, what's the outcome of comparing "soft" with "warm"?

You can have "soft" or you can have "warm" — which do you want?

You can have an apple or you can have an orange — which do you want?

Re: Rust is now overall faster than C in benchmarks

#383

Post by igouy »

Blikkentrekker wrote: post #138
vitus wrote: post #76

Earlier quoted context omitted.

I recall an anecdote about how Haskell actually outperformed C on various tree benchmarks because it was using a better implementation. At some point, the C programmers got fed up with the airs of superiority from Haskell programmers, ported the Haskell implementation, and reclaimed their position. I wouldn't be surprised if there's something similar happening here.

The Haskell code on some pathological examples of these implementations that I have seen has so many unsafe construct, strictness annotations, inlining annotations and so forth that it's practically C in a different syntax. It is not idiomatic Haskell at all and loses all of the touted benefits. Is there a separate benchmark that only accepts idiomatic code?

Is there a GHC compiler switch that ensures only "idiomatic code" is compiled?

One can, with sufficient effort, essentially write C code in Haskell using various unsafe primitives. We would argue that this is not true to the spirit and goals of Haskell, and we have attempted in this paper to remain within the space of “reasonably idiomatic” Haskell. However, we have made abundant use of strictness annotations, explicit strictness, and unboxed vectors. We have, more controversially perhaps, used unsafe array subscripting in places. Are our choices reasonable?

http://www.cs.ru.nl/P.Achten/IFL2013/symposium_proceedings_I...

Re: Rust is now overall faster than C in benchmarks

#384

Post by igouy »

qart wrote: post #120
FartyMcFarter wrote: post #64

Looking at the reverse-complement code, it appears that the Rust and C implementations are using different algorithms: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On a quick inspection: - The Rust code is about twice as long. - The Rust code has CPU feature detection and SSE intrinsics, while the C code is more idiomatic. - The lookup…

I have seen this happening so often: C/C++/Rust often end up using CPU-specific features, and the code starts looking more and more like assembly code, and less like idiomatic high-level language code. Basically, comparisons of programs written in all the other languages against these three become meaningless. And in turn, hurts benchmarksgame as a resource for comparing languages. If I had to write a performant libr…

> If I had to write a performant library at work, I too might rely on CPU-specific assembly wrappers in my code. But IMO, such code has no place in a general-purpose cross-language benchmark site.

My guess is that other people would take your "performant library at work" premise as justification for including that code.

Re: Rust is now overall faster than C in benchmarks

#385

Post by igouy »

littlestymaar wrote: post #201
pornel wrote: post #80

Earlier quoted context omitted.

Nothing stops someone from copying and submitting other implementation's algorithm. There are multiple implementations of each benchmark for every language: • https://benchmarksgame-team.pages.debian.net/benchmarksgame/... • https://benchmarksgame-team.pages.debian.net/benchmarksgame/... • https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It's possible that someone has already submitted both algorithms…

> Nothing stops someone Well, it looks like the submission process[0] and the maintainer[1] do, actually. [0]: https://www.reddit.com/r/rust/comments/kpqmrh/rust_is_now_ov... [1]: https://www.reddit.com/r/rust/comments/kpqmrh/rust_is_now_ov...

When someone on proggit writes — "Yeah it's really hard to submit code. Not only do you have to sign up for their site but they don't accept Gmail addresses." — they may just be repeating something they read on proggit.

Re: Rust is now overall faster than C in benchmarks

#386

Post by jcdentonunatco »

dan-robertson wrote: post #197
Matthias247 wrote: post #93

Apart from those benchmark games a lot of real world C is a lot less performant than people think it might be. I spent a fair amount of time reviewing C code in the last 5 years - and things that pop up in nearly every review are costly string operations. Linear counts due to the use of null terminated strings and extra allocations for substrings to attach null terminators, or just deep copies because ownership can’t…

The reason that C programs often perform well is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays. In many ways, modern CPUs are particularly designed to run the machine code generated by C compilers on typical C code like this. Pointers and memo…

It's amazing that you could write this much and have it be 100% wrong.

Re: Rust is now overall faster than C in benchmarks

#387

Post by tick_tock_tick »

volta87 wrote: post #349
tick_tock_tick wrote: post #319

Earlier quoted context omitted.

In theory one day Rust will but LLVM doesn't support anything beyond the function level for noalias since that's all that's needed to support __restrict in C. Even that isn't used by Rust most of the time since they have found several bugs in it.

LLVM does support tbaa! and noalias! metadata.

https://github.com/rust-lang/rust/issues/54878

Re: Rust is now overall faster than C in benchmarks

#388

Post by igouy »

pornel wrote: post #80
FartyMcFarter wrote: post #64

Looking at the reverse-complement code, it appears that the Rust and C implementations are using different algorithms: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On a quick inspection: - The Rust code is about twice as long. - The Rust code has CPU feature detection and SSE intrinsics, while the C code is more idiomatic. - The lookup…

Nothing stops someone from copying and submitting other implementation's algorithm. There are multiple implementations of each benchmark for every language: • https://benchmarksgame-team.pages.debian.net/benchmarksgame/... • https://benchmarksgame-team.pages.debian.net/benchmarksgame/... • https://benchmarksgame-team.pages.debian.net/benchmarksgame/... It's possible that someone has already submitted both algorithms…

It's only 6 weeks since that Rust revcomp #1 program was contributed — November 23, 2020.

Re: Rust is now overall faster than C in benchmarks

#389

Post by igouy »

Tade0 wrote: post #345
wuxb wrote: post #321

Just took a quick peek at the binary-trees C code. Why using openmp while the others don't? why use recursive functions? The C implementation is not correctly optimized. People just paid more attention to Rust and other languages. Rust can be as fast as C, but "faster" is really misleading. BTW, I use clang all the time since it's better than GCC.

It seems that someone simply tacked openmp on without checking if it actually increases performance in this case - which is unusual, because I remember a course in college, part of which was a project aiming to teach the student that openmp is not a silver bullet and should be used only when it actually helps.

How do you know that this is not one of those cases when openmp actually helps?

Re: Rust is now overall faster than C in benchmarks

#390

Post by pjmlp »

MaxBarraclough wrote: post #371
enedil wrote: post #362

Earlier quoted context omitted.

This is not true. Undefined behaviour can mean that ``` bool b; if (b) printf("1 "); if (!b) printf("2 "); ``` might print `1 2 `.

Right on. Unless the compiler documentation promises a consistent handling of the various triggers of undefined behaviour, it is under no obligation to always generate code that handles UB consistently. To my knowledge there is no C compiler that promises to always handle all forms of UB consistently. The closest you could get would probably be something like Valgrind.

At least for this specific case Microsoft and Google are fixing it by always initializing the variables.
Post reply on HN