4 ms·

Part of the problem is that the multiply() function takes variable-size matrices as inputs and isn't inlined because it's declared as an external function and s

Part of the problem is that the multiply() function takes variable-size matrices as inputs and isn't inlined because it's declared as an external function and so could, in theory, be called from another compilation unit. If it's declared as "static" instead then the compiler generates identical code (modulo register selection) at -Ofast for both versions—eliminating the bounds checking at compile-time: https://gcc.godbolt.org/z/qqWr1xjT8 https://gcc.godbolt.org/z/qqWr1xjT8

jcelerier 5y ago
> Part of the problem is that the multiply() function takes variable-size matrices as inputs so does real-life code ? I don't know about you but I pretty much never know the size of my data at compile time. > If it's declared as "static" again, real-life code calls math operations defined in other libraries, sometimes even proprietary.
- titzer 5y ago
  In Java or other languages with bounds-checked arrays, you would typically just loop from 0 to the end of the array. In Java the JIT will analyze the loop, see that it is bounded by the length of the array, conclude all accesses are in-bounds and eliminate bounds checks. Virgil does this simple type of bounds check elimination as well in its static compiler, but its analysis is not quite as sophisticated as Java JITs.
- nybble41 5y ago
  > I don't know about you but I pretty much never know the size of my data at compile time. Whole-program optimization (LTO) can deal with that. Also, Rust inlines across modules much more aggressively than C++ does, even without LTO, so optimization will be more effective and its bounds-checking won't have as much (if any) runtime overhead. Especially if you write your Rust code idiomatically, as others have already suggested. Your earlier Rust example was practically designed to inhibit any attempt at optimization. Simply iterating over a slice of the vector, rather than the indices, results in a much tighter inner loop as it only needs to check the bounds once. That being said, in this case I think it would be better to have fixed-size matrices (using const generic/template arguments) so that the bounds are encoded in the types and known to the compiler locally without relying on whole-program optimization.
  - stouset 5y ago
    > Especially if you write your Rust code idiomatically, as others have already suggested. Your earlier Rust example was practically designed to inhibit any attempt at optimization. This is pretty much word-for-word what I've seen in other similar disagreements. Rust Skeptic transcribes their solution from its original programming language into Rust line by line, producing something nobody using Rust would actually write. They find that Rust performs poorly. Rust Proponent writes it the way you'd expect someone who actually knows Rust to write it, and performance meets or exceeds the original. Sometimes they even catch a few bugs. Yes, if you don't know Rust, and you think it's just a weird re-skin of C++ that can be gsub'd from one to another, you're going to have a bad time. If you're an expert in C++ and have never written Rust, you probably aren't going to beat your finely-tuned C++ program with a ten minute Rust translation. But someone with a year of experience in Rust is probably going to be able to rewrite it in half an hour and come within spitting distance of the thing you've optimized by hand over the course of a few years. I've written Rust for half a decade and I'm not sure I've ever actually explicitly indexed into a Vec or slice in production code. If I needed to, and it was in a hot loop, and it wasn't a fixed-size array whose size is known at compile time... there's always `get_unchecked()` which is functionally identical to indexing into a C++ vec without `at`.
    - jcelerier 5y ago
      > Yes, if you don't know Rust, and you think it's just a weird re-skin of C++ that can be gsub'd from one to another, you're going to have a bad time. most C++ code is not "idiomatic C++" either, it's code which looks like this: https://github.com/cdemel/OpenCV/blob/master/modules/calib3d/src/epnp.cpp#L49 https://github.com/cdemel/OpenCV/blob/master/modules/calib3d... or this https://github.com/madronalabs/madronalib/blob/master/source/matrix/MLMatrix.cpp#L769 https://github.com/madronalabs/madronalib/blob/master/source... or this https://github.com/MTG/essentia/blob/master/src/3rdparty/spline/splineutil.cpp#L1925 https://github.com/MTG/essentia/blob/master/src/3rdparty/spl... etc ... which is in general code from science papers written in pseudocode which is ported at 2AM by tired astrophysics or DSP masters students to have something to show to their advisor. You can have whatever abstraction you want but they won't be used because the point is not to write rust or C++ or anything but to get some pseudo-MATLABish thing to run ASAP, and that won't have anything that looks like range / span, only arrays being indexed raw.

