5 ms·

Hmm, something is wrong with your benchmark: the absolute values in MB/s are very low for i7, and relative too — blake2sp should be much faster than SHA256.

by dchest 9y ago

jasode 9y ago
>blake2sp should be much faster than SHA256. blake2sp is indeed faster than Microsoft's builtin Crypto API for SHA256. However, it is not as fast as Wei Dai's Crypto++ library implementation of SHA256 that has lots of hand tuned assembly language code. The official C source code for blake2sp does not have assembly language primitives in it. It's very possible that if an assembly language expert wrote optimizations for blake2sp, it would beat Crypto++ SHA256 performance. The code I used is really simple. Used files "blake2sp-ref.c" and "blake2s-ref.c" from the BLAKE website. The hash code (no loops) is: blake2sp_state S[1]; // BLAKE 1 element array of the struct for state blake2sp_init(S, BLAKE2S_OUTBYTES); blake2sp_update(S, BufInput, iBuffersize); blake2sp_final(S, hashval_blake2sp_bytes, BLAKE2S_OUTBYTES); ... where iBuffersize is 500MB but I got the same results at larger buffer sizes 1GB+. With that code, I'm guessing anyone can whip up a C++ project to benchmark blake2sp in 10 minutes. It would be interseting to see what MB/sec that others achieve.
- mappu 9y ago
  There is AVX/AVX2 assembly for BLAKE2 at https://github.com/minio/blake2b-simd https://github.com/minio/blake2b-simd , benchmarked at a 1.8x-3.9x speedup.
- dchest 9y ago
  My pure JavaScript implementation of blake2s (which is approximately half the speed of parallelized sp variant) on 2.6 GHz Core i5 hashes at 170 MiB/s. JavaScript! Whatever you do with your benchmark, you're doing it wrong. Also, there is no reason to use such large buffer sizes, I suspect this only makes benchmarks more unreliable. For real numbers on many platforms, see https://bench.cr.yp.to/results-hash.html https://bench.cr.yp.to/results-hash.html (warning: very large page) For long messages on 2015 Intel Core i5-6600; 4 x 3310MHz: blake2b: 3.33 cycles/byte blake2s (remember, half speed of sp): 4.87 cycles/byte sha512: 5.06 cycles/byte sha256: 7.63 cycles/byte This means BLAKE2s is close to 700 MB/s, and BLAKE2sp will hash data at more than 1 GB/s. Here are the SHA-256 implementations measured: https://bench.cr.yp.to/impl-hash/sha256.html https://bench.cr.yp.to/impl-hash/sha256.html As you can see, the winner varies by platform, but in most cases OpenSSL wins, and Wei Dai's implementation is close.
  - jasode 9y ago
    >My pure JavaScript implementation of blake2s (which is approximately half the speed of parallelized sp variant) on 2.6 GHz Core i5 hashes at 170 MiB/s. If I recompile blake2sp with "/O2" optimization, it improves to 171MB/sec. I ran tests with "/Od" optimizations disabled because the default Crypto++ library project has optimizations disabled when it makes the lib file. Therefore, every hash had no optimizations to keep the comparisons apples to apples. I see your Javascript code of BLAKE2 on github so I'll try it and compare. (https://github.com/dchest/blake2s-js https://github.com/dchest/blake2s-js) >Also, there is no reason to use such large buffer sizes, I suspect this only makes benchmarks more unreliable. I chose 500MB because I wanted the fastest hashes (CRC32, MD5) to take at least 1 second and many data sizes I want to hash will be 10GB+.
    - dchest 9y ago
      If I recompile blake2sp with "/O2" optimization, it improves to 171MB/sec. Too slow! You're doing something wrong or measuring some slow implementation :) It should be more than 500 MB/s. Therefore, every hash had no optimizations to keep the comparisons apples to apples. That's not apples to apples at all. Most performant code is written specifically to be optimized by compiler. Use /O3 for benchmarking. Also, you just wrote that you were measuring a hand-optimized assembly version and then compared it to a C version compiled with optimization disabled? O_o I chose 500MB because I wanted the fastest hashes (CRC32, MD5) to take at least 1 second and many data sizes I want to hash will be 10GB+. Then call the update function with a reasonable 8K buffer many times. Using such large buffers will generate a lot of noise in benchmarks. * * * Speaking of JS, you can try my newer implementations/ports by cloning https://github.com/StableLib/stablelib https://github.com/StableLib/stablelib. run ./scripts/build, cd into packages/blake2s (/sha3, /sha256, etc.) and run: node lib/.bench.js Note that SHA-3 (and SHA-512, BLAKE2b [not implemented yet]) is slow in JS compared to SHA-256, BLAKE2s, etc. because it uses 64-bit numbers, so in JS I have to emulate them by using two 32-bit ones for low and high bits. * * Benchmarks on Intel Skylake: https://blake2.net/skylake.png https://blake2.net/skylake.png
      - jasode 9y ago

