Optimize/streamline fill operations

[ncruces]

This optimizes/streamlines fill operations.

Backstory:

• since 1.21 we have a clear builtin which is faster than copy when zeroing memory
• slices.Repeat uses a copy loop very similar to the one we're using
• bytes.Repeat does the same, but adds an 8KB maximum to the chunk size
• the existing generated code could be streamlined

Intuition:

• rare that tables are much larger than 8KB
• using clear (actually runtime.memclrNoHeapPointers) from native code is harder
• favor smaller/simpler code for tables, faster code for memory (like the standard library)

For the compiler:

• streamline/simplify table.fill
• optimize memory.fill using the 8KB maximum chunk size

For the interpreter:

• keep table.fill unchanged
• optimize memory.fill with both clear and maximum chunk size

For table.Grow:

• recognize that zero initialization is already done

Results:

I could measure an over 2x improvement filling megabytes of memory, with no degradation in performance at small sizes. No increase of generated code size.

Future work:

Using memory.fill to zero memory is very common. If we could access runtime.memclrNoHeapPointers in the compiler, we could potentially gain another 25% there (especially if we optimized this when zero is known at compile time).

[mathetake]

Fantastic

[ncruces]

That was way faster than I expected. 😂
I kinda expected this to be torn to pieces.

It has since occured to me that ((i - 1) & 8191) + 1 might not be better than min(i, 8192). Wdyt?

I know very little of the back ends to know what generates better code. “Branches are bad, conditional moves not so much” is the advanced-ness of my understanding.