It would be interesting to see if an iterator instead of a manual for loop would increase the performance of the base case.

My guess is not, because the compiler should know they are equivalent, but would be interesting to check anyway.

for shape in &shapes {
  accum += shape.area();
}

shapes.iter().map(Shape::area).sum()

#!/usr/bin/env bash
sleep 0.5
xte "str ::: spoiler Anti Commercial AI thingy"
xte "key Return"
xte "str [CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/)"
xte "key Return"
xte "str :::"

No

struct Shapes<const N: usize>([Shape; N])

impl<const N: usize> Shapes<N> {
 const fn area(&self) -> f64 { /* ... */ }
}

Bad article 🤨

Correct me if I am wrong but isn’t “loop unrolling/unwinding” something that the c++ and rust compilers do? Why does the loop here not get unwound?

Casey’s video is interesting, but his example is framed as moving from 35 cycles/object to 24 cycles/object being a 1.5x speedup.

Another way to look at this is, it’s a 12-cycle speedup per object.

If you’re writing a shader or a physics sim this is a massive difference.

If you’re building typical business software, it isn’t; that 10,000-line monster method does crop up, and it’s a maintenance disaster.

I think extracting “clean code principles lead to a 50% cost increase” is a message that needs taking with a degree of context.

I agree with the conclusion, and the exploration is interesting enough that I think it was worth sharing. Still, while the author seemingly knows this already based on their conclusion, it’s still worth stressing: these kinds of microbenchmarks rarely reflect real world performance.

This toy case doesn’t have many (if any) real world performance-sensitive applications. At best, using shapes in games comes to mind, but shapes there are often represented as meshes, and if you really need the area that much, you might find that precalculating the area once is more impactful on the performance than optimizing how fast the area is calculated.

Still, the author seems aware, and it seems to just be the author sharing their fun experiment.

Did author knows about difference between static and dynamic dispatch? 🤦🏻‍♂️

So the problem discovered is that the compiler can’t optimize the loops by unrolling them (due to floating point issues?). The proposed solution is to unroll the loop manually.

But wouldn’t it be much cleaner and more performant to just have a macro like #![allow lossy floating point optimizations] and let the compiler figure out the rest?

Compilers exist to compile and optimize things. Manually unrolling loops might improve performance on one machine, but completely break the program on another. It’s much safer and more performant in the long term to allow the compiler the leeway to optimize things the optimal way.