Use IEEE-754 interchange format?

[Olly Betts]

Most current platforms use IEEE-754 floating point formats, so using IEEE-754 interchange format in the remote protocol would be very efficient for such platforms. For any other platforms, a bit more work would be needed, but probably similar to what we do to encode and decode the base-256 representation we currently use.

The downsides I can see are that we'd lose precision or range if the native precision or range was better than IEEE (currently we should convert exactly), and that the current serialisation is more compact for some values (e.g. small integers) - it is bigger if all bits of the mantissa are used though, so might actually not be much different overall. In most cases weights aren't round numbers.

One wrinkle is it seems IEEE doesn't specify the endianness, so I guess we'd have to pick one and then convert for platforms which don't use the same endianness.

[Olly Betts]

Not worth holding 1.4.0 for, let's consider for the next development cycle.

[Olly Betts]

A slightly more concrete plan:

• Using little-endian IEEE-754 format makes most sense as that's the dominant format for current platforms (notably used by x86, x86-64, and common configurations of arm). For these platforms we then just need to copy the bytes in the new versions of serialise_double() and unserialise_double().

• For platforms with big-endian IEEE-754 we just need to byte-swap when doing that copying. There's already a helper do_bswap() which handles this efficiently (by using compiler built-ins or similar where available).

• For the (currently rare) platforms using a non-IEEE-754 format we'll need a pair of utility functions to convert between the native format and little-endian IEEE-754 format. The current serialise_double() and unserialise_double() should provide some hints as to how to implement those.

I'd suggest getting this working for IEEE-754 platforms first, then worrying about the others as a second step.

[Olly Betts]

Implemented on git master by [44f5a2fd44bb5a7139e8c189190101cd584122e1].

This is an incompatible remote protocol change, so not suitable for backporting to 1.4.x.