3 ms·
The implementations measured are listed here: https://bench.cr.yp.to/impl-hash/blake2s.html https://bench.cr.yp.to/impl-hash/blake2s.html Code mirror: https:/
by dchest 9y ago
The implementations measured are listed here:
https://bench.cr.yp.to/impl-hash/blake2s.html https://bench.cr.yp.to/impl-hash/blake2s.html
Code mirror: https://github.com/floodyberry/supercop https://github.com/floodyberry/supercop
Yeah, of course reference implementation is a lot slower — it's for algorithm reference, so has readable code, which is slow. It can even be greatly improved by just unrolling loops and inlining message indexing by sigma constants, even without SSE (like my JavaScript implementation).
As for memory copying — I didn't mean memcpy(), what I meant is that your CPU would have to get chunks of your huge buffer from RAM, which is slower and has more unpredictable performance.
- jasode 9y ago>Yeah, of course reference implementation is a lot slower — it's for algorithm reference, so has readable code, which is slow. Exactly! That's why my original post had the footnote that I using the slower blake2sp reference code. Same situation as the SHA-3 reference code being the slowest implementation. >As for memory copying — I didn't mean memcpy(), what I meant is that your CPU would have to get chunks of your huge buffer from RAM, which is slower and has more unpredictable performance. But this observation also applies to all the other hash performance tests. If the blake2sp hash is handicapped by computing large RAM buffers beyond the L1/L2/L3 caches, the MD5/SHA1/SHA256/etc are also handicapped the same way. Whatever "noise" exists in the tests can be evened out by multiple executions. Restricting the tests to tiny memory sizes that fit in L1/L2/L3 is not realistic for my purposes.