Re:A basic introduction to NumPy's einsum
by thrownawayalre on Saturday April 09, 2022 @07:50PM
(#30973253)
But BLAS is much more than 3 loops for matrix-matrix multiplication.
https://stackoverflow.com/questions/1303182/how-does-blas-ge...
Why turn your back on all the carefully crafted optimizations?
BLAS is great and must be used whenever possible. That was not my point.
I don't want to turn my back on the beautiful loop notation. For some algorithms, the loop notation is clearer than any "vectorized" version. It is absurd that the language penalizes you for that. Loops are alright.
I agree. At least some faster-cpython work is going on, does anyone know if there are aggregate updates on that, like performance progress reports?
Re:A basic introduction to NumPy's einsum
by upbeat_general on Saturday April 09, 2022 @09:09PM
(#30973604)
This is 100% not the case with SIMD.
Re:A basic introduction to NumPy's einsum
by dsharlet on Saturday April 09, 2022 @09:51PM
(#30973795)
Compilers can be pretty good if you help them out a bit. Here's my implementation of Einstein reductions (including summations) in C++, which generate pretty close to ideal code until you start getting into processor architecture specific optimizations: https://github.com/dsharlet/array#einstein-reductions
Re:A basic introduction to NumPy's einsum
by TheRealKing on Monday April 11, 2022 @12:37PM
(#30991269)
or Rust
The issue of "slow loops" is entirely self-inflicted by some languages. It's getting ridiculous to still worry about this shit in 2022.
Simple loops can and should be just as fast as vectorized programs. When they are slower, it is 100% due to deliberate decisions by the language dessigners