-
Notifications
You must be signed in to change notification settings - Fork 135
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
Comments
I agree that Rust should implement bounds checking |
Guarantees can be made at every level. |
I meant more computing algorithms, where operation “arr[i]” is very popular. And bounds checking is not happening for that. |
Why do you think |
Just to have a "fair" comparison. Otherwise everyone could switch-off bounds checking for speed.. Another point from the internet: |
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. |
So it is not mine benchmark) and I'm just regular participant who send several PRs PS be aware that the author lost interest a bit, and many PRs stayed unprocessed and unmerged. |
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/*
.The text was updated successfully, but these errors were encountered: