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
| crate | min | median | average | max |
|---|---|---|---|---|
| sha3 | 602 | 670 | 714.6 | 21224 |
| tiny-keccak | 554 | 618 | 653.74 | 48502 |
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
| crate | min | median | average | max |
|---|---|---|---|---|
| sha3 | 3255550 | 4157527.5 | 4259370.89 | 9443800 |
| tiny-keccak | 3152116 | 4151925.5 | 4235831.5 | 10022048 |
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.