One example I know of is that when trying to calculate a dot product, you can improve the generated code and elide the bounds check only by a very particular syntax:
// Must slice to equal lengths, and then bounds checks are eliminated!
let len = cmp::min(xs.len(), ys.len());
let mut xs = &xs[..len];
let mut ys = &ys[..len];
let mut s = 0.;
for i in 0..xs.len() {
s += xs[i] * ys[i];
}
https://github.com/rustsim/nalgebra/blob/b1b18d17ee64d3fd28b...
assert_eq!(xs.len(), ys.len());
?At some point in history, when you wrote the straightforward, primitive three-nested-loops version of matrix multiplication your code ran much faster than when you tried to implement one of the more sophisticated algorithms.
That was because the Fortran compiler recognised the primitive version and replaced it with a special purpose highly optimized matrix multiplication. The compiler couldn't do that with the more sophisticated approaches.
> At some point in history, when you wrote the straightforward, primitive three-nested-loops version of matrix multiplication your code ran much faster than when you tried to implement one of the more sophisticated algorithms.
It might also have been due to Fortran using column-major matrix layout; if you try to implement a sophisticated multiplication algorithm that is optimised for row-major matrices, then that will be slower (indeed, also the row-major three-nested-loops version is already quite a bit slower). Another thing is that the sophisticated algorithms usually have some constant overhead that makes them shine only on sufficiently large matrices.