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

261–270 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#261

Post by WalterBright »

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…

D uses slices for strings, which also gives D a big performance boost over C whenever strings are in play.

Re: Rust is now overall faster than C in benchmarks

#262

Post by RcouF1uZ4gsC »

wink wrote: post #231
blackrock wrote: post #228

Earlier quoted context omitted.

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.

The other thing that C++ and Rust have for collections and algorithms is that they follow a standard pattern.

Because of that, it is usually pretty easy to substitute an optimized algorithm or a container for another one with minimal code changes. In C, because there is no standard for how to do containers and algorithms, it is likely that every library does something a little different in terms of conventions making it harder to swap in implementations.

Re: Rust is now overall faster than C in benchmarks

#263

Post by burntsushi »

sitkack wrote: post #249
mh7 wrote: post #89

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

As soon as the libraries are RiiR, then the Rust compiler can optimize across those library calls.

That's not good enough. Rust already has a pure-Rust regex library. (I'm its author.) It is the only non-PCRE regex engine to appear in the first 20 results of the regex-redux benchmark. (The 21st I believe is currently RE2.) When using the regex crate, you would not materially benefit from optimizations across library calls, nor is it the difference maker here. Highly optimized regex engines depend more on internal inlining. Take a look at the object code for a program compiled with PCRE2 or the regex crate. You'll find huge functions internal to the regex library where inlining has been forced to reduce overhead. Those things are never going to be inlined across library boundaries.

Re: Rust is now overall faster than C in benchmarks

#264

Post by musicale »

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…

> real world C is a lot less performant than people think it might be

What is meant here? Fast? Reliable? Secure? Memory efficient? Power efficient? Easy to write? Easy to maintain? Quick to compile? Easy to debug?

I have no illusions about the reliability/security/correctness of real-world C code, especially since it's usually not compiled with a memory-safe compiler or run with memory-safe libraries and runtime environments (though it's often sandboxed to limit the damage.) It's relatively easy to introduce memory errors which are not detected by the compiler or runtime.

Certainly many algorithms and data structures (in C and other languages) exhibit tradeoffs including things like speed vs. memory use vs. code size vs. complexity, etc..

But C compilers are pretty fast, which I really like. Then there are/were environments like Turbo Pascal or Think C, which seem to have been amazingly compact while offering a rapid edit-compile-debug cycle as well as decent runtime speed and code size.

Re: Rust is now overall faster than C in benchmarks

#265

Post by sitkack »

burntsushi wrote: post #263
sitkack wrote: post #249

Earlier quoted context omitted.

As soon as the libraries are RiiR, then the Rust compiler can optimize across those library calls.

That's not good enough. Rust already has a pure-Rust regex library. (I'm its author.) It is the only non-PCRE regex engine to appear in the first 20 results of the regex-redux benchmark. (The 21st I believe is currently RE2.) When using the regex crate, you would not materially benefit from optimizations across library calls, nor is it the difference maker here. Highly optimized regex engines depend more on internal…

> Those things are never going to be inlined across library boundaries.

What prevents this?

I trust you on on this, but where is the remaining work? Language semantics, compiler, third choice?

Re: Rust is now overall faster than C in benchmarks

#266

Post by bluGill »

TheNewAndy wrote: post #148
ryanianian wrote: post #116

Earlier quoted context omitted.

Sure you can hard-code intcmp into qsort but then it would only work for arrays of ints. You could do some macro magic instead of templates e.g. `DEFINE_QSORT(int, intcmp)` which could stamp out `qsort_int` but that's not a part of the stdlib. C++ arguably gets this right since sort and sort will be separate functions, although templates are of course a footgun. And of course duping the logic for std::sort for a bunc…

The poster you are replying to didn't suggest hardcoding intcmp into qsort - just making it so the implmentation of qsort is available to the compiler when the comparison function is known (i.e. just like with C++). When this is done, the compiler can inline qsort, and replace the indirect function call with an inlined version of intcmp, and then things are equivalent.

Only if inlining qsort is best. Sometimes it is sometimes it isn't, based on complex rules that I trust the compiler to know.

Re: Rust is now overall faster than C in benchmarks

#267

Post by Hawxy »

littlestymaar wrote: post #195
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…

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

> for C#, at least last time I used it, which was 2011

Since then, C# added nullable reference types:

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

In projects with complete NRT coverage, it's extremely rare I ever get a null ref, as the compiler will warn/error me if I'm using a possibly null value in an unsafe way.

Re: Rust is now overall faster than C in benchmarks

#268

Post by burntsushi »

sitkack wrote: post #265
burntsushi wrote: post #263

Earlier quoted context omitted.

That's not good enough. Rust already has a pure-Rust regex library. (I'm its author.) It is the only non-PCRE regex engine to appear in the first 20 results of the regex-redux benchmark. (The 21st I believe is currently RE2.) When using the regex crate, you would not materially benefit from optimizations across library calls, nor is it the difference maker here. Highly optimized regex engines depend more on internal…

> Those things are never going to be inlined across library boundaries. What prevents this? I trust you on on this, but where is the remaining work? Language semantics, compiler, third choice?

It's prevented by good sense. The functions are likely multiple KB in size. Inlining them would seriously bloat the binary and would be unlikely to help due to how much work most regex engines do on each search.

The remaining work _on this particular benchmark_ is the regex algorithm itself. I'm on mobile so I can't do a deep dive, but I haven't yet figured out how to easily improve on this particular case. It has to do with the fact that the benchmark has a high match count and the finite automata approach in the regex crate has a bit higher overhead than the typical backtracking solution used in PCRE2 (which is also JIT'd in this case).

It's not the language, compiler, inlining or any other such thing. It's algorithms.

But this is one single benchmark. Before regex-redux there was regex-dna, and Rust's regex crate was #1 there. Why? Same reason. Algorithms.

You can't judge regex performance by a single benchmark. Two won't do it. Not even ten. It's one of the many problems with the Benchmark Game. This would be fine if everyone was circumspect and careful with their interpretation of the data provided, but they aren't. And the Benchmark Game doesn't really do much to alleviate this other than some perfunctory blurbs in some corners of the web site.

With that said, running a benchmark is hard work. It's easy to criticize.

Re: Rust is now overall faster than C in benchmarks

#269

Post by frutiger »

loup-vaillant wrote: post #255
josephg wrote: post #206

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…

Yes, the address of any element of an std::map is valid until that element is erased.

Re: Rust is now overall faster than C in benchmarks

#270

Post by jolux »

ghostwriter wrote: post #233
jolux wrote: post #214

Earlier quoted context omitted.

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

My impression was that its facilities for type- and memory-safe pointer usage were fairly sophisticated and unlike anything in more popular languages, which is what I was going off of. I must admit I haven't written any ATS, just done a cursory skim of the documentation and watched a Strange Loop talk a few years back.
Post reply on HN