hanabi1224
Rust running with overflow-checks=false
Running Rust, a language that prides on being "safe", with overflow-checks=false, which is inherently an unsafe feature, is not representative of what the language stands for.
Also some of the Rust benchmarks run with unsafe sections. That is misleading and should be removed. It's not because the language allows that it can be used. It would be equivalent to running C++ with inline optimized assembly language.
Still, on a AMD 3960x the nsieve 12 benchmark runs at 226ms(gcc) and 246ms(clang) for C++ and 472ms for Rust, even with overflow checks turned off. That is very different from what the benchmark shows. Both compiled exactly with the build options on bench/include/*.
I agree that Rust should implement bounds checking Also c++ code should be rewritten with “at” (safe indexing) and smart pointers. Then the comparison will be more interesting
Guarantees can be made at every level.
C++ relies on contract and context for safety as opposed to Rust. For example, when you sort a vector with std::sort(vec.begin(),vec.end()), that line guarantees that every access done in the underlying algorithm will be safe. You could mathematically prove that.
Rust philosophically makes contract guarantees null so they HAVE TO implement bounds checks at lower level. It is an important distinction.
Still, why there is such a gap between the performance numbers that I am seeing locally with virtually the same hardware (AMD EPYC) versus the results on this site?
I meant more computing algorithms, where operation “arr[i]” is very popular. And bounds checking is not happening for that. But std::vector provides safe operation “arr.at(i)” which should be used instead. But most of the code in C++ just does not care about that.
Why do you think arr.at(i) should be used instead? Imagine what happens when i is an invalid index - it will throw and who will catch? It's going straight to main, print an error and bails out. As a business, how is it better than a segfault to me? I'm losing speed and not having anything back of value.
Just to have a "fair" comparison. Otherwise everyone could switch-off bounds checking for speed.. And then we have all those bugs and CVE in large software.
Another point from the internet: "I prefer to use at(). The way our code is set up, we log from which module an exception was thrown, so by using at() it makes it easier/quicker to troubleshoot the silly bugs that we or QA tends to find in brand new modules and features"
I dont think this is fair. Rust provides security as an inherent feature, C++ does not. It is part of the language offering so fairness is to run the program as 99% of the users would run it. But it is your website. Again, why is that the numbers deviate so much between my machine and the numbers displayed in your website? It is like 100% difference.
So it is not mine benchmark) and I'm just regular participant who send several PRs Btw which tests have different numbers?
PS be aware that the author lost interest a bit, and many PRs stayed unprocessed and unmerged.