3 ms·
> (disclaimer: I'm not a Rust or C++ developer!) You have not shown the Rust or C++ code, nor how you compiled it. Did you turn on optimizations? If you want
by steveklabnik 3y ago
> (disclaimer: I'm not a Rust or C++ developer!)
You have not shown the Rust or C++ code, nor how you compiled it. Did you turn on optimizations?
If you want to know why some code is performing the way that it is, you have to give folks a way to reproduce what you did. There is simply not enough information to answer your question.
- y42 3y agoI assumed it was not important, it's just two loops with a modulo operation, but you are right, I made one mistake for Rust: I implemented a progress bar. This was slowing down the process tremendously. A clean script now takes around 400 seconds, but still way more than the other solutions, see here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2e099a6c9bcb16f86f05b28f8ca87c02 https://play.rust-lang.org/?version=stable&mode=debug&editio...
- steveklabnik 3y agoYou linked to a playground that's in debug mode. If that's what you're measuring, you're absolutely going to be much slower. You need to compile with optimizations. Additionally, while I don't have the time to dig into the specifics of the assembly here, your Rust code doesn't do the exact same thing as the JavaScript code. valand's version is a more direct translation. While it appears you tried a few things to optimize the function in this Rust version, ..= can be a performance hazard in microbenchmarks like this. I have no idea if that's relevant, but it's a good example of why it's important to actually show your code, how you compiled and ran it, and how you tested it. But disregarding that, I still don't see how you're getting 400 seconds. You said you're testing up to 50,000 primes. In the playground that shows 0.02 seconds for me in debug, and 0.00 seconds in release.