Optimize typed coordinate conversion functions for faster Windows unsafe_get_submap_at performance

[akrieger]

Summary

Performance "Optimize typed coordinate conversion functions for widespread savings"

Purpose of change

I accidentally left a performance profiling run open for a couple hours. Interestingly, I noticed that what should be a basic math function, project_coord, was top of the list in self CPU at a shockingly high % of total cpu. This tickled my performance hotspot spidey sense so I went digging.

There's a variety of things going on but the basic point is the compiler was not inlining project_coord which by design is supposed to be inlined to take advantage of dead code stripping because the struct has more members than usually needed. This meant wasted computation in a very, very, hot code path.

The net win is map::ter is about 33% faster, map::furn is 25% faster, many other things called less often probably have similar wins. map::ter in particular is called in the render codepath so that makes everything just a bit snappier.

There were, unfortunately, no measurable wins with clang-cl. The generated code was identical (and fairly optimal) before/after my changes.

Describe the solution

• Force the compiler to inline the function with compiler specific annotations.
• Optimize the class hierarchy so that 'in bounds' points are a subclass of 'out of bounds' points (really, not-validated-in-bounds points). This allows for taking a const ob& from an ib point, a free operation, instead of a conversion/copy. In turn this allows directly returning the result of project_coord out of get_submap_unsafe
• Other tweaks to reduce the generated asm size, like taking points by value as arguments. Tripoints fit in an SSE register, and the compiler would not optimize some of these functions more without passing by value (a const ref can still be changed by the caller or through a called function, after all).

Describe alternatives you've considered

• Being happy with slow less optimized code.

Testing

Hacked up map_bounds_checking test to run 100 times in a loop. Instrumented it enough times to get 3 results within noise of each other, before & after.

I also hand expanded the template code into unsafe_get_submap_at to strip all the dead code manually and the generated assembly was functionally identical.

Additional context

There's nontrivial bulk added by two conditionals because at the bottom of the math stack are calls to divide_xy_round_to_minus_infinity. If we can get the inputs to be _ib points, then the math instead uses divide_xy_round_to_minus_infinity_non_negative which is branch free and reduces the asm from 54 lines to 35 lines and no conditional jumps. That's a longer term and harder effort though, and my immediate attempts to do this did not get any significant wins off the bat.