For string hashes the direction looks a lot like what I had in mind with an early working version of https://go-review.googlesource.com/c/go/+/148177/4 which wasn’t liked back then when send for review.

The new scope seems to be broader and generate wrappers for specific lengths on demand to deduce them but the direction of thought seems basically the same.

I’m happy to rework algs generation in that direction again by continuing the original intent of my CL linked above (and taking improvements from josh into account) into a new cl with more types and generating wrappers for specific lengths on demand to dedupe.

With Register based calling convention the additional call needed will also be cheaper so could be a better binary size and speed tradeoff.

For discussion of general approach: To generate code inside other types algs wont using a direct call to a type array alg with additional length argument be better then a closure?

On the larger question of direction, I guess let's let @randall77 weigh in.

To generate code inside other types algs wont using a direct call to a type array alg with additional length argument be better then a closure?

Definitely. The CL I linked is missing that and more, like the optimization to check all string lengths before checking any of their contents, and calling bytealg.Equal directly to compare contents.

Using a helper in runtime for arrays of common types seems fine. I think the objection in CL 148177 is that there were 2 changes, doing the previous sentence, and manually inlining strhash. It would be nice to split those up into 2 separate CLs so we can see the effect of each individually.

We'll still need to use a closure for functions which will be directly assigned to runtime._type.equal or runtime.maptype.hasher.

You've probably already seen this, but note the one possible complication for these optimizations is that for hashes, any optimized hashing needs to still match runtime.typehash exactly. See #37716.

Algs generally seem to be a good part of the compiler/runtime where more can be done. I will focus on them again (assigned this issue to me) and besides general cleanup and refactoring will look into:

• introducing functions processing arrays (also multiple struct fields) of hashes and equals (this issue)
• replacing use of strhash with memhash (will be easier for array algs and already done for equals)
• dereferencing types that wrap simple types e.g. [1]string and struct { string } into just the field type for hashes and equals. This avoids building or calling an extra alg function for single element arrays. single element arrays may come up in creation of backing arrays used for initialization of slice values.

I refactor my earlier https://golang.org/cl/148177 to take into account other improvements here and split out the dereferencing part.

After the above I think we can see whats left on the table and potentialy also look into masked memequals as a general concept to be used in the runtime/compiler: #41774

This issue has not been forgotten and is back on my list to be tackled for go1.18. Working on updating and syncing my existing CLs to HEAD.