Live data from Hacker News

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

291–300 of 445 posts

Re: Rust is now overall faster than C in benchmarks

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

One big advantage when writing average code is that while Rust emphasizes generics and makes them easy to write, C++ makes it so difficult that you try and avoid it at all costs. Big, complex projects are going to probably use polymorphism all over the place in my experience which is not really captured by benchmarks. However, one advantage for C and C++ for such projects is that they make it far more pleasant to do…

I don't agree with the first paragraph at all. C++ templates are more powerful than Rust generics, and also easier to write, because they are not inherently type-checked. In practice templates are embraced and used extensively, not "avoided at all costs" (like C++ exceptions.)

Re: Rust is now overall faster than C in benchmarks

#292

Earlier quoted context omitted.

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

> In my opinion, hash tables, btrees and the like in the standard library should probably swap to flat lists internally when the number of items in the collection is small. I'm surprised more libraries don't do that. If I recall correctly, the STL provides guarantees that prevents it from taking advantage of flat lists. I think some containers (not arrays) guarantee that they don't move the address of whatever they'r…

> Likewise, I believe I have heard of small string optimisation being impossible with std::string for similar reasons.

not impossible, SSO is implemented to some extent in most mainstream c++ compilers.

Re: Rust is now overall faster than C in benchmarks

#293

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…

> The answer is almost always more arrays and fewer pointers.

The number of people who dismiss the lowly array is way too high. Arrays are fast. Keep your data in the cache and they're 10x or more faster than normal, and plain flat arrays are almost always faster than literally any OOP nonsense. By "almost always" I mean that I've never once encountered a situation where flat arrays weren't the fastest solution attempted, and I haven't seen everything, so I can't claim they're always fastest.

People really don't understand how fast their computers really are, thanks to developers not caring how fast their code is.

Re: Rust is now overall faster than C in benchmarks

#294

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

That is from 1.1.0, which is quite old.

Re: Rust is now overall faster than C in benchmarks

#295
post #121

Earlier quoted context omitted.

When people use the unsafe keyword are they always taking into account aliasing? At least you can audit only those places though.

Rust takes const with pointers very seriously. It is undefined behavior to mutate anything non-mut (pointer or reference) unless it is through an UnsafeCell. While you can break compiler guarantees through pointers in Rust, dereferencing this pointers must still obey the above guarantee (basically think of it as you need to go back to references to actually use the aliased pointers which would be undefined due to the…

What you describe about 'const' is just about const correctness. That's important but different than aliasing.

For example consider Slice::swap [1]. This does consider the possibility that the pointers alias, and correctly, because they might point at the same object.

https://doc.rust-lang.org/src/core/slice/mod.rs.html#541-553

Re: Rust is now overall faster than C in benchmarks

#296
post #121

Earlier quoted context omitted.

When people use the unsafe keyword are they always taking into account aliasing? At least you can audit only those places though.

Yeah, `unsafe` is the developer signing a contract to uphold all the guarantees that safe rustc provided (at least from the perspective of the public interface, the invariants can be broken in private code). That's why Rust developers don't take kindly to unnecessary unsafe usage, because the audit surface area (and interaction complexity) increases.

But this is the crux. What sorts of aliasing are permitted in unsafe Rust? I think we kind of don't know; that's what the "stacked borrow" effort is trying to answer.

Re: Rust is now overall faster than C in benchmarks

#297

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

The CPU will load less cache data with linear searches. This is because you will have less cache misses. Less cache misses == less loading from memory. With pointer-heavy data structures, you load more from memory, and most of the stuff you do load is useless.

Re: Rust is now overall faster than C in benchmarks

#298

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?

A programming language idiom is a pattern or technique that you expect your readers to know, even if it isn't obvious when encountered for the first time. Here's an idiom:

    for (int i=0; i 
We all instantly know this means loop 10 times, from 0 through 9. But on first read it takes a little work to figure out what's happening.

Re: Rust is now overall faster than C in benchmarks

#299
post #125

Earlier quoted context omitted.

How often does benchmark code have a function that takes two pointers that could potentially alias each other? If it's as rare as I think it is, it might not have that much of an impact on Rust's position in the benchmarks game. Still, real world performance will probably benefit from this fix so it's a positive change regardless.

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…

Honestly, the biggest thing that attracts me to Rust is memory consumption. Most of my work is IO bound, usually on IO latency and not throughput, so the ability to pack more instances per container/vm/server/whatever would have a significant effect on my final bill per measurable unit.

Re: Rust is now overall faster than C in benchmarks

#300
post #89

Some of the rust versions calls C libraries for its heavy lifting (gmp, pcre) so I wouldn't take this too seriously.

When a Rust program is faster than the matching C program, it is utterly nonsensical to attribute its speed to C.

It is gratifying to see C++ identified, here, as the hands-down fastest implementation language, but odd to see Rust performance still compared, in the headline, to C, as if that were the goal. The headline should say that Rust speed is approaching C++ speed. In principle, Rust speed should someday exceed C++'s, in some cases, because it leaves behind some boat anchors C++ must retain for backward compatibility. In particular, if compiler optimizers could act on what they have been told about language semantics, they should be able to do optimizations they could not do on C++ code. As it is, Rust relies on optimizers coded for C and C++.

Rust may never reliably beat C++, because Rust has itself committed to details that interfere with optimization, principally in its standard library: The C++ Standard Library offers more knobs for tuning, while the Rust libraries are simpler to use.

Some of the reasons that C++ is so reliably faster than C are subtle and, to some, surprising. As noted elsewhere in this thread, the compiler knows more about what the language is doing, and can act on that knowledge, but C and C++ compilers share their optimizer, so that makes less difference than one might guess. Mainly, the C++ code does many things you might do in C, but in exactly one way that the optimizer can recognize easily.

The biggest reason why C++ is so much faster than C is that C++ can capture optimizations in libraries and reliably deliver those optimizations to library users. The result is that people who write C++ libraries pay a great deal of attention to performance because it pays, and that attention directly benefits all users of the library, including other libraries.

Because you can capture more semantics in C++ libraries, C++ programs naturally use better algorithms than C programs can. C programs much more frequently use pointer-chasing data structures because those are easier to put into a C library, or quicker to open-code, where the corresponding C++ program will use a library that has been hand-tuned for performance without giving up anything else.

Rust gets to claim many of the same benefits, because it is also more expressive than C, and Rust libraries are often as carefully tuned. Rust is not as expressive as C++, yet, and has many, many fewer people working to produce optimal libraries, but it is doing well with what it has.

Post reply on HN