However, none with SHAEXT; they just weren't there yet. But the Zen numbers should give you a good idea.
Note that these benchmarks are made using a plain C implementation of BLAKE2 (the reference one), which is not vectorized by any compiler. The fastest (AVX2) BLAKE2 implementation is about 40 % faster than the scalar C implementation (on Haswell).
As far as I'm aware no mainstream crypto library ships optimized BLAKE2 versions. I believe some Go packages do/did make up their own version (not the one from Samuel Neves), but at least one of them mixed SSE and VEX/AVX insns with the predictably bad results (60 MB/s or so) - perhaps this is fixed by now.
So in summary, BLAKE2b is imho the best candidate on perf, and if you use a good implementation it should be within ~30% of SHA2 (512) with SHAEXT — with the numbers we have so far. I understand that Zen's aggressive (=good) power mgt makes it somewhat difficult to benchmark hot loops consistently, so we'll have to wait and see for practical results, I guess.
However, none with SHAEXT; they just weren't there yet. But the Zen numbers should give you a good idea.
Note that these benchmarks are made using a plain C implementation of BLAKE2 (the reference one), which is not vectorized by any compiler. The fastest (AVX2) BLAKE2 implementation is about 40 % faster than the scalar C implementation (on Haswell).
As far as I'm aware no mainstream crypto library ships optimized BLAKE2 versions. I believe some Go packages do/did make up their own version (not the one from Samuel Neves), but at least one of them mixed SSE and VEX/AVX insns with the predictably bad results (60 MB/s or so) - perhaps this is fixed by now.
So in summary, BLAKE2b is imho the best candidate on perf, and if you use a good implementation it should be within ~30% of SHA2 (512) with SHAEXT — with the numbers we have so far. I understand that Zen's aggressive (=good) power mgt makes it somewhat difficult to benchmark hot loops consistently, so we'll have to wait and see for practical results, I guess.