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

91–100 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#91

Post by lawn »

_wldu wrote: post #86
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.

Yes, it seems everyone is always trying to beat C, but really, no one can.

To be fair, if there's a language that has a fair chance it's Rust.

Re: Rust is now overall faster than C in benchmarks

#92

Post by harporoeder »

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.

There was a long period where a fairly unknown theorem proving language ATS (1) was beating C in many test cases on the benchmark game (2) the benchmarks were removed though (3). I expect many languages could be made to win with sufficient effort.

1. http://www.ats-lang.org/ 2. http://web.archive.org/web/20121218042116/http://shootout.al... 3. https://stackoverflow.com/questions/26958969/why-was-the-ats...

Re: Rust is now overall faster than C in benchmarks

#93

Post by Matthias247 »

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 be determined are far more common than exceptional. This happens because null terminated strings feel like idiomatic C to most people.

Rust avoids those from the start by making slices idiomatic.

Another thing I commonly see is the usage of suboptimal containers (like arrays with linear search) - just because it’s there’s no better alternative at hand (standard library doesn’t offer ones and dependency management is messy). Which also makes it less surprising that code in higher level languages might perform better.

Re: Rust is now overall faster than C in benchmarks

#94

Post by spiffytech »

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.

That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks: what kind of performance could I expect to see using technology $FOO? Crucially, that question depends on how someone will realistically implement $FOO.

I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. PyPy manages to outperform CPython because although a C implementation should theoretically be faster, realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach.

I don't know C or Rust well enough to comment on these specific scenarios, but if two technologies can be fast, and one makes that speed accessible while the other encourages implementors to leave performance on the table, that's much more useful information to me than seeing a back-and-forth where folks compete to implement optimizations I'll never make in my own projects.

Re: Rust is now overall faster than C in benchmarks

#95

Post by steveklabnik »

djeiasbsbo wrote: post #79
steveklabnik wrote: post #66

Earlier quoted context omitted.

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

I'm pretty sure that for the classic "Hello World" example that's not the case, because we can simply use the linux write system call. For example, an assembly program that just calls write and then exits is much smaller than even an unlinked version of it that uses printf, because the ELF binary doesn't need to contain information for the linker.

Yes, on the very very very low end, this is the case, but generally, in more real programs, it's not.

(The program I linked is an example of exactly what you're talking about)

Re: Rust is now overall faster than C in benchmarks

#96

Post by martincmartin »

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…

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.

Re: Rust is now overall faster than C in benchmarks

#98

Post by vitus »

spiffytech wrote: post #94
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.

That kind of tit-for-tat in benchmarks seems like it's counter to the goal of benchmarks: what kind of performance could I expect to see using technology $FOO? Crucially, that question depends on how someone will realistically implement $FOO. I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy. PyPy manages to outperform CPython because althou…

You raise a good point. I've always been fascinating by PyPy's performance, personally -- anecdotally, I've achieved ~10x speedups from just running a script with `pypy` instead of `python`. I always attributed that to better performance of the JIT, but I could be wrong.

I have nothing against Rust personally, but it's ultimately not an apples-to-apples comparison if they're not implementing the same algorithm, or even if they're not using the same mechanisms (e.g. Rust explicitly using SSE intrinsics, which are certainly available to C in just as idiomatic a fashion).

Re: Rust is now overall faster than C in benchmarks

#99

Post by jandrewrogers »

vitus wrote: post #74
jeffbee wrote: post #63

Earlier quoted context omitted.

Speaking generally and about no specific program, you should expect C++ to be faster than C. C++ has more ways for the programmer to communicate with the compiler.

At the same time, a lot of those mechanics involve additional overhead (e.g. vtable lookups for dynamic dispatch per inheritance). But yes, some of these do provide hints for the compiler, e.g. constexpr, ownership semantics per unique_ptr. There's nothing stopping a human from writing equivalent C, so my suspicion is that the performance gap is primarily due to the benchmark implementation.

While nothing prevents you from writing C that will generate the equivalent code, it requires several times more lines of C than the equivalent C++. At which point, it becomes an economics discussion. C is usually a choice when pure performance is secondary to other considerations like portability.

Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance hierarchies are not idiomatic in C++. The code gen for C++ looks a lot like hyper-optimized C code, but without having to write hyper-optimized code. C++ naturally provides much more information about intent to the compiler than C does, and modern compilers are excellent at using that information to provide nearly optimal code gen.

Re: Rust is now overall faster than C in benchmarks

#100

Post by gameswithgo »

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