Hi, I'm discussing about Rust with my Computer Science professor, can anybody share with me a good performance comparision between C and Rust to show it to him?
Thanks.
1 Like
I googled "rust benchmark" and found this http://benchmarksgame.alioth.debian.org/u64q/rust.html
I heard that one is pretty bad because the way it's done and because it's focused in mature libraries and not the language itself.
It makes little sense to compare Rust vs C with respect to performance, because you can write the exact equivalent of C code in Rust and get the same performance (That's like comparing C vs C++ for performance). What you can compare is idiomatic Rust vs idiomatic C, and there Rust still has cases where it performs worse than C, but it also has cases where it outperforms C. These cases are eliminated one by one. As you can see here, There have been > 300 closed issues tagged with the slow label, and there are still around 60 open issues.
The cases where Rust outperforms C are those, where C needs to be conservative with optimizations, e.g. because it has two pointers through which it modifies memory, but doesn't know whether they point to the same object or to different objects. Rust on the other hand knows that it will never have two pointers to the same memory, and thus can optimize that case more aggressively.
11 Likes
We should also compare Rust with Fortran code 
1 Like
Oh, your right, thank you for the answer.
But, is true that Rust need more memory than C? Why? I heard that is something related with Jemalloc.
Regards.
Jemalloc is faster and more memory efficient afaik, but it will consume more memory initially, because it builds some database.
That said, you can replace the allocator with any allocator, even the system allocator which C often uses:
2 Likes
Here are two interesting comparisons of Rust vs C++
- Rust vs. C++: Fine-grained Performance -- this is a micro scale benchmark
-
[1505.07383] Experience Report: Developing the Servo Web Browser Engine using Rust -- this really is a paper about Servo, but it gives a feeling about
Rust vs C++for the huge code base.
4 Likes
Maybe what you heard is wrong?
Can you figure that out?
http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html
Forgive me but not mean to offend. I just try to compare opinions, at no time I say that is correct.
Regards.
No offence taken. Your Computer Science professor will probably expect you to explain whatever you show them.
1 Like
What you probably heard was that Rust builds bigger binaries by default because it statically links jemalloc into the binary. There's an overhead of something like 100kb for every binary because of this; this doesn't matter for most use cases, and you can dynamically link the system allocator instead if you need to.
igouy valiantly defends the benchmark game whenever it is discussed anywhere on the internet, but it is inherently limited in its relevance to comparing languages. It presents a comparison of what programmers can create in a language by micro-optimizing and tuning their source to solve that problem - it therefore compares the language's performance maxima, with a significant factor being that languages' users sum interest in providing tuned implementations for its problems. It is inverted from the normal situation: the resources to solve the problem exceed the problem requirements.
What the language game does not compare is the performance of two idiomatic codebases created in a more normal programming environment (with factors like shifting requirements, large code bases, growing technical debt, and insufficient resources for completing all requirements fully and properly). This seems like an impossible scenario to artificially reproduce and compare - instead we are left with comparing the known limitations of the language in order to estimate its performance. So we know that Rust has a comparable runtime to C and has access to an optimizer in the same class as C's optimizers. From this we can infer that the performance of idiomatic Rust should be of the same order as the performance of idiomatic C.
I really hesitate to post this, because I am not interested in 'debating' it as I have seen anyone who 'criticizes' this website inevitably have to do - but there it is. And this isn't even criticism - there is no actionable way I can see the benchmarks game could be more representative of language performance than it is. This is just inherently unrepresentable.
13 Likes
It is certainly true that I try to encourage people to read what is actually said on the website.
What is actually said on the website should give the impression that comparison between programming languages IS inherently limited.
Does the website mis-represent the comparison?
"Will your toy benchmark program be faster if you write it in a different programming language? It depends how you write it!
…
We want easy answers, but easy answers are often incomplete or wrong. You and I know, there's more we should understand…"
footnote:
Without "'debating' it" aren't we left with -- I'm right your wrong ?
[moderator note: let's not derail this thread any further into another pro/con of benchmarksgame, please.]
7 Likes
It's not even an "I'm right you're wrong" scenario--you two actually seem to be in agreement. You seem to be getting a bit defensive about points that, as you note, are already explicit on the website itself. So can we just say "yep, everyone agrees those are good considerations to keep in mind" and move on?
Perhaps we were all aware of that, perhaps not.
I thought that rustc stopped passing the noalias metadata to llvm due to some bugs. Without this I expect LLVM's reasoning of IR generated from both Rust and C to be very similar with respect to aliasing.
More info here. You're right, but my statement still holds. Rust can optimize more aggressively, and it might do so (again) in the future.
1 Like