Hmm, something is wrong with your benchmark: the absolute values in MB/s are very low for i7, and relative too — blake2sp should be much faster than SHA256.

by dchest 9y ago

Hmm, something is wrong with your benchmark: the absolute values in MB/s are very low for i7, and relative too — blake2sp should be much faster than SHA256.

jasode 9y ago

>blake2sp should be much faster than SHA256. blake2sp is indeed faster than Microsoft's builtin Crypto API for SHA256. However, it is not as fast as Wei Dai's Crypto++ library implementation of SHA256 that has lots of hand tuned assembly language code. The official C source code for blake2sp does not have assembly language primitives in it. It's very possible that if an assembly language expert wrote optimizations for blake2sp, it would beat Crypto++ SHA256 performance. The code I used is really simple. Used files "blake2sp-ref.c" and "blake2s-ref.c" from the BLAKE website. The hash code (no loops) is: blake2sp_state S[1]; // BLAKE 1 element array of the struct for state blake2sp_init(S, BLAKE2S_OUTBYTES); blake2sp_update(S, BufInput, iBuffersize); blake2sp_final(S, hashval_blake2sp_bytes, BLAKE2S_OUTBYTES); ... where iBuffersize is 500MB but I got the same results at larger buffer sizes 1GB+. With that code, I'm guessing anyone can whip up a C++ project to benchmark blake2sp in 10 minutes. It would be interseting to see what MB/sec that others achieve.

mappu 9y ago
There is AVX/AVX2 assembly for BLAKE2 at https://github.com/minio/blake2b-simd https://github.com/minio/blake2b-simd , benchmarked at a 1.8x-3.9x speedup.
dchest 9y ago
My pure JavaScript implementation of blake2s (which is approximately half the speed of parallelized sp variant) on 2.6 GHz Core i5 hashes at 170 MiB/s. JavaScript! Whatever you do with your benchmark, you're doing it wrong. Also, there is no reason to use such large buffer sizes, I suspect this only makes benchmarks more unreliable. For real numbers on many platforms, see https://bench.cr.yp.to/results-hash.html https://bench.cr.yp.to/results-hash.html (warning: very large page) For long messages on 2015 Intel Core i5-6600; 4 x 3310MHz: blake2b: 3.33 cycles/byte blake2s (remember, half speed of sp): 4.87 cycles/byte sha512: 5.06 cycles/byte sha256: 7.63 cycles/byte This means BLAKE2s is close to 700 MB/s, and BLAKE2sp will hash data at more than 1 GB/s. Here are the SHA-256 implementations measured: https://bench.cr.yp.to/impl-hash/sha256.html https://bench.cr.yp.to/impl-hash/sha256.html As you can see, the winner varies by platform, but in most cases OpenSSL wins, and Wei Dai's implementation is close.
- jasode 9y ago
  >My pure JavaScript implementation of blake2s (which is approximately half the speed of parallelized sp variant) on 2.6 GHz Core i5 hashes at 170 MiB/s. If I recompile blake2sp with "/O2" optimization, it improves to 171MB/sec. I ran tests with "/Od" optimizations disabled because the default Crypto++ library project has optimizations disabled when it makes the lib file. Therefore, every hash had no optimizations to keep the comparisons apples to apples. I see your Javascript code of BLAKE2 on github so I'll try it and compare. (https://github.com/dchest/blake2s-js https://github.com/dchest/blake2s-js) >Also, there is no reason to use such large buffer sizes, I suspect this only makes benchmarks more unreliable. I chose 500MB because I wanted the fastest hashes (CRC32, MD5) to take at least 1 second and many data sizes I want to hash will be 10GB+.
  - dchest 9y ago
    If I recompile blake2sp with "/O2" optimization, it improves to 171MB/sec. Too slow! You're doing something wrong or measuring some slow implementation :) It should be more than 500 MB/s. Therefore, every hash had no optimizations to keep the comparisons apples to apples. That's not apples to apples at all. Most performant code is written specifically to be optimized by compiler. Use /O3 for benchmarking. Also, you just wrote that you were measuring a hand-optimized assembly version and then compared it to a C version compiled with optimization disabled? O_o I chose 500MB because I wanted the fastest hashes (CRC32, MD5) to take at least 1 second and many data sizes I want to hash will be 10GB+. Then call the update function with a reasonable 8K buffer many times. Using such large buffers will generate a lot of noise in benchmarks. * * * Speaking of JS, you can try my newer implementations/ports by cloning https://github.com/StableLib/stablelib https://github.com/StableLib/stablelib. run ./scripts/build, cd into packages/blake2s (/sha3, /sha256, etc.) and run: node lib/.bench.js Note that SHA-3 (and SHA-512, BLAKE2b [not implemented yet]) is slow in JS compared to SHA-256, BLAKE2s, etc. because it uses 64-bit numbers, so in JS I have to emulate them by using two 32-bit ones for low and high bits. * * Benchmarks on Intel Skylake: https://blake2.net/skylake.png https://blake2.net/skylake.png
    - jasode 9y ago