BLAKE2b hashing is significantly slower than blake2

[vaibhavsagar]

I've been benchmarking cryptonite against blake2 for BLAKE2b hashing, and I've found that cryptonite is significantly (~3x) slower, and ~2x slower than blake2 with all INLINEs replaced with NOINLINEs. Am I doing something wrong in the benchmarking code that would lead to this result? Here is a sample run:

benchmarking hashing/blake2
time                 49.30 ms   (49.09 ms .. 49.45 ms)
                     1.000 R²   (1.000 R² .. 1.000 R²)
mean                 48.88 ms   (48.65 ms .. 49.08 ms)
std dev              392.4 μs   (240.6 μs .. 599.8 μs)

benchmarking hashing/blake2-patched
time                 77.64 ms   (76.35 ms .. 78.91 ms)
                     1.000 R²   (0.999 R² .. 1.000 R²)
mean                 76.78 ms   (75.85 ms .. 77.52 ms)
std dev              1.341 ms   (842.3 μs .. 1.900 ms)

benchmarking hashing/cryptonite
time                 161.4 ms   (155.8 ms .. 164.9 ms)
                     0.999 R²   (0.998 R² .. 1.000 R²)
mean                 157.3 ms   (155.4 ms .. 159.4 ms)
std dev              2.673 ms   (1.701 ms .. 3.362 ms)
variance introduced by outliers: 12% (moderately inflated)

[vaibhavsagar]

See kadena-io/blake2#1 for the motivation behind replacing those INLINEs.

[ocheron]

Considering haskell-cryptography/blake2#4 I'm not sure the functions compute the same result.

With a simpler program derived from the benchmark:

main = do
    print (originalHash B.empty)
    print (patchedHash B.empty)
    print (cryptoniteHash B.empty)

I get:

"00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
"00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
"786a02f742015903c6c6fd852552d272912f4740e15847618a86e217f71f5419d25e1031afee585313896444934eb04b903a685b1448b755d56f701afe9be2ce"

[vaibhavsagar]

Good point.

[ocheron]

Also cryptonite has a generic implementation so we can expect it slower than a specialized library doing only BLAKE2. This will be especially visible with very short messages, probably less as the input size increases.