Re: about "Switch default hash to SIPHASH on 64 bit builds and ONE_AT_A_TIME on 32 bit builds"

On Wed, Dec 5, 2012 at 1:56 AM, demerphq <deme...@gmail.com> wrote:

> SipHash relies on 64 bit types, so cannot build on a 32 bit computer.>> Thus I made the default be SipHash for 64 bit builds and 32 bit builds> will continue to use One-at-a-time.

On a quick glance it looks as though you made it depend on the
definedness of U64, which as far as I know just means the compiler
supplies an unsigned 64-bit integer type and has nothing to do with
the size of an IV, the size of a pointer, the width of the data path
between the cpu and memory, maximum addressable memory, or other
common definitions of 64-bitness.

>> What is the difference between a 64 build>> and a 32 bit build? What about compilers/platforms that have compiler>> emulated 64 bit integers, like 32 bit x86?>> If someone can figure out how to build SipHash in this situations it> would be nice.

It doesn't look to me like anything special will be required to build
in this situation.  If the compiler supplies uint64_t or equivalent,
that's what SipHash will use.  If the compiler has to generate two or
three hardware instructions to perform an operation on a 64-bit
integer because its target doesn't have 64-bit integer instructions,
so be it.

It looks like the operations involved in SipHash are all bit shifting
and bit flipping (no exponentiation, no converting back and forth to
double, etc.), so it shouldn't be too much of a strain if those
operations have to be done by combining operations on two, 32-bit
pieces of string instead of being a single operation on one, 64-bit
piece of string, though of course benchmarks would be welcome.

The only interesting case is where the compiler does not supply a
64-bit type at all.  It's not utterly crazy to imagine a SipHash
implementation that does its thing on an array of two, 32-bit
integers, but it might not be worth trying to implement it.