Optimized Rust is Still Slower Than Python+NumPy
github.com
github.com
There may be further optimizations you can do to the Rust code, likewise for Python. I do find it a bit hilarious we are "comparing" Python and Rust because really what this "comparison" lets us conclude is "FFI-ing into a mature Fortran library happens to give faster numerical perf than some Rust solution that is naive in comparison."
Let's see how Rust performs with its own FFI into LAPACK and BLAS. Better yet, since I know people will immediately complain Rust isn't a scripting language, let's try to compare something Lua + Torch against Python + PyTorch. This would be much more "apples-to-apples" than whatever OP is doing at the moment.
It won't be worth your while optimizing it unless you need to do something that steps outside the bounds of what numpy can easily do (parallel code, lots of small function calls, etc.)
I wouldn't be surprised to see Rust numerical libraries created similar to NumPy which also use Fortran, for the same reasons.
If you want a real comparison, try NumPy vs Julia:
Rust called into from Python showed a 100x improvement over the "done wrong" code: https://ohadravid.github.io/posts/2023-03-rusty-python/
So Python+NumPy is significantly slower than Python+Rust. And that's without doing any SIMD in the Rust code, though it's possible the compiler autounrolls and then autovectorizes the loop.
There is a post today demonstrated that rewriting Python Code in Rust got 100X speed up.
https://news.ycombinator.com/item?id=35367520
(credit to EwanToo, who gave the link first)
Also the original author claimed that Numpy is not worth the effort because it is significantly slower.
So here is the demonstration of a piece of Numpy code, with 350X speed up over the original code.
tldr:
original Python: 1X
original Numpy: 7X
original Rust: 100X
new Numpy: 350X