Is poking opposite-endian integers byte by byte really faster than `pokeStorable . byteSwap`?

[raehik]

I got curious about some behaviour in this library and looked into it. In short, I feel the most efficient method of poking a machine integer with opposite endianness to the host should be to swap the byte order, then use host poke. It doesn't look like it makes much difference overall (unsurprised, most work is probably wrapping/unwrapping), but there appears to be a consistent marginal improvement on my 64-bit system (2%?): https://github.com/raehik/ptr-poker/commit/cf9cdbf1d362c2eb3fdcb41d4bdd28081fbb9025

I disassembled GHC's output for big endian encoding Word64s on my x86_64 system and confirmed that using byteSwap64 translates to a single "inlined" BSWAP instruction, whereas the byte-by-byte approach is a bunch of MOVs and SHRs.

[raehik]

Different binary serialization libraries tend to take different approaches to this.

• my suggestion uses CPP to check WORDS_BIGENDIAN and uses host poke when it can. When it can't it runs byteSwapX and host pokes.
• ptr-poker uses CPP to check WORDS_BIGENDIAN and uses host poke when it can. When it can't, it uses an endianness-independent, byte-by-byte poke.
• store doesn't provide explicit endianness primitives.
• binary, cereal use bytestring builder primitives; bytestring uses the same as my suggestion.
• flatparse uses my suggestion (parse only).

[nikita-volkov]

Sounds absolutely reasonable! Could you make a PR?

[raehik]

Gladly! Cleaned up and placed at #14 .

[nikita-volkov]

Thanks. It's merged and released now!