Archived

This topic is now archived and is closed to further replies.

Speed issue for inlined MyVec.Normalize()

This topic is 5135 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello members, today I improved our normalize function of our vector3 class at our company by factor 3 (!!!!) We're using Microsoft Visual Studio 6.0 Enterprise with SP5. Our first normalize implementation was like this: Vec* Normalize() { return (*this /= Length()); } My modified one that is three times faster is like this: Vec* Normalize() { float distInv = 1.f / Length(); return (*this *= distInv); } The microsoft compiler seems to optimize the first version very badly, if it does at all. Of course, we all checked the compiler settings, and we compiled release with all optimizations turned on for speed. We all triple-checked that, and everyone got the same result. Is the microsoft compiler so bad? We all thought the compiler would compute Length() and then call the division operator, but no, it seems that it inserts the term Length() into the division operator. So it calls Length() for every axis, xyz. Now we have fear, because: What if we do similar calls outside? What if we call: ourVec /= sin(foo....). or similar things? Will the microsoft compiler always insert the term uncomputed into our operators? Why the hell does it do such things!! Please help us, we all don't believe what's going on and we have fear that our app could run a lot faster. Thanks in advance, Lyve _____________________________________ http://www.winmaze.de, a 3D shoot em up in OpenGL, nice graphics, multiplayer, chat rooms, a nice community, worth visiting! [edited by - Lyve on November 27, 2003 3:08:24 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Lyve

Vec* Normalize() { return (*this /= Length()); }

My modified one that is three times faster is like this:

Vec* Normalize() { float distInv = 1.f / Length(); return (*this *= distInv); }




3 divisions vs 1 division, asuming that Vec::operator /= is implemented like this :



void Vec::operator /= (float p)
{
x /= p;
y /= p;
z /= p;
}



Could explain the difference.

quote:


Will the microsoft compiler always insert the term uncomputed into our operators? Why the hell does it do such things!!




Operators in classes are functions, just like a normal member function. I see no reason why the compiler should treat them different. So the term isn''t inserted uncomputed, it''s first computed then passed to the function as an argument.

Share this post


Link to post
Share on other sites