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

231–240 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#231

Post by wink »

blackrock wrote: post #228
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…

Fascinating. I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place. I assume most C++ programs heavily use more of these advanced data structures, correct?

You can't really compare C with a C++ stdlib or boost, or Qt. Well, some organizations surely have their own repo of debugged, tested, and optimized stuff but I guess a lot of them roll everything on their own again and again - and in C++ there is a rich ecosystem, at least for basic data structures.

Re: Rust is now overall faster than C in benchmarks

#232

Post by burnthrow »

josephg wrote: post #222
steveklabnik wrote: post #218

Earlier quoted context omitted.

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

They seem unidiomatic because you have to fight the standard library to use them. Using an arena means abandoning String, Vec, Box, std::collections, and so on. I have no problem doing that if I need to. But it feels like I'm fighting against the grain of rust more than I'd like.

This topic is of great interest to me, do you know if there is any related official or community documentation on using arena allocation (and the problems you mentioned) in Rust? I've only found https://doc.rust-lang.org/1.1.0/arena/index.html

Re: Rust is now overall faster than C in benchmarks

#233

Post by ghostwriter »

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…

> It's also vastly more esoteric and complicated than Rust is from my limited knowledge.

I doubt that ATS is more complicated than Rust at on-par feature comparison. It gets more complex only when you reach for a larger set of static constraints you can express in ATS, that are unavailable in Rust: things like dependent types and complete formal proofs that you don't need a separate language for. It feels esoteric only because those features in such low level languages are extremely rare. Also, consider the amount of effort you need to spend on learning a new toolchain (Rust), whereas ATS seems like a plugin/extra compilation step on top of your regular and familiar C toolchain.

Re: Rust is now overall faster than C in benchmarks

#234

Post by dodobirdlord »

notorandit wrote: post #141

I am not sure I can buy such a comparison. Someone smarter than me already argued about test implementations. Someone else also put compilers and interpreters into prospective. Of course language expressiveness can gauge in but, IMHO, comparing the same sort algorithm or the same hash table implementation (or n-queens algo) could make much more sense especially with comparable compilers. If Rust implementation is fat…

The Rust language specifically gives more information and thus more optimization opportunities to the compiler. Plus, when comparing Rust code compiled with rustc and C code compiled with Clang, both are using LLVM as the compiler backend, so what primarily comes into play is how expressive each language is, and how idiomatic it is to write code that will be optimized by the compiler.

Both C and Rust are capable of just inlining optimal assembly, so comparing "pure speed potential" is pointless.

Re: Rust is now overall faster than C in benchmarks

#236

Post by fermienrico »

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…

Forgive me for asking a stupid question: what does it mean when something is “idiomatic” in a programming language context? Is it just the best or recommended way to do something? Or is it something that’s supported by the language? Or something else?

Re: Rust is now overall faster than C in benchmarks

#237

Post by steveklabnik »

burnthrow wrote: post #232
josephg wrote: post #222

Earlier quoted context omitted.

They seem unidiomatic because you have to fight the standard library to use them. Using an arena means abandoning String, Vec, Box, std::collections, and so on. I have no problem doing that if I need to. But it feels like I'm fighting against the grain of rust more than I'd like.

This topic is of great interest to me, do you know if there is any related official or community documentation on using arena allocation (and the problems you mentioned) in Rust? I've only found https://doc.rust-lang.org/1.1.0/arena/index.html

Crates like https://crates.io/crates/typed-arena and https://github.com/fitzgen/bumpalo are the way you do this in today’s Rust, but what he’s referring to is that types like String manage their own allocations and aren’t yet parameterizable by an allocator. So they’re not super easy to use together.

In my experience most of the time you need arenas you’re using your own data structure anyway, but YMMV.

Re: Rust is now overall faster than C in benchmarks

#238

Post by throwaway894345 »

roca wrote: post #208
throwaway894345 wrote: post #179

Earlier quoted context omitted.

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…

The optimal point on the tradeoff between developer velocity and performance/correctness depends a lot on the domain, in particular: -- How much usage do you expect to have? The more usage, the more important performance and correctness are. -- How critical is your application? The more critical it is, the more important correctness is. Also, the argument that you can spend developer time to increase correctness just…

> The optimal point on the tradeoff between developer velocity and performance/correctness depends a lot on the domain

Agreed. This is what I was alluding to by "many applications absolutely index on developer velocity and performance". Note that it's even a bit more nuanced--within an application there are bits that are more sensitive than others. For example, the UI widgets are typically much less sensitive than the security, data privacy, and data integrity bits. Even still, I haven't noticed a frenzied rewriting of these systems from Go/C#/Java/etc into Rust, and I'm willing to bet that there's a fair amount of this kind of code implemented in JavaScript or Python.

> How much usage do you expect to have? The more usage, the more important performance and correctness are.

True, but this is a very low-value concern. Notably, hugely popular apps like Reddit can break altogether on a nearly daily basis (never mind more minor bugs, like some UI widget breaking) and they're still content to write in a completely dynamic language.

> How critical is your application? The more critical it is, the more important correctness is.

I think this is a much more important driver than usage, but relatively little software is so critical. As previously mentioned, there's lots of software that governs privacy and security systems that isn't being frenzily rewritten in Rust. Even OpenSSL, an application in which correctness is far more important than velocity, isn't considering a rewrite to Rust despite that it's written in a language with worse static verifiability than the Go/C#/Java tier. This is probably the kind of application that I would want to see in Rust--it's very sensitive to performance and correctness; which is to say, I think OpenSSL is very near the boundary at which writing in Rust makes economic sense (something that is very stable and very sensitive to correctness and performance). It's almost certainly not your web services.

> Also, the argument that you can spend developer time to increase correctness just by writing more tests works up to a point, but then it doesn't, because of diminishing returns. With Rust you can eliminate certain entire classes of bugs which tests will never reach.

Yeah, sorry, my brain was thinking one thing and my fingers typed another. I should have said "writing additional tests would recoup a bit less than the additional 4% that Rust would get you"; instead I typed "more". I missed the edit window, so I can't update my post.

Re: Rust is now overall faster than C in benchmarks

#239

Post by grzm »

fermienrico wrote: post #236
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…

Forgive me for asking a stupid question: what does it mean when something is “idiomatic” in a programming language context? Is it just the best or recommended way to do something? Or is it something that’s supported by the language? Or something else?

Idiomatic in a programming language means pretty much what it means in any other language: how would someone fluent in the language express it? In a programming context, that may also correspond to the most performant or otherwise "best" expression, but sometimes it's just a commonly used style or phrase.

Re: Rust is now overall faster than C in benchmarks

#240

Post by amelius »

FartyMcFarter wrote: post #124
pjscott wrote: post #106

Earlier quoted context omitted.

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!

Good point! It would be interesting to find out where the Rust version gets most of its speed from.

Yes, it could be mostly LLVM doing the heavy lifting here, for all we know.
Post reply on HN