Carmack's Magic Hacks

[night_hawk]

I stumbled upon an interesting article regarding John Carmack's "black magic" hacks in the Quake 3 source. Some of these could be nicely inserted in Irrlicht. One of them is the sqrt function Carmack uses, which is waaaay faster than the default one, and the error is very small.

Here's the full article (with sourcecode).
http://www.codemaestro.com/reviews/9

It would be nice to see these enhancements in Irr.

[JP]

Irrlicht does have a reciprocal_squareroot function in include/irrMath.h which i imagine is an attempt at speeding things up like this. It does require IRRLICHT_FAST_MATH which doesn't seem to be defined in the standard release versions.

[rogerborg]

One of them is the sqrt function Carmack uses, which is waaaay faster than the default one

I calculate it as taking about 75% of the time as calling sqrt() on an Intel Core2 6700 using MS cl.exe 8.00 (VS 2005) in release mode on Windows. YMMV.

and the error is very small.

It does seem to be a small relative difference from the sqrt() result for the values that I've tested, although of course the absolute difference depends on the magnitude of the input.

For FLT_MAX, the difference in result (from my version of sqrt()) is 79164837199872.0000, for example.

It would be nice to see these enhancements in Irr.

A 33% increase in speed of one operation isn't necessarily an enhancement if you lose even a small amount of precision. It depends on the user.

Thanks, it's an interesting method.

[night_hawk]

It does seem to be a small relative difference from the sqrt() result for the values that I've tested, although of course the absolute difference depends on the magnitude of the input.

Indeed, but as stated in the article, you could add a few more iterations of Newton's Algorithm to get a more precise value.

As for the speed increase, apps that need lots of distances calculated would benefit quite a bit.

[rogerborg]

It does seem to be a small relative difference from the sqrt() result for the values that I've tested, although of course the absolute difference depends on the magnitude of the input.

Indeed, but as stated in the article, you could add a few more iterations of Newton's Algorithm to get a more precise value.

And slower execution. We're only talking a ~33% reduction to begin with.

As for the speed increase, apps that need lots of distances calculated would benefit quite a bit.

It depends on the definition of "lots" and "quite a bit". Apps that need accuracy with large values would get hosed (for various definitions of "accuracy", "large" and "hosed").

It looks like a good fit for IRRLICHT_FAST_MATH, but I don't find the speed increase compelling enough to recommend replacing all uses of sqrt() by default.

[night_hawk]

True that, true that.