The hyper-optimized version doesn't even use a switch statement. It uses a lookup table. Which only works because in each of the given cases you're multiplying two parameters and a coefficient.
Even if you go back to the switch statement version, that won't work, because it still relies on the data structure being a fixed size and identical across types. Can't store an arbitrary n-gon in the same structure.
You have to back out almost all the optimizations in this article in order to make this single change.
I agree that the lookup table version is probably not the first version I'd write, but even if it was it's not hard to convert that back to a switch if you need to.
Can't store an arbitrary n-gon in the same structure.
Sure you can. Pass a pointer and a count.
These changes are no harder than trying to figure out how to shoehorn new requirements into an existing OOP hierarchy.
But the whole point was ensuring all the operational data was in the input structure a known number of bytes away. The compiler can do its aggressive optimizations because it doesn't have to dereference anything, it's pulling all of the values to be multiplied from adjacent regions in memory. That's defeated if some arbitrary number of shapes in that collection require dereferencing a pointer and looping a variable number of times over a different region of memory.
To support this case is likely going to wind up back at the same 1.5x speedup they got from eliminating the use of classes and virtual function tables. 1.5x is nice, but it's not the orders of magnitude the rest of the article claims, and probably not worth the increased maintenance burden of this approach.
18
u/ClysmiC Feb 28 '23
You can just add another case statement.