4 ms·
Not sure why you are downvoted. Your table looks more factual than the blake3's github.
by antpls 7y ago
Not sure why you are downvoted. Your table looks more factual than the blake3's github.
- espadrine 7y agoRE: the downvotes; while I didn't partake, I know there is history between the BLAKE/BLAKE2/BLAKE3 author, JP Aumasson, and Rurban, in particular related to differing opinions over the publication of SipHash. Differing opinions here means that most of the cryptographic community agree that SipHash clears its claims as a PRF, while Rurban indicated he has found undisclosed vulnerabilities that he wishes not to publish. RE: the table; a point to note is that BLAKE3's main implementation, in Rust, benefits a lot from multithreading on large files, which SHA2 cannot. The C version, which Rurban copied, does not leverage multithreading: https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.md https://github.com/BLAKE3-team/BLAKE3/blob/master/c/README.m...
- temac 7y agoComparing single threaded speeds is also very valid for tons of contexts. Of course if one algo can't be multithreaded, maybe it will be better to use one that can instead, if that's interesting for a particular application, but it won't be necessarily interesting for all applications. So there is no single ordering about which is faster, in this case. If you sometimes needs to compute hashes on a computer that would have multiple unused cores at that moment, the multithreaded hash will have an advantage. If you are always loaded, you better consider the total amount of work; and maybe likewise if you want to prioritize energy efficiency (although it will not be completely linear)
- zokier 7y agoThe tone of the comment was unnecessarily dismissive, and it is kinda expected that hw implementation beats sw implementations. If anything, it's pretty impressive how close blake3 gets without dedicated instructions.