| Store | Cart

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

From: demerphq <deme...@gmail.com>
Wed, 5 Dec 2012 22:50:48 +0100
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.


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

Recent Messages in this Thread
bulk88 Dec 05, 2012 01:28 am
Craig A. Berry Dec 05, 2012 01:30 pm
demerphq Dec 05, 2012 09:50 pm
bulk88 Dec 05, 2012 10:57 pm
Craig A. Berry Dec 06, 2012 04:50 am
bulk88 Dec 07, 2012 12:40 am
demerphq Dec 06, 2012 07:35 am
bulk88 Dec 07, 2012 12:20 am
bulk88 Dec 07, 2012 01:00 am
bulk88 Dec 07, 2012 03:35 am
bulk88 Dec 05, 2012 11:00 pm
bulk88 Dec 05, 2012 03:52 pm
H.Merijn Brand Dec 05, 2012 03:58 pm
Brad Gilbert Dec 09, 2012 04:49 pm
Messages in this thread