CL https://golang.org/cl/32990 mentions this issue.

Just for future reference, what's the distribution of sizes on adler32 inputs? For sufficiently large inputs it can be computed in parallel (I have done this myself) which is another way of improving performance. The same can be done with somewhat more hair for CRC calculations.

There are really cases when inputs are GBs/sec. So parallelism is great, but hey, you want everything to be slow just because modern CPUs have 8+ cores typically?

adler32 is used in the zlib format and in many other places (see imports: https://godoc.org/hash/adler32?importers). The size of the inputs probably varies very widely, so I don't think it is appropriate to make the adler32 implementation parallel by default. That said, I personally would be interested in seeing Combine functions added to the various hash packages. I tried pushing for that in #12297.

Divide-and-conquer parallelism usually has a minimum chunk size, so "not by default" is hardwired into the algorithm. I recall the minimum chunk size for adler32 was measured in megabytes, but that was using heavier-weight threads, not goroutines. The question is really more one of whether it is worth the programming effort.

@rsc, @ianlancetaylor, @griesemer, @randall77: decision needed: does adler32 warrant unsafe to get a 1.8x speedup?

I'm not convinced unsafe is needed in that optimization. Why can't it just use the wide integer load technique that binary.LittleEndian.Uint64 uses?

I'm not against unsafe per se here, but @dsnet's suggestion should be considered first.

The CL uses unsafe to do an 8-byte load instead of 8 1-byte loads. It has to be amd64-only because of unaligned loads (not valid on some other 64-bit systems). If we use encoding/binary to do the load, doesn't the compiler handle that optimization for us?

While unsafe would be fine here (because assembly would be fine here, given at least a 2X speedup), it may be that unsafe is not necessary and we can still get the speedup, because the compiler knows about the functions in encoding/binary and emits the best instructions it knows how, and in particular it knows how to get an 8-byte load from a byte slice.

Decision: try to do without unsafe first.

I have send a CL about it
https://go-review.googlesource.com/c/48270/

Change https://golang.org/cl/51850 mentions this issue: hash/adler32: add AMD64 optimized Adler32 calculation