Rust is now overall faster than C in benchmarks • Hacker News Board

Re: Rust is now overall faster than C in benchmarks

#131

Post by berkut » Sun, Jan 03, 2021, 9:30 PM UTC

awestroke wrote: post #114

FartyMcFarter wrote: post #55

Earlier quoted context omitted.

n-body in C compiled by clang runs just as fast as Rust apparently: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

The code for the C-Clang version is terrifying, compared to the Rust version. Which one would you rather maintain?

Well, given the comments at the top:

// Contributed by Mark C. Lewis.

// Modified slightly by Chad Whipkey.

// Converted from Java to C++ and added SSE support by Branimir Maksimovic.

// Converted from C++ to C by Alexey Medvedchikov.

// Modified by Jeremy Zerfas.

It sounds like no-one bothered to actually write a from-scratch version of many of these things :)

Re: Rust is now overall faster than C in benchmarks

#132

Post by mlyle » Sun, Jan 03, 2021, 9:37 PM UTC

steveklabnik wrote: post #66

mlyle wrote: post #47

Earlier quoted context omitted.

A big part of why binaries are "big" is dynamic linking and external symbols. That Rust hello world is just hand-crafted to never be linkable to anything else at runtime and invoke a system call with a buffer. This isn't really how we'd like to do most things.

Interestingly enough, I would say that dynamic linking makes binaries smaller, that code no longer lives in the binary, but another place instead.

Sure. But there's a lot of overhead that comes with it, too.

Re: Rust is now overall faster than C in benchmarks

#133

Post by kolbe » Sun, Jan 03, 2021, 9:38 PM UTC

nindalf wrote: post #110

Svetlitski wrote: post #49

Once LLVM fixes some bugs with `noalias`, at which point Rust will begin using it again in more circumstances [1], I'd expect to see Rust get even faster in these benchmarks, given that the Rust compiler knows much more about which pointers do/do-not alias than most other programming languages [2] and the myriad optimizations this knowledge allows. [1] https://github.com/rust-lang/rust/issues/54878#issuecomment-... […

How often does benchmark code have a function that takes two pointers that could potentially alias each other? If it's as rare as I think it is, it might not have that much of an impact on Rust's position in the benchmarks game. Still, real world performance will probably benefit from this fix so it's a positive change regardless.

The problem is that it’s “rare” and not “impossible.” Compilers have to be logically sound, not probabilistic when it comes to defined behaviors.

Re: Rust is now overall faster than C in benchmarks

#134

Post by Blikkentrekker » Sun, Jan 03, 2021, 9:39 PM UTC

vvanders wrote: post #60

stabbles wrote: post #53

Earlier quoted context omitted.

I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.

Have you ever used restrict in anger? I've done it when we really needed that performance for an inner loop(particle system). It can be a real bastard to keep the non-alias constraint held constant in a large, multi-person codebase and the error cases are really gnarly to chase down. Compare that to Rust which has this knowledge built in since it naturally falls out of the ownership model.

Isn't every pointer `restrict` in Fortran which was often cited as why it still outperformed C in many cases for a very long time?

Re: Rust is now overall faster than C in benchmarks

#135

Post by colejohnson66 » Sun, Jan 03, 2021, 9:42 PM UTC

gameswithgo wrote: post #100

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…

cpu feature detection is way easier in rust. its just built into the core libs.

Doesn’t gcc have a CPU feature branching system? You use it by attaching attributes to functions that say what instructions are required. Granted, it’s not as “elegant” as Rust, but it does exist.

Re: Rust is now overall faster than C in benchmarks

#136

Post by loxias » Sun, Jan 03, 2021, 9:43 PM UTC

vitus wrote: post #76

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

It's exactly the same thing. I've been seeing this tossed around for years now, and one of these days it'll make me grumpy enough to fix the benchmark.

Re: Rust is now overall faster than C in benchmarks

#137

Post by marvy » Sun, Jan 03, 2021, 9:43 PM UTC

ryanianian wrote: post #116

mh7 wrote: post #104

Earlier quoted context omitted.

It's more to do with the fact that std::sort's definition is visible to the compiler and qsort() is not. Put qsort() code in stdlib.h, make it static and write a static intcmp() and you'll see the compiler inline that no problem.

Sure you can hard-code intcmp into qsort but then it would only work for arrays of ints. You could do some macro magic instead of templates e.g. `DEFINE_QSORT(int, intcmp)` which could stamp out `qsort_int` but that's not a part of the stdlib. C++ arguably gets this right since sort and sort will be separate functions, although templates are of course a footgun. And of course duping the logic for std::sort for a bunc…

I think mh7 did not mean to hard-code intcmp into qsort. The idea is to move the definition of qsort directly into the stdlib.h header file. That way, the compiler can see the definition of qsort and intcmp at the same time.

In that case, the compiler could make a specialized qsort using intcmp automatically.

Re: Rust is now overall faster than C in benchmarks

#138

Post by Blikkentrekker » Sun, Jan 03, 2021, 9:43 PM UTC

vitus wrote: post #76

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

Re: Rust is now overall faster than C in benchmarks

#139

Post by lumost » Sun, Jan 03, 2021, 9:44 PM UTC

bluecalm wrote: post #129

martincmartin wrote: post #96

Earlier quoted context omitted.

Also lack of generics can make it slow, e.g. qsort() requires a function call for each comparison. So C++'s std::sort() can be significantly faster on an array of integers.

I benchmarked it several times in the past and couldn't replicate std::sort being faster (GCC with high optimization settings). Anyway both are slow. If you need fast sort you need an implementation without any function calls (no recursive calls) and both the pivot choice and the chunk size at which insert sort kicks in optimized to your data and hardware. My experience is that you can beat built in sort by 2x to 3x.

How would you perform this optimization? If it’s the same data getting sorted, why not put it in an ordered data structure?

Re: Rust is now overall faster than C in benchmarks

#140

Post by the8472 » Sun, Jan 03, 2021, 9:46 PM UTC

lmilcin wrote: post #65

Which is not at all surprising. Rust has much larger compilation unit and knows more about what can read/write a particular piece of memory. This allows some occasions for optimization where C compiler must be conservative. An example of simpler version of this is Fortran that can be faster for numerical loads due to the fact that Fortran disallows aliasing of function arguments. C on the other hand, must pay the pri…

Wouldn't the C compiler be allowed to make similar assumptions with -flto or -fwhole-program?