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

271–280 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#271

Post by naniwaduni »

spiffytech wrote: post #216
moonchild wrote: post #118

Earlier quoted context omitted.

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

CPython isn't a JIT because its goals as a portable reference implementation would be much harder to achieve with a JIT.

To put it another way, there's a reason PyPy trails CPython language features on the scale of literal years. This is not explained by the affordances of the language they're written in! They're just projects with very different requirements which, on some platforms, happen to run a lot of similar-looking code.

Re: Rust is now overall faster than C in benchmarks

#272

Post by jimbokun »

josephg wrote: post #206
vbezhenar wrote: post #153

Earlier quoted context omitted.

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

> I have no idea whether that matters or even easy to measure... It is reasonably easy to measure, and the GP is about right. I've measured a crossover point of around a few hundred items too. (Though I'm sure it'll vary depending on use case and whatnot.) I made a rope data structure a few years ago in C. Its a fancy string data structure which supports inserts and deletes of characters at arbitrary offsets. (Design…

Here's an article about how NSArray on MacOS does something similar:

https://ridiculousfish.com/blog/posts/array.html

In the sense of swapping the underlying implementation as the number of items in the collection increases.

Re: Rust is now overall faster than C in benchmarks

#274

Post by creato »

pjscott wrote: post #106
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/...

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-team.pages.debian.net/benchmarksgame/...

Re: Rust is now overall faster than C in benchmarks

#276

Post by [deleted] »

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

[deleted]

Re: Rust is now overall faster than C in benchmarks

#277

Post by [deleted] »

littlestymaar wrote: post #204
dan-robertson wrote: post #197

Earlier quoted context omitted.

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…

> The reason that C programs often don’t perform as well as an equivalent rust program[1] 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 Brian Cantrill talks[1] about exactly this: in his C version he was using AVL trees because they are eas…

[deleted]

Re: Rust is now overall faster than C in benchmarks

#278

Post by lambda »

brundolf wrote: post #202
lambda wrote: post #191

Earlier quoted context omitted.

Ah, thanks. It's been a while since I've used Ruby seriously. Still not quite sure why "Matz's ruby" is separate on the Benchmark Game rankings, while all other languages are grouped based on the best implementation of the language. Anyhow, that's pretty much irrelevant to my overall point. Thanks for the kind words, not sure why it's getting downvoted other than that I called someone out on their lazy dismissal. But…

Your tone at certain points was overly incendiary, imo (the comment you were replying to was a little bit too). But there was also lots of good substance around those bits. Just my two cents.

Yeah, my tone was a bit incendiary at first, because I get a bit frustrated at the shallow dismissal you see so often on Hacker News (and any number of other tech discussion sites). This kind of snarky dismissive comment is easy to make, and has a tendency to get upvoted because it matches misconceptions that many people have.

These kinds of comments, and downvotes in place of discussion, are corrosive to honest, informative discussion, and I've seen way too many tech discussion communities get taken over by people who make low-effort dismissive comments and avoid engaging in actual substantive discussion.

Re: Rust is now overall faster than C in benchmarks

#279

Post by madars »

nynx wrote: post #9

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

In https://old.reddit.com/r/rust/comments/kpqmrh/rust_is_now_ov... /u/Saefroch writes:

Some years ago I submitted an n-body implementation that used the crunchy crate to unroll the inner loop. This was rejected as being non-idiomatic and obscuring what compilers are/aren't capable of. Rust is currently leading the benchmark because someone added the flag -C llvm-args='-unroll-threshold=500' which achieves the same effect. Why one of these is acceptable and the other isn't is beyond me, and all of this makes the whole project very discouraging.

Re: Rust is now overall faster than C in benchmarks

#280

Post by fancyfish »

topspin wrote: post #146

Is it just me or has that 'benchmarks game' site been growing less navigable over time? It use to be easy to compare benchmarks across several languages. If that capability still exists somewhere it's buried and I'm not interested in puzzling it out. There are no side bars or menus or anything helpful.

It's a bit hard to find, but the page comparing languages is found via the main page -> "Which are fastest?"

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

Post reply on HN