Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rust running with overflow-checks=false #430

Open
HFTrader opened this issue Mar 6, 2024 · 7 comments
Open

Rust running with overflow-checks=false #430

HFTrader opened this issue Mar 6, 2024 · 7 comments

Comments

@HFTrader
Copy link

HFTrader commented Mar 6, 2024

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

@HFTrader HFTrader changed the title Rust running with overflow-checks=true Rust running with overflow-checks=false Mar 6, 2024
@cyrusmsk
Copy link
Contributor

cyrusmsk commented Mar 7, 2024

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

@HFTrader
Copy link
Author

HFTrader commented Mar 7, 2024

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?

@cyrusmsk
Copy link
Contributor

cyrusmsk commented Mar 7, 2024

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.

@HFTrader
Copy link
Author

HFTrader commented Mar 8, 2024

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.

@cyrusmsk
Copy link
Contributor

cyrusmsk commented Mar 8, 2024

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"

@HFTrader
Copy link
Author

HFTrader commented Mar 8, 2024

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.

@cyrusmsk
Copy link
Contributor

cyrusmsk commented Mar 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants