Nice to see: on my non-AVX512 amd thread ripper, this is almost as fast as the b3sum reference implementation written in rust, generally 1-2% slower.

On my AVX512 enabled mac, this Go version is faster than b3sum.

Ah. It turns out I was choking off the available parallelism. With a buffered channel, we are strictly faster than the rust version.

I appreciate that authors have limited time to review such changes; and may wish to keep their libraries tightly focused on single core performance.

For users like myself who need the fastest possible file hashing -- using all available cores -- my fork's master branch https://github.com/glycerine/blake3 has these changes applied. My b3 tool makes them available in a b3sum-like command line utility: https://github.com/glycerine/b3

Thanks for the contribution! The API and overall style is markedly different from the rest of the repo, so I don't think I can merge this as-is -- but I will push a commit that simplifies parallel hashing, with you as a co-author, if that's acceptable.

@lukechampine Feel free to re-mold as you like.

I'll point out that I find getting a Hasher back after a parallel file scan incredibly useful; it expands the usefulness of the functionality a great deal. For example, if I want to track a file's modification time (or other meta data) as well as its content, I can just add on (Write) the few bytes for the timestamp to the existing hasher and call Sum again. No need to repeat the expensive part.

Superceded by #25 -- thank you!