Optimized Rust is Still Slower Than Python+NumPy

I assume this is in response to https://news.ycombinator.com/item?id=35367520

[flagged]

Ah, the classic problem with benchmarking programming languages.

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.

I don't think it matters at the end of the day. Properly written numpy is very fast because it uses MKL or BLAS optimized for relevant architectures.

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.)

No surprise, because NumPy is implemented with Fortran which is designed to be efficient and fast at mathematical operations. Rust is not. And Python is not either, which is why it uses Fortran under the covers.

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:

https://www.matecdev.com/posts/numpy-julia-fortran.html