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

341–350 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#341

Post by bicolao »

pbadenski wrote: post #329
scottlamb wrote: post #220

Earlier quoted context omitted.

Conversely, more sophisticated algorithms, and particularly monomorphization, may bloat the code size, causing icache, L2/L3 cache, and TLB misses. (Also slows compilation.) I think this is under-appreciated because it doesn't show in microbenchmarks. (I wish I knew of an easy way to measure how much cache pressure you're causing from a microbenchmark.) I suspect for this reason it'd be better in Rust to use a Go-lik…

Thank you for mentioning monomorphization - I wasn't aware of this concept. Would you maybe if there's any source discussing how this is solved in different languages and performance consequences of it?

Not really answering your questions, but regarding monomorphization, you can see a comparison of code size and compilation speed between printf, std::format and C++ iostream. The last one is monomophization, I believe.

https://github.com/fmtlib/fmt#compile-time-and-code-bloat

Re: Rust is now overall faster than C in benchmarks

#342

Post by jcelerier »

zeroimpl wrote: post #156
sli wrote: post #115

Earlier quoted context omitted.

I admit I'm destroying the metaphor here but there are a lot of useful comparisons to be made between different cultivars of apple and those comparisons have implications on their applications.

That's the whole point of the metaphor - comparing apples to apples is good, apples to oranges is bad.

I'm comparing apples to oranges every time I'm trying to decide which fruit to buy at the supermarket though.

Re: Rust is now overall faster than C in benchmarks

#343

Post by jcelerier »

neopallium wrote: post #287
FartyMcFarter wrote: post #124

Earlier quoted context omitted.

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

The Rust compiler can auto-vectorize loop code. This blog post shows how to write simple idiomatic Rust code that will allow the compiler to auto-vectorize: http://cliffle.com/p/dangerust/6/

But, C and C++ compilers also can autovectorize quite well. I had some SSE & AVX algorithms where the compiler ended up doing the same or lightly better job in C++ for instance.

So maybe it's just the C benchmark being a cargo cult.

Re: Rust is now overall faster than C in benchmarks

#344

Post by jcelerier »

pjmlp wrote: post #176
jandrewrogers wrote: post #99

Earlier quoted context omitted.

While nothing prevents you from writing C that will generate the equivalent code, it requires several times more lines of C than the equivalent C++. At which point, it becomes an economics discussion. C is usually a choice when pure performance is secondary to other considerations like portability. Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance h…

Just a small, correction, you mean 90's style C++ GUI frameworks inheritance are no longer idiomatic in modern C++. Naturally we have to ignore that wxWidgets, Gtkmm, MFC, ATL, Qt, COM, DirectX, IO Kit, DriverKit, Skia are still around.

> you mean 90's style C++ GUI frameworks inheritance are no longer idiomatic in modern C++

I mean, as much of a Qt user I am, that's definitely the case. All the libs you listed are still around, but no one writes new libraries in that style (sometimes at a performance cost, e.g. using a ton of std:: function instead of virtuals)

Re: Rust is now overall faster than C in benchmarks

#345

Post by Tade0 »

wuxb wrote: post #321

Just took a quick peek at the binary-trees C code. Why using openmp while the others don't? why use recursive functions? The C implementation is not correctly optimized. People just paid more attention to Rust and other languages. Rust can be as fast as C, but "faster" is really misleading. BTW, I use clang all the time since it's better than GCC.

It seems that someone simply tacked openmp on without checking if it actually increases performance in this case - which is unusual, because I remember a course in college, part of which was a project aiming to teach the student that openmp is not a silver bullet and should be used only when it actually helps.

Re: Rust is now overall faster than C in benchmarks

#346

Post by Narishma »

madacol wrote: post #225
vitus wrote: post #76

Earlier quoted context omitted.

I recall an anecdote about how Haskell actually outperformed C on various tree benchmarks because it was using a better implementation. At some point, the C programmers got fed up with the airs of superiority from Haskell programmers, ported the Haskell implementation, and reclaimed their position. I wouldn't be surprised if there's something similar happening here.

Looked at the git repo https://salsa.debian.org/benchmarksgame-team/benchmarksgame and it seems there's only one committer. So if all scripts are written by the same guy, then his biases are all over the place, and it needs more code diversity before we can arrive to any conclusion. Am I missing something?, is there a list somewhere of the people who have contributed to this?

Click on any of the benchmark programs and it will have the contributors' names at the beginning.

Re: Rust is now overall faster than C in benchmarks

#347

Post by fnord123 »

millstone wrote: post #291
slaymaker1907 wrote: post #166

Earlier quoted context omitted.

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

>C++ templates are more powerful than Rust generics, and also easier to write

They are definitely not easier to write. The last time I checked, the error reporting were still so intractable that would be hard to take this argument in good faith. Maybe it improved?

>In practice templates are embraced and used extensively, not "avoided at all costs" (like C++ exceptions.)

I think many would agree that this is largely because the package management system for C++ is so awful that header-only libraries are popular since you just need to copy paste a single file into your project.

C++ is a large language and there are some wildly different coding standards. Some do avoid templates (but you're right that GP overstated this). Why? Templates introduce a lot of code bloat because there is little opportunity for eliding copies of the same code at link time. Aside from bloating the global offset table in position independent executables (if the GOT doesn't fit in cache, perf drops), the compile time hit is also a non trivial issue. But this is a really exceptional scenario where you are shaving the monolith and need to get the ELF executable down (e.g. server side ball-of-mud, small embedded systems).

Re: Rust is now overall faster than C in benchmarks

#348

Post by volta87 »

nindalf wrote: post #110
Svetlitski wrote: post #49

Once LLVM fixes some bugs with `noalias`, at which point Rust will begin using it again in more circumstances [1], I'd expect to see Rust get even faster in these benchmarks, given that the Rust compiler knows much more about which pointers do/do-not alias than most other programming languages [2] and the myriad optimizations this knowledge allows. [1] https://github.com/rust-lang/rust/issues/54878#issuecomment-... […

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.

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

Most C++ STL algorithms take iterators, that in many cases are just pointers in benchmarks because these often only deal with arrays. Hell most C standard APIs (e.g. memcpy) take multiple pointers.

Re: Rust is now overall faster than C in benchmarks

#349

Post by volta87 »

tick_tock_tick wrote: post #319
arcticbull wrote: post #42

Earlier quoted context omitted.

Rust can be faster than C because in general C compilers have to assume that pointers to memory locations can overlap (unless you mark them __restrict). Rust forbids aliasing pointers. This opens up a whole world of optimizations in the Rust compiler. Broadly speaking this is why Rust can genuinely be faster than C. Same is true in FORTRAN, for what it's worth.

In theory one day Rust will but LLVM doesn't support anything beyond the function level for noalias since that's all that's needed to support __restrict in C. Even that isn't used by Rust most of the time since they have found several bugs in it.

LLVM does support tbaa! and noalias! metadata.

Re: Rust is now overall faster than C in benchmarks

#350

Post by aliceryhl »

millstone wrote: post #295
slaymaker1907 wrote: post #188

Earlier quoted context omitted.

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

Thanks for posting that link. I found the following issue because of it: https://github.com/rust-lang/rust/issues/80682
Post reply on HN