use of bitwise arithmetic in GEGL code

Is the use of such tricks discouraged for GEGL (because gfloats could
be doubles at some point?)

We can take the absolute value by setting the sign bit to zero:
// Example 13.24
float f;
*(int*)&f &= 0x7FFFFFFF; // set sign bit to zero

(From http://www.agner.org/optimize/optimizing_cpp.pdf)

Nicolas Robidoux
Universite Laurentienne

On 08/06/2009 09:00 PM, Nicolas Robidoux wrote:
> Is the use of such tricks discouraged for GEGL (because gfloats could
> be doubles at some point?)
>
> We can take the absolute value by setting the sign bit to zero:
> // Example 13.24
> float f;
> *(int*)&f&= 0x7FFFFFFF; // set sign bit to zero

Why not use standard library functions?

/ Martin

On 08/06/2009 09:00 PM, Nicolas Robidoux wrote:
> Is the use of such tricks discouraged for GEGL (because gfloats could
> be doubles at some point?)
>
> We can take the absolute value by setting the sign bit to zero:
> // Example 13.24
> float f;
> *(int*)&f&= 0x7FFFFFFF; // set sign bit to zero
>
> (From http://www.agner.org/optimize/optimizing_cpp.pdf)

It was an interesting paper, but I doubt that the gained speed in
execution performance outweights the messier code. Plus, his example was
to set the sign bit, i.e. x = -abs(x). Maybe x = abs(x) is equal to the
above for optimizing compilers

/ Martin

Michael:

> I doubt that the gained speed in execution performance outweights
> the messier code.

The bit twiddling absolute value was just an example. It's a
branch-free float minmod we're actually after.

Do I gather that it may be OK to use such bit twiddling provided the
speed gain is sufficient to justify code opacity?

Nicolas Robidoux

PS

Really, vector operations are where speed is to be found. But
implementation is a bit more involved than the occasional bit twiddle.

On 08/06/2009 10:02 PM, Nicolas Robidoux wrote:
> Michael:
>
>> I doubt that the gained speed in execution performance outweights
>> the messier code.
>
> The bit twiddling absolute value was just an example. It's a
> branch-free float minmod we're actually after.
>
> Do I gather that it may be OK to use such bit twiddling provided the
> speed gain is sufficient to justify code opacity?

If the code is unlikely to require changes later, then I'm fine with
these kind of optimizations

/ Martin

Ralf Meyer (another Laurentian prof) did some quick and dirty
experimentation with preliminary versions of bit-twiddling minmods and
found that on PowerPC chips it made a big difference. Not on Intel.

Not really surprising: Avoiding branches like the plague is more
relevant to PowerPC/cell than Intel.

In GEGL (production) code? Not sure.

Nicolas Robidoux

On Thu, Aug 6, 2009 at 3:00 PM, Nicolas Robidoux
<nrobidoux@cs.laurentian.ca> wrote:
>
> Is the use of such tricks discouraged for GEGL (because gfloats could
> be doubles at some point?)
>
> We can take the absolute value by setting the sign bit to zero:
> // Example 13.24
> float f;
> *(int*)&f &= 0x7FFFFFFF; // set sign bit to zero

Doesn't this violate pointer aliasing rules?

Rockwalrus

Nathan Summers writes:
> On Thu, Aug 6, 2009 at 3:00 PM, Nicolas Robidoux wrote
> >
> > Is the use of such tricks discouraged for GEGL (because gfloats could
> > be doubles at some point?)
> >
> > We can take the absolute value by setting the sign bit to zero:
> > // Example 13.24
> > float f;
> > *(int*)&f &= 0x7FFFFFFF; // set sign bit to zero
>
> Doesn't this violate pointer aliasing rules?

Indeed.

Consequence of your observation: The next edition of Agner Fog's
online optimization manuals

http://www.agner.org/optimize/#manuals

will contain an updated version of the above example:

union {
float f;
int i;
} u;
u.i &= 0x7FFFFFFF; // set sign bit to zero

and the following caveat:

In general, it is faster to access a floating point variable as an
integer if it is stored in memory, but not if it is a register
variable. The union forces the variable to be stored in memory, at
least temporarily. Using the methods in the above examples will
therefore be a disadvantage if other nearby parts of the code could
benefit from using registers for the same variables. Using type
casting of pointers instead of unions in the above examples may not
work on compilers that rely on the strict aliasing rule of standard
C, specifying that pointers of different types cannot point to the
same object, except for char pointers.

Nicolas Robidoux
Laurentian University