SipHash benchmarks: I will use HalfSipHash31

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

SipHash benchmarks: I will use HalfSipHash31

Sam Trenholme
I have run a number of benchmarks with Lunacy, my fork of Lua 5.1, to
see how much changing the SipHash variant used affects performance, for
both 32-bit (386) and 64-bit (x86_64) binaries.

Conclusion: I will use HalfSipHash31 as the hash compression algorithm,
for both 32-bit and 64-bit builds of Lunacy.

The binaries have been compiled using GCC 8.3.1, in CentOS 8, using an
older Core Duo T8100 chip from 2008.  The benchmark consisted of loading
and processing a bunch of COVID-19 data in to large tables taking up 550
(32-bit) or 750 megs (64-bit) of memory.  This real-world benchmark (it
is the exact same code I use to build an entire COVID-19 tracking
website) was done multiple times, to minimize speed fluctuations from
outside factors, against the following setups:

• “Lunacy32”, which is a 32-bit compile of Lua 5.1
• “Lunacy64”, a 64-bit compile of same

And the following string hash compression functions:

• “noSipHash”: Lua’s default hash compressor
• “SipHash42”: 64-bit SipHash with 2 rounds during input processing,
followed by 4 rounds after input ends.
• “SipHash31”: 64-bit SipHash with 1 round during input processing,
followed by 3 rounds after input ends.
• “SipHalf31”: 32-bit HalfSipHash with 1 round during input processing,
followed by 3 rounds after input ends.

Here are the results, where lower numbers are better (less time needed
to run the benchmark):

lunacy64-noSipHash 197.801
lunacy64-sipHash31 203.457
lunacy64-SipHalf31 203.507
lunacy64-sipHash42 210.043
lunacy32-noSipHash 240.898
lunacy32-SipHalf31 246.995
lunacy32-sipHash31 265.916
lunacy32-sipHash42 270.226

HalfSipHash31 is as fast as full SipHash31 on 64-bit CPUs, while being
quite a bit faster for 32-bit binaries compared to 64-bit sipHash.

HalfSipHash31 is only 2.5% slower on 32-bit machines (compared to Lua’s  
“stock” hash); it is only 2.9% slower on 64-bit machines.

Since HalfSiphash only has a 64-bit key, it is not fully secure in cases
where an attacker has significant computing resources to brute force the
key, and where the attacker is able to see the hash compression values
for strings.  However, in the case of using HalfSipHash31 as a hash
compression string, an attacker will not be able to see the hash
compression values; to do so would require viewing the memory used by a
Lua process -- if an attacker has that level of access, there are other
far more devistating attacks they can perform.

-- Sam
Reply | Threaded
Open this post in threaded view
|

Re: SipHash benchmarks: I will use HalfSipHash31

Sam Trenholme
The compile time flags were -O3 for maximum performance.

> The binaries have been compiled using GCC 8.3.1, in CentOS 8