jcelerier 5y ago

> Part of the problem is that the multiply() function takes variable-size matrices as inputs so does real-life code ? I don't know about you but I pretty much never know the size of my data at compile time. > If it's declared as "static" again, real-life code calls math operations defined in other libraries, sometimes even proprietary.

titzer 5y ago
In Java or other languages with bounds-checked arrays, you would typically just loop from 0 to the end of the array. In Java the JIT will analyze the loop, see that it is bounded by the length of the array, conclude all accesses are in-bounds and eliminate bounds checks. Virgil does this simple type of bounds check elimination as well in its static compiler, but its analysis is not quite as sophisticated as Java JITs.
nybble41 5y ago
> I don't know about you but I pretty much never know the size of my data at compile time. Whole-program optimization (LTO) can deal with that. Also, Rust inlines across modules much more aggressively than C++ does, even without LTO, so optimization will be more effective and its bounds-checking won't have as much (if any) runtime overhead. Especially if you write your Rust code idiomatically, as others have already suggested. Your earlier Rust example was practically designed to inhibit any attempt at optimization. Simply iterating over a slice of the vector, rather than the indices, results in a much tighter inner loop as it only needs to check the bounds once. That being said, in this case I think it would be better to have fixed-size matrices (using const generic/template arguments) so that the bounds are encoded in the types and known to the compiler locally without relying on whole-program optimization.
- stouset 5y ago
  > Especially if you write your Rust code idiomatically, as others have already suggested. Your earlier Rust example was practically designed to inhibit any attempt at optimization. This is pretty much word-for-word what I've seen in other similar disagreements. Rust Skeptic transcribes their solution from its original programming language into Rust line by line, producing something nobody using Rust would actually write. They find that Rust performs poorly. Rust Proponent writes it the way you'd expect someone who actually knows Rust to write it, and performance meets or exceeds the original. Sometimes they even catch a few bugs. Yes, if you don't know Rust, and you think it's just a weird re-skin of C++ that can be gsub'd from one to another, you're going to have a bad time. If you're an expert in C++ and have never written Rust, you probably aren't going to beat your finely-tuned C++ program with a ten minute Rust translation. But someone with a year of experience in Rust is probably going to be able to rewrite it in half an hour and come within spitting distance of the thing you've optimized by hand over the course of a few years. I've written Rust for half a decade and I'm not sure I've ever actually explicitly indexed into a Vec or slice in production code. If I needed to, and it was in a hot loop, and it wasn't a fixed-size array whose size is known at compile time... there's always `get_unchecked()` which is functionally identical to indexing into a C++ vec without `at`.
  - jcelerier 5y ago
    > Yes, if you don't know Rust, and you think it's just a weird re-skin of C++ that can be gsub'd from one to another, you're going to have a bad time. most C++ code is not "idiomatic C++" either, it's code which looks like this: https://github.com/cdemel/OpenCV/blob/master/modules/calib3d/src/epnp.cpp#L49 https://github.com/cdemel/OpenCV/blob/master/modules/calib3d... or this https://github.com/madronalabs/madronalib/blob/master/source/matrix/MLMatrix.cpp#L769 https://github.com/madronalabs/madronalib/blob/master/source... or this https://github.com/MTG/essentia/blob/master/src/3rdparty/spline/splineutil.cpp#L1925 https://github.com/MTG/essentia/blob/master/src/3rdparty/spl... etc ... which is in general code from science papers written in pseudocode which is ported at 2AM by tired astrophysics or DSP masters students to have something to show to their advisor. You can have whatever abstraction you want but they won't be used because the point is not to write rust or C++ or anything but to get some pseudo-MATLABish thing to run ASAP, and that won't have anything that looks like range / span, only arrays being indexed raw.