# Why do the hash functions tested by SMhasher appear to be exceptionally fast?

In SMhasher, it seems that data (keys) are read one by one sequentialy, and not splited and:

MiB/sec: The average of the Bulk key speed test for alignments 0-7 with 262144-byte keys. The higher the better.


/\ This is written in its README.

The author said that are the output of hash functions that is measured.

Take a fast hash function tested by SMhasher, for example Blake3, it has 1288.84 MiB/S is a modern processor.

As the output is measured, 1288.84 MiB/S equals ~1351446691-bytes that means ~42232709 outputs of Blake3, each output has 32-byte (256-bits).

But if we multiply the number of Blake3 invocations per 262144-byte keys hashed sequentially as input we have this: 42232709 * 262144 = 11071051268096-bytes read as input (11.07-terabytes).

How can it be possible that the input of a hash function tested can read data at 11.07-terabytes per second?

• These are not all cryptographic hashes (Blake3 is though). Generally you perform SELECT's and searches using the DB keys. The key is the input of the hash function to build up a fast internal hash table. The key is hashed again to perform the lookup. Mar 12 at 6:19
• "The author said that are the output of hash functions that is measured." Can you show exactly where the author said that? This looks like a case of a misunderstood question, a badly written reply, or a misinterpretation of said reply. 1.3 GB/s of input data is the reasonable value here. Mar 13 at 3:07