   optimizing the square root
  I'm making a physics simulation that needs to normalize vectors a lot, for that I need to use the sqrt() many times each frame and it's really slowing me down.How can I get a faster square root?  I had some ideas:1) since I know that the longest distance will be 100 I could pre calculate all the whole numbers, and then for every real number I'd find the closest whole number and frim there use a taylor expansion or Newton-Raphson method to get the sqry of the real number.2) Nueral Net??Are any of the those good?  Are there faster (but also exact - euler integration is unstable enough without unaccurate roots) ways?Thanks.   
  Turn on compiler intrinsics and make sure you're set to compile for a recent processor. Enabling SSE instructions will help as well. If that doesn't do the trick, you may wish to look at vectorizing with SSE yourself, and doing 4 square roots at a time.It is unlikely you will be able to even come vaguely close in performance to an SSE square root using any other method anyway.   ;  You can also find partial precision sqrt() approximations, but they may not give you the precision you need for a physical simulation.http://www.google.com/search?q=sqrt+approximation;  If you know that most vectors will be *close* to 100.0f, then a taylor expansion around 100 would be a good way to go. I've also stumbled on the following fake-sqrt which seems to be working nicely. I haven't been able to derive where it comes from, though.float fy = fabsf(y);float fx = fabsf(x);float l =  (fy > fx) ? (fy + .336356f*fx) : (fx + .336356f*fy);   ;  Since you're normalizing vectors if you go the SSE route it looks like you're much better off computing reciprocal square roots and multiplying rather than square roots and dividing.  I don't claim to be any great expert on x86 assembler - I know enough to get around but I'm nowhere near Jan Wassenberg's level - but the Intel manual list the packed square root and divide instructions as having latencies and throughputs of ~40 each, whereas packed reciprocal square roots are listed with a latency of ~6 and throughput of ~4 and packed multiplies a latency of ~7 and a throughput  of ~2.  Latency is the number of clock cycles required for the instruction to execute and throughput is the number of clock cycles required before that instruction can be issued again on the same port.Σnigma   ;  Carmack has a very fast inverse square root approximation that you can find if you dig through the Quake3 source (I think it's in c_math.h).  It's an approximation but a very close one, we used this all over the place in our last project.   ;Here's a little article that shows the code for Carmack's sqrt and discusses it a bit.   ;  Thanks, at in the article there were the following lines:i = 0x5f375a86- (i>>1); // gives initial guess y0x = *(float*)&i; // convert bits back to floatWhat do they mean.and what is 0x5f375a86 in the decimal (mormal) system?Thanks.   ;  About that constant:Quote:Original post by daniel_i_lIt turns out that the magic constant 0x5f3759df is a real mystery. In the article "Fast Inverse Square Root" [2] , mathematician Chris Lomont of Purdue University researches the meaning of this magic constant. About x = *(float*)&i:&i is the address of i, a pointer to an int.(float*) casts that pointer to int to a pointer to float.This pointer is then dereferenced by the * and stored in the variable x.What this line of codes does is interpret the bits represented by i as a float. This is necessary because you cannot manipulate the bits in a float variable.The algorithm will not make much sense to you unless you know how floating point values are internally stored.;  Maybe this thread is of interest:http://www.gamedev.net/community/forums/topic.asp?topic_id=278849