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

On 5 December 2012 14:30, Craig A. Berry <crai...@gmail.com> wrote:
> 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.

Im fine with changing it. My rationale was that as far as I understand
SipHash works on anything that supports a 64 bit unsigned type, and if
U64 was defined we had one. I am totally open to the idea that I did
it wrong :-)

>>> 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.

Yeah, thats my view too mostly.

> 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.

Personally I dont see the point, we are adopting SipHash as the
default out of an abundance of caution. One-at-a-time is not yet known
to be compromised and is believed to be stronger than Murmurhash so it
is also a candidate for the default.

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"