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

101–110 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#101

Post by FartyMcFarter »

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…

> I like PyPy as an example: on the surface, implementing a Python runtime in Python and expecting performance gains seems crazy.

Not if it includes a JIT compiler, as PyPy does. I don't know much about PyPy, but if most of the time is spent in JITted machine code, the fact that it's written in Python may not affect performance much.

Re: Rust is now overall faster than C in benchmarks

#102

Post by djeiasbsbo »

londons_explore wrote: post #43
jolux wrote: post #11

I think benchmarking C vs C++ vs Rust must only really be useful for researchers. They’re all making a similar tradeoff for performance: forcing you to consider how you use memory. Does anyone work in a field where the performance difference between these specific three platforms matters? I’m genuinely curious. Edit: also, if you could explain briefly why and what makes particular choices out of the three unsuitable,…

I do some graphics stuff. As soon as you get to "this chunk of code needs to be run for every pixel of every 4k frame at 60fps", suddenly the number of clock cycles and registers matters... Some of my platforms don't have GPU's, so it really is squeezing everything possible out of the language and compiler...

I do audio stuff and it is the same there. DSP is easy until it has to be in real time and there can only be minimal latency...

Re: Rust is now overall faster than C in benchmarks

#103

Post by steinuil »

harporoeder wrote: post #92
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.

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

ATS is not really a theorem proving language, it's almost a superset of C with a very long list of type system and language features that lets you write anything from C code with no safety to very high level recursive functional code with lifetime tracking which will translate to efficient C code, if the transformations are proved to be correct. It's a weird beast, but I'm not surprised it outperformed some C implementations, because it is basically C with a lot more features.

Re: Rust is now overall faster than C in benchmarks

#104

Post by mh7 »

martincmartin wrote: post #96
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.

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.

Re: Rust is now overall faster than C in benchmarks

#105

Post by gambiting »

tetromino_ wrote: post #68
yudlejoza wrote: post #8

When Rust is faster than C in a benchmark in which C++ is also faster than C, I know I can safely ignore such benchmark.

The problem is not with C the language, but with the C standard library, which has many inefficiency warts. Examples: * Strings. Any form of string access other than scanning the string's characters one by one from start to finish can benefit from knowing the string's length in advance. In C++, std::string and std::string_view know their lengths; plain C strings don't. Thus, in performance-optimal plain C, almost any…

>>plain C strings

But.....there is no such thing. There are arrays of chars, the whole principle of C is "if you want to know the length of a string....just store it yourself". It's a bit like saying that two wooden planks don't have the same functionality as a cupboard. Like, you're technically correct, but the whole idea is that you can use the planks to build your own cupboard or literally anything else.

Re: Rust is now overall faster than C in benchmarks

#106

Post by pjscott »

FartyMcFarter wrote: post #55
nynx wrote: post #9

The fastest n-body program is written in very idiomatic rust. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

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!

Re: Rust is now overall faster than C in benchmarks

#107

Post by gameswithgo »

vitus wrote: post #98
spiffytech wrote: post #94

Earlier quoted context omitted.

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 ev…

comparing apples to apples is pointless, they are both apples.

and you can always compare “equivalent” algorithms as some languages may not be able to efficiently express the same algorithm as another. i know what you are after, but trying to have some benchmark that is “fair” according to some spec that is important to your needs will just be seen as pointless to others. benchmark game at least lets us see what the performance ceiling is of various languages, and anytime you object to a language having a worse implementation you may go fix it.

i think what anyone with a clue understands is that C C++ and Rust all have roughly equivalent performance ceilings. Nobody really thinks Rust is faster than C now.

Re: Rust is now overall faster than C in benchmarks

#108

Post by jeffbee »

vitus wrote: post #83
jeffbee wrote: post #77

Earlier quoted context omitted.

You've got it backwards. For the same amount of polymorphism in the design of a program C++ is likely to be faster because a C++ compiler can often devirtualize calls but a C compiler faced with a home-grown vtable (the struct of function pointers that every large C program eventually uses) will never be able to do so.

Why bother to write the vtable in the first place? My experience is that C++ that's written for performance will often prefer the use of templates over inheritance since the cost is then paid upfront by the compiler. What's stopping a C programmer from hand-coding template instantiations (via macro or otherwise)?

Sure you are welcome to reimplement C++ in C macros. When your time is worthless anything is possible.

Re: Rust is now overall faster than C in benchmarks

#109

Post by walki »

arcticbull wrote: post #42
harporoeder wrote: post #2

I was wondering if perhaps this was actually measuring a difference between LLVM and GCC, but they also provide a set of benchmarks of C Clang vs C GCC (1) and Clang is generally slower in those test. Although there is some correlation between the ones Clang wins in C And Rust. 1. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Rust can be faster than C because in general C compilers have to assume that pointers to memory locations can overlap (unless you mark them __restrict). Rust forbids aliasing pointers. This opens up a whole world of optimizations in the Rust compiler. Broadly speaking this is why Rust can genuinely be faster than C. Same is true in FORTRAN, for what it's worth.

> C compilers have to assume that pointers to memory locations can overlap, unless you mark them __restrict...

What I don't fully understand is: "GCC has the option -fstrict-aliasing which enables aliasing optimizations globally and expects you to ensure that nothing gets illegally aliased. This optimization is enabled for -O2 and -O3 I believe." (source: https://stackoverflow.com/a/7298596)

Doesn't this mean that C++ programs compiled in release mode behave as if all pointers are marked with __restrict?

Re: Rust is now overall faster than C in benchmarks

#110

Post by nindalf »

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.

Post reply on HN