Re: Fast binary IEEE to float
Thomas Richter wrote:
in one of my latest projects, I need to interpret floating
point data stored in an external buffer as IEEE numbers. The
data is layed out as IEEE, but "advertised" as raw binary
data.
Now, to make this portable, even for machines that do not use
IEEE as native floating point format, I wrote a little
conversion routine that interprets the binary data stored in a
32-bit integer and constructs from it a "float". All this
works fine even for denormalized numbers. NANs and INFs are
not an issue as they are disallowed.
Unfortunately, even though all this works fine as it is, it
turns out to be too slow - benchmarks done, it's a critical
part of the code. Luckely, on the most important target
system, floats just *happen to be* IEEE numbers even in the
right endian, so all I would need to do is to "cast" the
integer to float.
I tried several approaches, and would like to ask you for
recommendations as what to use (code reduced to the minimum):
1) Method one: The "pointer trick": (LONG is a 32 bit binary integer type):
float QuickBinaryToFloat(LONG in)
{
return *(float *)∈
}
That's the way I'd do it (but with a reinterpret_cast, and
uint32_t instead of LONG).
Actually, I think I'd write it using references :
float QuickBinaryToFloat( uint32_t in )
{
return reinterpret_cast< float& >( in ) ;
}
2) Method two: The "union trick":
float QuickBinaryToFloat(LONG in)
{
union {
LONG i;
float o;
} u;
u.i = in;
return u.o;
}
Formally, that's undefined behavior. (The reinterpret_cast is
only implementation defined.) In practice, it should work if
the function is compiled without optimization. (With
optimization, of course, the compiler will recognize that u.i is
never used, and suppress the assignment.)
3) Modified version 1):
float QuickBinaryToFloat(LONG in)
{
return *(float *)(char *)∈
}
What does this buy you compared to 1?
Problem: Pointer aliasing. For method 1, the latest g++ warns
(AFAIK correctly) that it breaks the strict aliasing rule
because now we have one object (in) that is reachable as two
different types, so the compiler believes that it might break
something. House policy disallows warnings in deliverable
code, so it's a no-no.
Given that all of the trickiness is in a single expression, I
can't imagine it not working. What would be the point of
supporting reinterpret_cast otherwise? It's required to work on
Posix based systems -- or at least those supporting dlsym (where
the documentation says to use something similar to write a void*
into a pointer to a function). And a compiler which warns that
you're doing something dangerous when you use a reinterpret_cast
isn't really very clever. You know that; otherwise, you
wouldn't need a reinterpret_cast. Historically, casts have been
the approved way of stopping a compiler from complaining.
The guideline against warnings is a good one, but you should be
able to apply what should be the rule 0 of every guideline: any
rule may be broken given a good justification. Just tell your
bosses that they have a choice: no warnings, or no speed.
For method 2, the problem stays the same, but gcc allows it.
It looks even more fishy to me, but maybe you've more
experiences with other compilers.
I've used at least one compile (an older version of Microsoft C)
which did the read of u.o before it did the write of u.i; the
standard says (alghough this was pre-standard) that they are
different "variables", and that you can only use one at a time.
Method 3 avoids the aliasing as a "char *" must, AFAIK, be
assumed to be possibly aliased. It might possibly (?) prevent
the optimizer from making some optimizations - the code above
is truncated down, it is part of a larger method which does
this step.
Since you don't actually access as a char*, method 3 buys you
nothing (IMHO). Strictly speaking, the surest is copying the
bytes: memcpy, or copy through an unsigned char*. That is the
only way in which the standard guarantees that the bits in the
original uint32_t are the same as those in the float.
Interestingly, reinterpret_cast<> is not allowed to make this
conversion, though it looked reasonably enough for me (why,
actually?).
Which conversion? reinterpret_cast should support all of the
possible pointer and reference conversions.
I also checked for compiler-specific extensions, but haven't
found any built-in function for it.
There's always asm:-).
Any recommendations, possibly a fourth method, or any
experiences from your projects?
I've never found the "correct" conversion (which makes no
assumptions concerning the internal format of float) to be a
performance problem. It takes about 10 msec. to read a sector
from disk, and compared to that, the couple of microseconds for
the conversion routines are negligible. If the internal
floating point format is binary, ldexp and frexp shouldn't take
more than that, and extracting the individual fields from the
input isn't very costly either.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]