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

191–200 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#191

Post by lambda »

steveklabnik wrote: post #167
lambda wrote: post #130

Earlier quoted context omitted.

> I know I can safely ignore such benchmark And yet, rather than ignoring it, you are commenting on it, with a pithy retort which dismisses the entire benchmark without actually providing any additional insight. Programming languages, compilers, library ecosystems, the groups of people who decide to sit down and try to produce a better result for a given language, and the benchmark maintainers who decide what submiss…

Don't know why you're downvoted, this is a great comment. By the way, YARV has been "ruby" since 2007; these benchmarks were run with ruby 3.0.0preview1. The name has probably just never been changed.

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 I wouldn't worry about it too much, I've been on HN and Reddit for long enough to not care too much about downvotes.

Re: Rust is now overall faster than C in benchmarks

#194

Post by lambda »

rcoveson wrote: post #158
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.

Null terminated strings are often called cstrings. They’re beyond idiomatic; they’re part of the C standard library.

Not just the standard library, but the core language. They are what you get if you write a string literal in your code.

Re: Rust is now overall faster than C in benchmarks

#195

Post by littlestymaar »

throwaway894345 wrote: post #179
jerf wrote: post #125

Earlier quoted context omitted.

I've been fairly convinced for a while that once Rust matures (which is probably fairly close to "now", but I've held this opinion for years) that it's going to have a performance advantage in real code that's going to be hard to capture in benchmarks, because it's easy in a small benchmark to be very careful and ensure that you don't have aliasing, avoid extra copies, etc. Where I expect Rust to really shine perform…

I agree with this. Benchmark code differs from real code in in that it approximates the performance ceiling for a language implementation; it's not "ordinary code" or even "somewhat optimized" but usually the most optimal code one can conceive of with little respect paid to competing concerns, like maintainability. Rust aspires to make idiomatic, maintainable code almost as performant as benchmark code by way of zero…

> If C# and Go preclude 95% of the errors found in Python and JS

Well Go and C#[1] still suffer from the billion dollar mistake (null pointers), which represents at least 1/3 of errors I've witnessed in JavaScript code, so I'd say they at best removes 70% of errors. And there's also logic errors, for which neither Go's or C#'s type system helps either, so maybe we're at 50% error reductions with Go and C# compared to JS and Python. I don't even think that Rust, with its really helpfull type system (ADT + Affine types) achieves 95% error reductions though.

[1]: for C#, at least last time I used it, which was 2011

Re: Rust is now overall faster than C in benchmarks

#196

Post by tutfbhuf »

Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust.

I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C modules in Python if you need the speed, but I don't know if that's a good answer to the problem.

Re: Rust is now overall faster than C in benchmarks

#197

Post by dan-robertson »

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…

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 memory allocation are often painful or fickle so use of pointer-heavy data structures like linked lists is quite uncommon.

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

[1] suppose the programs are independently created at the same time by programmers of equal ability and are idiomatic in their languages. If a C program is rewritten in rust, it is likely to be faster, but that would likely also be true if it were rewritten in C.

Re: Rust is now overall faster than C in benchmarks

#198

Post by [deleted] »

forrestthewoods wrote: post #163
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...

You’re stretching there imho. L1 and L2 are per core. A cacheline is 64 bytes and per-core cache size is on the order of 32kb and 256kb for L1/L2. Reading data from L1 is on the order of 1 nanosecond (or less) and RAM on the order of 50 nanoseconds. If you’re scanning an array and load a dozen cachelines that’s almost certainly preferable to several cache-misses (and lines). Memory access is very often an application…

[deleted]

Re: Rust is now overall faster than C in benchmarks

#199

Post by brundolf »

tutfbhuf wrote: post #196

Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust. I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C mo…

Node uses V8, which does JIT compilation, while CPython is a straight bytecode interpreter. A better point of comparison would be PyPy

Re: Rust is now overall faster than C in benchmarks

#200

Post by burnthrow »

indymike wrote: post #85

Let's talk about speed when we are implementing the same algorithm and optimizations, please. If $1 was donated to cure cancer every time a developer games a comparison like this, there would be no more cancer.

I sort of doubt that, billions of dollars have been spent on cancer research.
Post reply on HN