RustAlgebloat

ut many times to you before. > Consider a matrix multiply, the most common operation in number-crunching Also an operation you won't be implementing manually if you actually care about performance (better implementation: call a BLAS library). And, any high performance implementation will be doing more than the naive triple-nested loop (blocking, SIMD, etc.). Focusing on this operation is somewhat missing the forest for the trees. > You're indexing through three 2D matrices along both axes. The indices are usually controlled by FOR statements, so the compiler knows the range the indices can take. Yes exactly, the compiler knows the range of the indices. > If the compiler knows about multidimensional arrays, it's easy to make those checks once at FOR loop entry. This is a non-sequitur: the compiler can still make/move the checks based on what the code looks like, without having to have a hardcoded concept of arrays. Ensuring optimisation passes are powerful enough to handle these sort of relatively straight-forward cases is more general than relying on a language-level concept of multidimensional arrays, as it allows them to apply to cases which can't quite be implemented with an array directly. > Although technically you could generate a special case This is exactly what compilers do, see the IRCE documentation. > The compiler can't optimize it that aggressively and fail early It certainly can: these sort of assertions shouldn't ever trigger, and with appropriate top level assertions (e.g. asserting that the dimensions of the incoming matrices work for multiplication) the compiler can easily see this. Also, the compiler can hoist assertions early if this cannot be observed externally, e.g. the loop kernel only mutates locals. > If all those optimizations really exist, why is there code like this (at https://github.com/SiegeLord/RustAlgebloat/blob/master/algeb...)? That code is almost 2 years old, and so the compiler will have improved since then. Of course, the compiler may not have improved enough (e.g. IRCE still may not be enabled). Additionally, there's a lot of uncertainity/lack of clarity (as demonstrated by your own comments) about exactly what the compiler can do, and so people may use `unsafe` unnecessarily. I've certainly been guilty of this myself, and been glad when people have pushed back in code-review, making me work a bit harder to get equal (or better) performance in safe code. [0]: http://llvm.org/docs/doxygen/html/InductiveRangeCheckElimina...

nt it becomes inevitable, rather than checking on every iteration and failing on iteration 1001. (Although technically you could generate a special case.) But that requires special treatment of "assert". In Rust, "assert!" is just a macro. The compiler can't optimize it that aggressively and fail early. Especially since you can now catch assertion failures during unwinding. If all those optimizations really exist, why is there code like this (at https://github.com/SiegeLord/RustAlgebloat/blob/master/algeb...)? MatrixMul<LHS, RHS> { unsafe fn raw_get(&self, r: usize, c: usize) -> f64 { let mut ret = 0.0; for z in 0..self.lhs.ncol() { ret += self.lhs.raw_get(r, z) * self.rhs.raw_get(z, c); } ret } } If what you say is true, all that unsafe stuff is unnecessary. [1] http://llvm.org/docs/Passes.html

atrix math. "Unsafe" all over the place, and unsafeness is exported, allowing the caller to do unsafe things. This is an example of why I occasionally stress the need for multidimensional array support at the language level. If the compiler knew about multidimensional arrays, it could optimize the subscript checks for them, avoiding code such as this. The unsafe version. The caller can store anywhere in memory. fn unsafe_set_idx(&self, $mat: &T, v: f64) { let $self_ = self; let (r, c) = $rc_expr; unsafe { $mat.raw_set(r, c, v) } } Safe, but inefficient version. The compiler can't hoist those checks out of loops. fn set_idx(&self, $mat: &T, v: f64) { let $self_ = self; let (r, c) = $rc_expr; assert!(r < $mat.nrow()); assert!(c < $mat.ncol()); unsafe { $mat.raw_set(r, c, v) } } This is the sort of thing that leads to exploits in code that reads things like JPEG files. Yet you can't do much better in Rust. That's why doing multidimensional arrays in macros and templates isn't good enough.