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

211–220 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#211

Post by josephg »

michaelmior wrote: post #150
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…

> null terminated strings feel like idiomatic C to most people Doesn't that mean that null terminated strings is idiomatic C? That is, my understanding of the term idiomatic is that it is defined by whatever is most natural to users of a language regardless of whether it is the most performant.

One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers.

It would be the equivalent of teaching people to write books without encouraging them to read anything.

To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lot from doing so. One of my first discoveries was this beauty in the Redis source code:

https://github.com/redis/redis/blob/3.0/src/sds.h

The idea is to have a string struct that stores its length and content. But the pointer passed around is a pointer to the (null terminated) contents field in the struct. The string is efficient for internal calls (the length can be queried by subtracting from the pointer). But the pointer is also an idiomatic null-terminated C string pointer, compatible with the standard library and everything else. (typedef char *sds;)

Dovecot is also a gem to read if you're looking for inspiration. The way it manages memory pools is delightful - and I'm sure much more performant than idiomatic rust. (That is, without reaching for arena allocator crates and alternate implementations of Box and Vec).

Re: Rust is now overall faster than C in benchmarks

#212

Post by steveklabnik »

rurban wrote: post #173

Because Rust does alloca for all locals, and this if course faster. Everyone else avoids it for security reasons. Just search the Rust bugtracker for stack overflows.

You are confusing the llvm instruction “alloca” with the C feature “alloca.” llvm will use its alloca instruction for C and C++ local variables the same way as Rust does.

You are correct that the C feature is often banned. Rust doesn’t even support it at all.

Re: Rust is now overall faster than C in benchmarks

#213

Post by kouteiheika »

