Apples and oranges. How about Rust vs C++?
Rust is now overall faster than C in benchmarks
281–290 of 445 posts
Re: Rust is now overall faster than C in benchmarks
#282Yeah 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 l…
You'll be happy to know I implemented the n-body benchmarks game in zig 0.6.0 and it absolutely thrashed the rust version. Submitted it, but they don't take PLs not on the board currently.
Re: Rust is now overall faster than C in benchmarks
#283Yeah 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 l…
You'll be happy to know I implemented the n-body benchmarks game in zig 0.6.0 and it absolutely thrashed the rust version. Submitted it, but they don't take PLs not on the board currently.
But how much? Do you have an idea why?
Re: Rust is now overall faster than C in benchmarks
#284Once 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-... […
I doubt there's any performance to be gained that way, but if so, the C implementation can just use `restrict` to the same effect.
Sure, if you put the burden of proving correctness of restrict on the developer.
That's like saying C programmers could just write memory safe code if they felt like this would help, so clearly memory safety is not important.
Re: Rust is now overall faster than C in benchmarks
#285Earlier quoted context omitted.
The reason that C programs often perform well is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays. In many ways, modern CPUs are particularly designed to run the machine code generated by C compilers on typical C code like this. Pointers and memo…
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?
> I would’ve thought most commercial C programs would have heavily used linked lists, hashes (dictionary), and binary search trees all over the place.
Every large scale C code base I have worked on has had these things, and they were used as you say all over the place. If I were to encounter a code base that didn't have these things I would wonder why it was written in C in the first place.
Re: Rust is now overall faster than C in benchmarks
#286Earlier quoted context omitted.
n-body in C compiled by clang runs just as fast as Rust apparently: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
It's not entirely surprising that a carefully-optimized C program using explicit SSE intrinsics, plus a fancy trick involving a low-precision square root instruction fixed up with two iterations of Newton's method, would be fast. :-) What impresses me is that the Rust version didn't do any of that stuff, just wrote very boring, straightforward code -- and got the same speed anyway. Some impressive compilation there!
Someone wrote a 6 part of blog post [0] about porting that nbody benchmark from C to Rust. They went from a straight line by line port using unsafe rust using the same SSE based design to clean no-unsafe and no SSE rust code that was faster then the original C code with hand optimized SSE.
It is a great example of how the Rust compiler can auto-vectorize code.
Re: Rust is now overall faster than C in benchmarks
#287Earlier quoted context omitted.
It's not entirely surprising that a carefully-optimized C program using explicit SSE intrinsics, plus a fancy trick involving a low-precision square root instruction fixed up with two iterations of Newton's method, would be fast. :-) What impresses me is that the Rust version didn't do any of that stuff, just wrote very boring, straightforward code -- and got the same speed anyway. Some impressive compilation there!
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:
Re: Rust is now overall faster than C in benchmarks
#288Earlier quoted context omitted.
What makes you think arenas are considered unidiomatic in Rust? They’re there to be used when appropriate!
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.
Per object custom allocators are coming soon! I believe Vec already has an implementation on nightly.
Re: Rust is now overall faster than C in benchmarks
#289It’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.
Re: Rust is now overall faster than C in benchmarks
#290Earlier 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…
Maybe but there's reasons to doubt this. For starters, it's not obvious that Rust copies less. Sometimes you copy in Rust because it's easier than threading lifetimes throughout; sometimes you copy because you are defending against an imaginary threat (consider std::env::var or std::env::args).
One potentially important difference is integer indexes vs pointers. Compared to C, Rust uses int indexes less often within a function (iterators, not for loops) but more often between functions: in C you might store a pointer somewhere, while in Rust it's easier to store an index into a collection. But a ton of work has been poured into LLVM's induction variable analysis so this is swimming upstream.
The aliasing could be really important; there's a ton of pessimizations for e.g. uint8 pointers. Part of the maturing is fully specifying Rust's UB and aliasing model.