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 be determined are far more common than exceptional. This happens because null terminated strings feel like idiomatic C to most people.<p>Rust avoids those from the start by making slices idiomatic.<p>Another thing I commonly see is the usage of suboptimal containers (like arrays with linear search) - just because it’s there’s no better alternative at hand (standard library doesn’t offer ones and dependency management is messy). Which also makes it less surprising that code in higher level languages might perform better.
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 <i>much</i> more about which pointers do/do-not alias than most other programming languages [2] and the myriad optimizations this knowledge allows.<p>[1] <a href="https://github.com/rust-lang/rust/issues/54878#issuecomment-429578187" rel="nofollow">https://github.com/rust-lang/rust/issues/54878#issuecomment-...</a><p>[2] <a href="https://doc.rust-lang.org/nomicon/aliasing.html" rel="nofollow">https://doc.rust-lang.org/nomicon/aliasing.html</a>
Looking at the <i>reverse-complement</i> code, it appears that the Rust and C implementations are using different algorithms:<p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/revcomp-rust-1.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a><p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/revcomp-gcc-6.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a><p>On a quick inspection:<p>- The Rust code is about twice as long.<p>- The Rust code has CPU feature detection and SSE intrinsics, while the C code is more idiomatic.<p>- The lookup table is larger in the Rust code.
The fastest n-body program is written in very idiomatic rust. <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-rust-8.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
From the page: "… a pretty solid study on the boredom of performance-oriented software engineers grouped by programming language."
I find this both funny and consider it true to some degree. There's nothing like a good old friendly arms race for the benefit of all (languages and its users, in this case) involved!
I was wondering if perhaps this was actually measuring a difference between LLVM and GCC, but they also provide a set of benchmarks of C Clang vs C GCC (1) and Clang is generally slower in those test. Although there is some correlation between the ones Clang wins in C And Rust.<p>1. <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/c.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
Which is not at all surprising. Rust has much larger compilation unit and knows more about what can read/write a particular piece of memory. This allows some occasions for optimization where C compiler must be conservative.<p>An example of simpler version of this is Fortran that can be faster for numerical loads due to the fact that Fortran disallows aliasing of function arguments. C on the other hand, must pay the price of having to be conservative with how it treats arguments just in case they overlap.
Yeah I can understand why. Though I still prefer C in some ways simply because of its minimalism in the language, while still allowing for the kinds of things you want to be able to do if you wanna push your code to the limits. It is a bit scary sometimes writing in C though and sometimes I get a bit annoyed at how some things work or not work in it. I personally am hoping Zig can soon fill this minimalism trait in langs for me. C will probably always be the standard though and I do think more programmers should learn C better to become better programmers.<p>Rust is a good lang though. I am glad something else is pushing up there for the top spots. And more competition in performance is a good thing.<p>You don't always have to pick your sides. I just want to be able to write good code and be happy writing it :)
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.
I'm having a hard time making sense of this page. Why is this comparing fastest implementation with slowest implementation? Why is the metric busy time/least busy? Why is C++ so much better than C?
An unrelated rant about benchmarksgame. Has anyone noticed that the Python implementation of regex beats a lot of the Rust and C implementations? That’s because it uses the PCRE2 library (written in C) which it assumes is installed on the OS. Benchmarks are always artificial but this seems like a step too far: the benchmark hardly says anything about Python and is dependent on the OS environment having the right dependences.<p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-python3-2.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
Let's talk about speed when we are implementing the same algorithm and optimizations, please. If $1 was donated to cure cancer every time a developer games a comparison like this, there would be no more cancer.
Rust seems to be using parallelism better. In one benchmark though (fasta), C gcc is using all 4 cpus and Rust only two, and still wins.<p>(Looking at just C gcc vs Rust) <a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gcc-rust.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a>
Nodejs is incredible fast for a interpreted language. It is only ~4 times slower than Rust and only a bit slower than Go or Java (compiled GC languages) in the benchmarks. Compare that with Python 3, also interpreted but ~30 times slower than Rust.<p>I know that Python 3 can do some runtime stuff that Nodejs can't, but I wonder whether that's worth so much performance. Maybe if the answer is that you would include C modules in Python if you need the speed, but I don't know if that's a good answer to the problem.
One of Rust's performance advantages is the compiler's ability to unambiguously determine memory aliasing. Aliasing is why many numeric kernels are written in Fortran, a much older language that also enforces strict aliasing as it simply doesn't allow overlapping references.<p>There are probably others as well, but this is the advantage I'm familiar with. C's ambiguity makes it harder to achieve some optimizations that can really matter on modern CPUs.
The reasons I use C versus comparable alternatives are not limited to speed. For example, the size of the compiler toolchain, the speed of compilation and the size of the resulting executables are all factors I have to consider. I do lots of work on systems with limited resources. How does Rust compare on those points versus, say, GCC.<p><a href="https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna" rel="nofollow">https://dev.to/aakatev/executable-size-rust-go-c-and-c-1bna</a>
It’s all depends on developer. I have talent to write really bad code in any language and make code as slow as I want. I can write code in ruby that would outperform code in C. The benchmarks like this don’t give you full picture of language possibilities. On top of everything we also need account for compilers and compiler optimization.
Nothing against rust. I write ton of code using rust, and advocating at my work. But this looks like a PR move to me.
Is it just me or has that 'benchmarks game' site been growing less navigable over time? It use to be easy to compare benchmarks across several languages. If that capability still exists somewhere it's buried and I'm not interested in puzzling it out. There are no side bars or menus or anything helpful.
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.<p>If Rust implementation is father than C's, kudos goes to the compiler, not to the language
Wondering around the site I found this particular benchmark interesting<p><a href="https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html" rel="nofollow">https://benchmarksgame-team.pages.debian.net/benchmarksgame/...</a><p>Why is julia using 250x the memory? (and it`s still fast)
Was the Formula One pilot Schumacher as good as he is just because of his Ferrari? Obviously not, but he probably wouldn't have performed as well with a Ford Focus.<p>If you are willing to spend the time to perform at the highest level, Rust can bring you there.
It struck me a while ago that the most powerful feature of rust is the strong contracts libraries can and must express. This allows people with much deeper knowledge than me to make awesome stuff I can depend on.
How do I downvote a thread in HN, I can just upvote it?<p>Also is there also a way to filter out posts with the word "Rust" in it so I don't see them?
Because Rust does alloca for all locals, and this if course faster. Everyone else avoids it for security reasons. Just search the Rust bugtracker for stack overflows.
I know it's a meme, but it really does seem like most C or C++ code would be better off transitioning to Rust at some point. That includes the entire Linux kernel, web browsers, entire OS's...
I think benchmarking C vs C++ vs Rust must only really be useful for researchers. They’re all making a similar tradeoff for performance: forcing you to consider how you use memory. Does anyone work in a field where the performance difference between these specific three platforms matters? I’m genuinely curious. Edit: also, if you could explain briefly why and what makes particular choices out of the three unsuitable, that would be awesome too.