If you occasionally inline all the functions and unroll all the loops, you can occasionally find optimizations that even the compiler won't be able to make. Fo

If you occasionally inline all the functions and unroll all the loops, you can occasionally find optimizations that even the compiler won't be able to make. For example, in quaternion-based rotation math, there exists a "sandwich product" where you take the (non-commutative) product of the transform and the input, followed by the product of that result and the conjugate of the transform. It turns out that several of the embedded multiplication terms cancel out in that double operation, and if you avoid calculating the canceled terms in the first place, you can do a "sandwich product" in about 60% the total floating-point operations as two consecutive product operations. In the application that used spatial transforms and rotations, the optimized quaternion functions were faster than the 4x4 matrix implementation, whereas the non-optimized quaternion functions were slightly slower. That change alone (adding an optimized sandwich product function) cut maybe 30 minutes off of our longest bulk data processing times. You would never be able to figure that out from this. out = ( rotation * in ) * ( ~rotation ); You have to inline all the operations to find the terms that cancel (or collapse into a scalar multiplication).