[Haskell-cafe] ANN: ieee version 0.7
daniel.is.fischer at web.de
Tue Sep 21 15:08:11 EDT 2010
On Tuesday 21 September 2010 19:46:02, John Millikin wrote:
> On Tue, Sep 21, 2010 at 07:10, Daniel Fischer <daniel.is.fischer at web.de>
> > And I'd expect it to be a heck of a lot faster than the previous
> > implementation. Have you done any benchmarks?
> Only very rough ones -- a few basic Criterion checks, but nothing
Certainly good enough for an indication.
> Numbers for put/get of 64-bit big-endian:
> getWord getFloat putWord putFloat
> Bitfields (0.4.1) 59 ns 8385 ns 1840 ns 11448 ns
> poke/peek (0.4.2) 59 ns 305 ns 1840 ns 744 ns
Yaw. That's a huge difference. I don't think there's much room for doubt
that it's much faster (the exact ratios will vary of course).
> unsafeCoerce 59 ns 61 ns 1840 ns 642 ns
Odd that unsafeCoerce gains 244 ns for get, but only 102 for put.
> Note: I don't know why the cast-based versions can put a Double faster
> than a Word64;
Strange. putFloat does a putWord and a transformation, how can that be
faster than only the putWord?
> Float is (as expected) slower than Word32. Some
> special-case GHC optimization?
> > One problem I see with both, unsafeCoerce and poke/peek is endianness.
> > Will the bit-pattern of a double be interpreted as the same uint64_t
> > on little-endian and on big-endian machines? In other words, is the
> > byte order for doubles endianness-dependent too?
> > If yes, that's fine, if no, it would break between machines of
> > different endianness.
> Endianness only matters when marshaling bytes into a single value --
> Data.Binary.Get/Put handles that. Once the data is encoded as a Word,
> endianness is no longer relevant.
I mean, take e.g. 2^62 :: Word64. If you poke that to memory, on a big-
endian machine, you'd get the byte sequence
40 00 00 00 00 00 00 00
while on a little-endian, you'd get
00 00 00 00 00 00 00 40
If both bit-patterns are interpreted the same as doubles, sign-bit = 0,
exponent-bits = 0x400 = 1024, mantissa = 0 , thus yielding
1.0*2^(1024 - 1023) = 2.0, fine. But if on a little-endian machine, the
floating point handling is not little-endian and the number is interpreted
as sign-bit = 0, exponent-bits = 0, mantissa = 0x40, hence
(1 + 2^(-46))*2^(-1023), havoc.
I simply didn't know whether that could happen. According to
On the other hand, "no standard for transferring floating point values has
been made. This means that floating point data written on one machine may
not be readable on another", so if it breaks on weird machines, it's at
least a general problem (and not Haskell's).
More information about the Haskell-Cafe