stabbles wrote: post #53
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-... […

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.

> I doubt there's any performance to be gained that way

And how do you know this? Have you actually measured the difference?

My CPU-heavy program (which takes ~30 seconds to run on a 32-core Threadripper) gains ~15% extra performance if I turn it on.

Re: Rust is now overall faster than C in benchmarks

#214

Post by jolux »

steveklabnik wrote: post #17
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 think what's most interesting about your comment is the assumption that the three are in the same ballpark. You're not wrong, but it just reminds me of how far we've come. That is, the key is not "which of these three can eke out the last tiny ounce of things," but that Rust has successfully landed across that gap you see in the graph. That it's "(C/C++/Rust) vs everything else" is in of itself an interesting resul…

>You can see some skepticism of the premise elsewhere in this thread, even.

Heh, well. The downvotes are clearly trying to tell me something, though I'm not sure what. I can guess. I assumed that this was something widely agreed upon at this point but clearly I assumed incorrectly.

I think ATS is in that category too but it was removed from the benchmarks game at some point. It's also vastly more esoteric and complicated than Rust is from my limited knowledge. Perhaps someday Zig will get there as well. I wouldn't have expected that this niche would ever see so much exploration, as C and C++ were the only game in town for so long.

Re: Rust is now overall faster than C in benchmarks

#215

Post by wang_li »

gameswithgo wrote: post #184
vitus wrote: post #122

Earlier quoted context omitted.

> Nobody really thinks Rust is faster than C now. The submission title would beg to differ. (I know, it explicitly calls out "benchmarks" as the context.) I think languages like Rust or Swift have significant advantages around safety over C/C++, while not sacrificing much in terms of performance. But if one language's benchmark contributors are willing to put in more effort than another's to eke out additional perfor…

go fix the c implementation then. no single person can maintain optimally implemented solutions over dozens of languages. its up to we the people to help out. you want perfectly equivalent comparisons, make it happen

Yeah. At a fundamental level these programs are running on the same hardware. Unless you’ve an ultra simplistic language (basic or logo), one could implement identical algorithms and methodologies and techniques and get the same performance.

Re: Rust is now overall faster than C in benchmarks

#216

Post by spiffytech »

moonchild wrote: post #118
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…

> 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. Pypy outperforms cpython for the simple reason that pypy is a jit where cpython is a basic bytecode interpreter. Anything else is icing on the cake. The only reason python seems slow a…

PyPy has a JIT because using Python as the implementation language made it simple to build a runtime generator instead of a single runtime implementation, so RPython (the underlying PyPy tech) can generate a JIT and non-JIT runtime from the same source code. Conversely, the CPython team doesn't have the resources to make a JIT runtime the bespoke way that's more typical for these projects.

https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding...

Re: Rust is now overall faster than C in benchmarks

#217

Post by steveklabnik »

jolux wrote: post #214
steveklabnik wrote: post #17

Earlier quoted context omitted.

I think what's most interesting about your comment is the assumption that the three are in the same ballpark. You're not wrong, but it just reminds me of how far we've come. That is, the key is not "which of these three can eke out the last tiny ounce of things," but that Rust has successfully landed across that gap you see in the graph. That it's "(C/C++/Rust) vs everything else" is in of itself an interesting resul…

>You can see some skepticism of the premise elsewhere in this thread, even. Heh, well. The downvotes are clearly trying to tell me something, though I'm not sure what. I can guess. I assumed that this was something widely agreed upon at this point but clearly I assumed incorrectly. I think ATS is in that category too but it was removed from the benchmarks game at some point. It's also vastly more esoteric and complic…

Yeah I mean, to be clear I believe you are right and am pretty surprised you were downvoted. It happens I guess.

Re: Rust is now overall faster than C in benchmarks

#218

Post by steveklabnik »

josephg wrote: post #211
michaelmior wrote: post #150

Earlier quoted context omitted.

> null terminated strings feel like idiomatic C to most people Doesn't that mean that null terminated strings is idiomatic C? That is, my understanding of the term idiomatic is that it is defined by whatever is most natural to users of a language regardless of whether it is the most performant.

One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers. It would be the equivalent of teaching people to write books without encouraging them to read anything. To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lo…

What makes you think arenas are considered unidiomatic in Rust? They’re there to be used when appropriate!

Re: Rust is now overall faster than C in benchmarks

#219

Post by jolux »

gambiting wrote: post #105
tetromino_ wrote: post #68

Earlier quoted context omitted.

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.

The comment was illustrating why not including the length is a problem: it lead to a community norm that is bad for performance (stdlib functions not taking string length).

Re: Rust is now overall faster than C in benchmarks

#220

Post by scottlamb »

vbezhenar wrote: post #153
frutiger wrote: post #149

Earlier quoted context omitted.

Mostly agree with your comment but linear search through arrays of size less than a few hundred will typically beat more sophisticated structures such as red-black trees or hashtables. This is due to prefetching and avoidance of unpredictable pointer traversals. Asymptotic complexity is only that: asymptotic. In many programs in many domains the sizes of these data structures will rarely exceed this limit.

It might be fast, but it'll load CPU caches with that data and it'll evict another useful data. Which means that while this particular code will be fast or at least not very slow, some other code will be slow because its data have to be fetched again. I have no idea whether that matters or even easy to measure...

Conversely, more sophisticated algorithms, and particularly monomorphization, may bloat the code size, causing icache, L2/L3 cache, and TLB misses. (Also slows compilation.) I think this is under-appreciated because it doesn't show in microbenchmarks. (I wish I knew of an easy way to measure how much cache pressure you're causing from a microbenchmark.)

I suspect for this reason it'd be better in Rust to use a Go-like hash map implementation [1] that keeps all the key/value information (size, Hash and Eq implementations) in a vtable-like form rather than be monomorphized, except in really hot inner loops where the specialization is worth it. There was an interesting article and discussion on reddit relating to this [2] where someone made a toy type-erased map (though not as nice as Go's) to measure the difference in compilation times. Maybe some day I'll make a more production-ready attempt...

[1] https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

[2] https://www.reddit.com/r/rust/comments/g1skz4/an_experiment_...

Post reply on HN