I noticed in sn_api Cargo.toml there are 2 different crates for the same thing, sha3 and tiny-keccak both provide the same hash functionality. Turns out there’s a good reason for it, but I got curious if we did have the chance to consolidate which one to use.
In the end, tiny-keccak was the faster lib.
100 bytes input, 10K tests. Values are nanoseconds per hash
Using the median, tiny-keccak is about 7.8% faster. Not a lot, but that’s about 1h51m difference over 24h of hashing, so it’s not completely unimportant.
1 MB input, 10K tests. Values are nanoseconds per hash
The median has tiny-keccak at about 0.13% faster so that’s pretty close, about 1m56s difference over 24h of hashing.
I did remove one of the libraries for the fun of it (turned out tiny-keccak was much easier to remove so I did that) and the difference in file size was about 90K, but increased in size after removal. Probably to do with adding in sha3_512 which must be much smaller in tiny-keccak than sha3.
When testing bls performance in this post, blst (which does hashes with assembly) is much faster than threshold_crypto (which does hashes with tiny-keccak), so I hoped to be able to test the blst hashing too. But it’s a difficult library to hack on, so I didn’t get to it. I’m also not sure if blst is using sha2 or sha3, anyone able to compare the sources? Here’s a link to blst/sha256.h and blst/sha256-x86_64.pl if anyone’s keen. I’m pretty sure it’s sha2, judging from their use of Intel SHA Extensions, which would also explain the speed of blst compared to threshold_crypto.