FPU and CRT
Jan Bares
achieve maximal speed I have found that implementations of functions from
<math.h> library are very complex, long and slow. I understand that this is
due to compatibility reasons (?). For instance if you step into _sqrt()
routine, you will find lot of calls like __fload_withFB, __load_CW,
__convertTOStoQNaN and in the middle of it there is the fsqrt instruction.
Is there any library for Intel Pentium FPU that will just do the requested
operation without any checks?
BTW, multiplication/division/subraction/addition has no function equivalent
in <math.h> with checks for various FPU exceptions, they are just emitted by
compiler as one expects. So why there is no sqrt() function that will just
call fsqrt?
_hypot() versus sqrt(): When I discovered _hypot() function, I used it when
it was possible. Now with little benchmark I was surpriced, that old version
of the same calculation with sqrt(x * x + y * y) is 8 times faster than
calling _hypot(x, y)!
The VC compiler uses FLD1 or FLDZ to load 1.0 or 0.0. But there is no way
how to load Pi even if the FPU has FLDPI instruction.
What is your opinion? Where are some resources related to this topics? Will
the intel compiler (part of VTune) help me?
Regards, Jan
PS: I use VC++ 6.0, SP3
--
Jan Bares
(remove no.spam from my email address)
JPCAD Graphics Engine developer, surf to http://www.antek.cz
Jan Bares
Unfortunately I was always using optimization for size (I firmly believe
that I can optimize program for speed much better by good algorithm desing
than speed optimization of compiler) and with this optimization the
intrinsic math functions are disabled.
Anyway any comments will be appreciated.
Dan Evens
<eoGJnkJb$GA....@cppssbbsa02.microsoft.com>...
> Blind me, now I have found intrinsic version of those functions.
> Unfortunately I was always using optimization for size (I firmly believe
> that I can optimize program for speed much better by good algorithm
desing
> than speed optimization of compiler) and with this optimization the
> intrinsic math functions are disabled.
>
> Anyway any comments will be appreciated.
While algorithm is critical to fast code, and while there are some
specifics at which it is very difficult for any compiler to make a
really well optimized binary, in general, it is a truly unusual
coder who can do much better than the compiler *at*what*
*the*compiler*is*good*at!* And it is a truly remarkable coder
who can do this without some experimentation and testing to
see which of several alternatives is actually better, and by how
much.
As this news group has bashed around quite a bit recently,
there are lots of things that are supposed to make a code
faster that can sometimes and other times may make it slower.
For example, loop unwinding can make code faster. Or the
larger code size can wind up causing more swapping and the
code might actually run slower. Or the difference may be so
minute that, in situations where user interaction is involved for
example, whatever is easier to maintain is perferable.
Similar comments will apply to changes made to make a code
smaller, etc. Try the "clever elegant" method and compare it
to the "easy to understand" method. See if it actually makes a
difference, a difference that matters to the person paying the
bills. If the difference is unimportant, stay with whatever is
easier to maintain.
--
Dan Evens
Standard disclaimers etc. No spam please.
Just because nobody complains does not
mean that all parachutes are perfect.
Jan Bares
> specifics at which it is very difficult for any compiler to make a
> really well optimized binary, in general, it is a truly unusual
> coder who can do much better than the compiler *at*what*
> *the*compiler*is*good*at!* And it is a truly remarkable coder
> who can do this without some experimentation and testing to
> see which of several alternatives is actually better, and by how
> much.
Usually there are few places in whole program where you *really* have to
care about speed. Usually the problem is inside a loop. Sometimes it really
helps when compiler optimizes, but usually it will not speed up things in
orders of magnitude. But with careful algrorithm design you can optimize and
maybe completely avoid using loops. In other words usual problem of speed is
that you choose algorithm with big complexity of O(n^2) or worse. When this
code is slow, compiler optimization will not help you. You will have to
choose different approach.
I see no reason why to ask compiler to speed optimize UI code. Much more
time is spent inside Win32 API than in your code so result of optimization
will not be percieved by user.
>
> As this news group has bashed around quite a bit recently,
> there are lots of things that are supposed to make a code
> faster that can sometimes and other times may make it slower.
> For example, loop unwinding can make code faster. Or the
> larger code size can wind up causing more swapping and the
> code might actually run slower. Or the difference may be so
> minute that, in situations where user interaction is involved for
> example, whatever is easier to maintain is perferable.
You can read very good article about optimization at
http://msdn.microsoft.com/library/ - Technical Articles/Visual Tools/Visual
C++/Visual C++ 6.0/Developing optimized code with Microsoft Visual C++ 6.0
Sure I know how good is VC 6.0 when it comes to optimalization. This is one
of the most important reasons why I choose it.
>
> Similar comments will apply to changes made to make a code
> smaller, etc. Try the "clever elegant" method and compare it
> to the "easy to understand" method. See if it actually makes a
> difference, a difference that matters to the person paying the
> bills. If the difference is unimportant, stay with whatever is
> easier to maintain.
Code readability (which includes also documentation) is very important
issue, maybe the most important topic in programming.
Thanks for comments, Jan