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

241–250 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#241

Post by ummonk »

frutiger wrote: post #149
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…

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.

This is why Rust uses B-trees, which combine linear search and trees at optimal ratios.

Re: Rust is now overall faster than C in benchmarks

#242

Post by throwaway894345 »

roca wrote: post #207
littlestymaar wrote: post #195

Earlier quoted context omitted.

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

Newtypes are also pretty great for detecting logic errors. (You can use them in Go and C# but they're not idiomatic and usually not zero-cost so people usually don't.)

Newtypes are pretty idiomatic in Go (e.g., https://golang.org/src/os/types.go#L35), and they're so inexpensive that cost isn't a reason to forego them 99% of the time.

Re: Rust is now overall faster than C in benchmarks

#243

Post by roca »

throwaway894345 wrote: post #238
roca wrote: post #208

Earlier quoted context omitted.

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

I think we mostly agree.

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

Yes, but I wonder if people are sometimes being irrational here. You pay for those breaks out of the devops budget. Moving breakage to earlier in the developer cycle typically reduces the cost of fixing it.

Regarding OpenSSL, there are a few reasons that isn't going to be rewritten in Rust anytime soon. The developers probably don't know Rust. OpenSSL runs in lots of places that don't have a Rust toolchain. Even if you rewrite it in Rust you're stuck with a bad API so why bother. In general there are more reasons against rewrite code in Rust than against writing new code in Rust ... and more reasons against writing new code in Rust that interfaces with old code than writing new greenfield code in Rust.

Re: Rust is now overall faster than C in benchmarks

#244

Post by burnthrow »

steveklabnik wrote: post #237
burnthrow wrote: post #232

Earlier quoted context omitted.

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.

Thanks for linking those projects and for "yet", which led me to the pages below

https://rust-lang.github.io/rfcs/1398-kinds-of-allocators.ht...

https://github.com/rust-lang/rust/issues/32838

https://github.com/rust-lang/wg-allocators

Re: Rust is now overall faster than C in benchmarks

#246

Post by Someone »

FartyMcFarter wrote: post #223
pjmlp wrote: post #171

Earlier quoted context omitted.

One of C's biggest marketing successes. All high level languages are portable, including some older than C. It helps when one drags the OS the language was born on, along via parallel standards like POSIX.

> All high level languages are portable, including some older than C. Theoretically portable, maybe. But C is actually portable in practice - you can compile C code for the vast majority of CPUs and OSs.

Devil’s advocate: compared to assembly, C is portable, but compared to a lot of high-level languages, C isn’t very portable.

Every “implementation defined” feature (https://en.wikipedia.org/wiki/Unspecified_behavior#Implement...) creates two different languages (examples are sizes of basic numeric types, signedness of the char type, and evaluation order of arguments)

Also, the standard library is so limited that, historically, you needed lots of stuff that wasn’t standardized between systems (https://en.wikipedia.org/wiki/GNU_Autotools: “It can be difficult to make a software program portable: the C compiler differs from system to system; certain library functions are missing on some systems; header files may have different names.”)

But yes, bringing up C on a system is a lot easier than doing the same for, to pick another extreme, Ada, but that’s because only half the job is done. Autotools does a bit of the rest, but still requires help from program writers.

Re: Rust is now overall faster than C in benchmarks

#247

Post by zucker42 »

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…

I don't think the value proposition of Rust over C#, Java, and Go is that it eliminates more errors. I think the advantage is it eliminates the same number of errors and performs better/has less overhead.

I agree with your post generally though.

Re: Rust is now overall faster than C in benchmarks

#248

Post by erik_seaberg »

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…

COM on Windows also promoted BSTR as a language-neutral type, which was a pointer to a null-terminated UTF-16 string (compatible with Win32 entry points, at least the Unicode versions) preceded in memory by its length.

Re: Rust is now overall faster than C in benchmarks

#250

Post by quotemstr »

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…

Right. As an industry, we need to get away from the simplistic "manual=fast" model. Logic does not automatically get faster when you write it in C or C++. It frequently gets slower, since your one-off "lean and mean" native code clumsily and slowly does the job that a managed runtime has been tuned for decades to do.
Post reply on HN