Did author knows about difference between static and dynamic dispatch? 🤦🏻♂️
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.
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.
I wonder if the compiler checks to see if the calls are pure and are therefore safe to run in parallel. It seems like the kind of thing the Rust compiler should be able to do.
If by parallel you mean across multiple threads in some map-reduce algorithm, the compiler will not do that automatically since that would be both extremely surprising behavior and in most cases, would make performance worse (it’d be interesting to see just how many shapes you’d need to iterate over before you start seeing performance benefits from map-reduce). If you’re referring to vectorization, then the Rust compiler does automatically do that in some cases, and I imagine it depends on how the area is calculated and whether the implementation can be inlined.
Do you mean this for loop?
for shape in &shapes { accum += shape.area(); }That does use an iterator
for-in-loops, or to be more precise, iterator loops, are a simple syntactic sugar over a common practice within Rust, which is to loop over anything that implements IntoIterator until the iterator returned by .into_iter() returns None (or the loop body uses break).
Anti Commercial AI thingy
I think they meant using for accumulating, like this:
shapes.iter().map(Shape::area).sum()Yes. That’s what I meant.
Though I heavily expect the rust compiler to produce identical assembly for both types of iteration.
Oh, I see. That would be interesting to benchmark too 👍
Anti Commercial AI thingy
No
struct Shapes([Shape; N]) impl Shapes { const fn area(&self) -> f64 { /* ... */ } }Bad article 🤨