5 ms·

I think it's quite impressive actually that someone can pick up Rust and manage to out-perform Numpy in their first project. BLAS implementations are decades-lo

I think it's quite impressive actually that someone can pick up Rust and manage to out-perform Numpy in their first project. BLAS implementations are decades-long exercises in optimization. In my own experience, Rust has been excellent for the more boring side of data science - churning through TBs of input data.

archgoon 7y ago
> I think it's quite impressive actually that someone can pick up Rust and manage to out-perform Numpy in their first project. They didn't. At the end of the article they discuss this. "In fact it’s worse than that. One of the exercises in the book is to rewrite the Python code to use vectorized matrix multiplication. In this approach the backpropagation for all of the samples in each mini-batch happens in a single set of vectorized matrix multiplication operations. This requires the ability to matrix multiplication between 3D and 2D arrays. Since each matrix multiplication operation happens using a larger amount of data than the non-vectorized case, OpenBLAS is able to more efficiently occupy CPU caches and registers, ultimately better using the available CPU resources on my laptop. The rewritten Python version ends up faster than the Rust version, again by a factor of two or so." The original python code was written to be easily understood; not performant. Shifting more of the work to the libraries improved the performance.
- mplanchard 7y ago
  That is a different algorithm, though, right? They didn’t rewrite the rust code to use matrix multiplication, so it’s no longer a direct comparison, and is instead comparing unoptimized rust with a less efficient algorithm to super optimized C++ with a more efficient algorithm (being called from python). In which case, IMO, it’s fairly surprising that the rust implementation is only 2x slower.
MiroF 7y ago
This is a common phenomenon (as anyone who has tried to rewrite the standard library buffer cache can tell you) - the reason is that these algorithms are oftentimes optimized to perform decently on the very very worst cases which means that they'll be slightly slower overall
- timClicks 7y ago
  Ah, that's a thought that I hadn't considered. Avoiding pathological worst case behavior does sound like a reasonable thing for a well-used library to do.

archgoon 7y ago

> I think it's quite impressive actually that someone can pick up Rust and manage to out-perform Numpy in their first project. They didn't. At the end of the article they discuss this. "In fact it’s worse than that. One of the exercises in the book is to rewrite the Python code to use vectorized matrix multiplication. In this approach the backpropagation for all of the samples in each mini-batch happens in a single set of vectorized matrix multiplication operations. This requires the ability to matrix multiplication between 3D and 2D arrays. Since each matrix multiplication operation happens using a larger amount of data than the non-vectorized case, OpenBLAS is able to more efficiently occupy CPU caches and registers, ultimately better using the available CPU resources on my laptop. The rewritten Python version ends up faster than the Rust version, again by a factor of two or so." The original python code was written to be easily understood; not performant. Shifting more of the work to the libraries improved the performance.

mplanchard 7y ago
That is a different algorithm, though, right? They didn’t rewrite the rust code to use matrix multiplication, so it’s no longer a direct comparison, and is instead comparing unoptimized rust with a less efficient algorithm to super optimized C++ with a more efficient algorithm (being called from python). In which case, IMO, it’s fairly surprising that the rust implementation is only 2x slower.

MiroF 7y ago

This is a common phenomenon (as anyone who has tried to rewrite the standard library buffer cache can tell you) - the reason is that these algorithms are oftentimes optimized to perform decently on the very very worst cases which means that they'll be slightly slower overall

timClicks 7y ago
Ah, that's a thought that I hadn't considered. Avoiding pathological worst case behavior does sound like a reasonable thing for a well-used library to do.