Vector normalization could easily be faster

[bvisness]

When digging into #80, I decided to see how GLM implemented vector normalization. Turns out their approach is pretty clever:

v * inversesqrt(dot(v, v));

This avoids both an actual square root and a division by exploiting the fact that inverse square roots are cheap and that dot(v, v) gives you the magnitude of the vector squared.

I ran some quickbench benchmarks with the following results:

No optimization

-O1

-O3

This is a pretty nice speedup for unoptimized builds (about 25%) and it could really help performance on processor architectures that hate square roots and divisions. (See concerns in #80.) So, we should probably do this.

[RandyGaul]

I would be a little worried about the error margins. Many times vectors are normalized in an attempt to ensure some kind of numeric drift does not occur. Personally I wouldn't like to see an inverse square root inside my math libraries, whether at work or in my personal codebase, at least not as the default option. In codebases where an "inverse sqrt option" for functions involving a sqrt are never used, and don't ever really justify their own existence.

It is sort of a neat concept to think about, but not really practical in my opinion.

[bvisness]

Given this library's focus on graphics math, and the fact that GLM actually uses this for vector normalization, do you think it's really that big a deal?

My normal advice would be to write your own normalize function, but of course changing how vectors are normalized has far-reaching implications for many other functions. We could do another #define (like #define HMM_NO_INVERSE_SQUARE_ROOT), but that adds a bit of complexity. At least to one place.

[RandyGaul]

For the things I would be normalizing, yes it would be a big deal. But, I'm not usually doing much rendering stuff.

It comes down to cost vs benefit. What are the costs, what are the benefits? Performance is just one way to measure costs and benefits. Numeric precision is another. Adding more complexity with a define to toggle inverse vs normal sqrts brings in abstraction cost.

It's really just my 2 cents. You run the repo, so feel free to ignore me :)

[IJzerbaard]

The inverse square root implementation (if used at all) should IMO definitely be _mm_rsqrt_ss/_mm_rsqrt_ps, which are built-in and fast.

[bvisness]

Randomly came back to this issue. Any objections to me implementing this as a FastNormalize function and leaving the existing normalize behavior the same?

[strangezakary]

Im cool with it, id just explain what the case should be used for like show the differences between the two

[bvisness]

Fast normalization has been added. Regular normalization has been left in place. If you look at the tests, you'll see that the precision is definitely worse, as you'd expect, so good call by @RandyGaul.

It's actually worth noting that we don't use a particularly fast inverse square root on non-SSE builds, so I've opened #95 to address this.

[bvisness]

Reopening for Handmade Math 2.0. I would rather make fast normalize the default and remove slow normalize. If inverse square root is good enough for GLM, it's good enough for us. Those who need more precision can make their own routine. (This decision will be documented, as with everything else in Handmade Math 2.0.)