This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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