I was kinda stunned when i noticed the impact of changing this: d=sqrt(fx*fx+fy*fy+fz*fz); fx/=d; fy/=d; fz/=d; to this: d=sqrt(fx*fx+fy*fy+fz*fz); d2=1.0/d; fx*=d; fy*=d; fz*=d; Why don''t compilers optimise that? Are they still too stupid?

You probably meant:
d=sqrt(fx*fx+fy*fy+fz*fz);
d2=1.0/d;
fx*=d2;
fy*=d2;
fz*=d2;

But yeah thats kind of odd. What kind of performance changes are you getting and what compiler are you using?

Using a VC++ 6.0 compiler (maximize speed optimisation) i go from an average of 11.0 fps to about 12.3 fps (i am doing exactly the same, i call the code above 32768 times every frame). When i first noticed it i was calling the code 4096 times per frame so the improvement was much more (in fps), only not accurate as i calculate the fps every frame (and timeGetTime isn''t accurate).

Yes, i am doing a test with substance physics (hmm, fluids, but also nearly solids, so i just call it substances) and the positions of the points change every frame so the normals of the outside vertices change every frame too.

quote:I was kinda stunned when i noticed the impact of changing this:

d=sqrt(fx*fx+fy*fy+fz*fz);
fx/=d;
fy/=d;
fz/=d;

to this:

d=sqrt(fx*fx+fy*fy+fz*fz);
d2=1.0/d;
fx*=d;
fy*=d;
fz*=d;

Are you are saying that you are stunned that it is faster or that the compiler didn''t catch it and change it?

it is faster because * is much faster than /, (but I am sure you knew that, or else you wouldn''t have changed it )

I wondered the same thing too, until I started thinking about it for a while...

If the compiler made that change for you automatically, then it would bring up a whole slew of problems that would be a pain in the ass....

for example, what if you were working on a VERY tight memory budget (as in a console), and there were many hundreds of instances of x,y,z being worked on....

the compiler might automatically insert code to change the code into this

d=sqrt(fx*fx+fy*fy+fz*fz);d2=1.0/d;fx*=d2;fy*=d2;fz*=d2; 

but there is one little problem...,
what if adding that extra float made you use up too much memory!
you would indeed be using up more memory than was allotted for by the programmer... Especially if there were hundreds of instances of it...

that can be solved if the compiler uses d=1.0/d, but what if d is a member variable or a memory location that HAS to equal the true distance...then changing it in the compiler without the programmers knowledge is disastrous to the program....

ok, fine then...Perhaps we ignore the memory problem and stay with

d=sqrt(fx*fx+fy*fy+fz*fz);d2=1.0/d;fx*=d2;fy*=d2;fz*=d2; 

that is all well and good (except for the memory) except what should the compiler do if it sees this?

d=sqrt(fx*fx+fy*fy+fz*fz);fx/=d;fy/=d;fz/=d;gx*=d;gy*=d;                    ///1 divsion rougly equals 3 multiplicationsgz*=d;gx1*=d;gy1*=d;gz1*=d;gx2*=d;gy2*=d;gz2*=d;

both sets of instructions take about the same time,
(division/multiplcation clock cycle ratio from amd.com)
so the compliler really doesn''t have a good option for how to optimize here.....

however, there are some instruction sets (3Dnow!) that contain in their chip specifications that Divisions are actually supposed to be the register equivilant of inverse multiplication, so I dont really know... I guess I could be talking out of my ass... but at least I got you thinking about something!





--------------------------------------

It took me long enough, but now I am finally 16. Yay! Sorta funny, but I am probably the only person on earth who wrote a 3D driving game prior to actually driving .

Well, i read somewhere about a simple optimisation by changing this and i really didn''t know it so i really didn''t expect such a speed boost. Programming is just a hobby of mine so i got no lessons or anything in it, i have only got 1 beginners book on c++ programming and the rest i find out either accidentily or from the net if i need to know anything. So the fact i never knew that before isn''t that strange.
Anyway i agree that the compiler should not change logic for you.