This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fast operations on floating point numbers?


>>>>> "Martin" == Martin Reinecke <martin@MPA-Garching.MPG.DE> writes:

 Martin> Peter Barada wrote:
 >> If flipsign is only refered to inside the(hevily executed) loop,
 >> you could try:
 >> 
 >> double a, flip; int flipsign;
 >> 
 >> flip = flipsign ? -1.0 : 1.0;
 >> 
 >> for (;;) { ...  a *= flip; ...  }
 >> 
 >> And get rid of the conditional...

 Martin> Unfortunately this does not work in all places where I have
 Martin> this problem. But even where I can use it, there is still a
 Martin> full floating-point multiplication where the simple XORing of
 Martin> a single bit should do. But maybe the cost of both operations
 Martin> is not so different on today's CPUs; I don't know.

You'd have to study the CPU books to find out; the answer will vary.

On some CPUs, trying to XOR float values is a bad idea because it
requires moving things from float to integer registers, which may
require memory load/stores.  

On some CPUs, using a multiply instead of a negate may hurt a lot.  On
others it might be just fine.

Some CPUs may have conditional-execute machinery so something like
     if (foo) a = -a;
doesn't involve any branches.  Other CPUs may have efficient branch
caches so the cost of that conditional branch is very low.

My inclination would be to write the obvious source code (i.e., what's
above) and let the optimizer pick "the right" answer.  Trying to fake
it out by introducing a multiply by -1.0 either will have no effect
(if the compiler recognizes the constant and translates the operation
back into a negate) or is likely to make things slower.

If profiling and/or analysis of the generated code along with a
detailed study of the processor documentation tells you that the
optimizer is NOT generating the best code for this task (and that
improving it will actually make an interesting difference) then your
best bet is to insert assembly language code for the job.  But if you
don't understand the CPU well enough to do that, you really should
just leave things alone and let the compiler do its best.

     paul


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]