Skip to content
This repository was archived by the owner on Apr 25, 2025. It is now read-only.
This repository was archived by the owner on Apr 25, 2025. It is now read-only.

"Optimized" bulk array instructions, e.g. array.new_copy #367

Open

Description

@Liedtke

This is a follow-up to #313 (comment) where the question was raised whether we'd need or want to have an array.new_copy instruction.

We have a micro-benchmark mainly consisting of copying an existing array.
Right now, the sequence is array.new_default followed by an array.copy.

There are two options to skip the default initialization of the array:

  1. We rely on engines detecting such patterns and optimizing it (e.g. skipping initialization if the array.new is followed by an array.copy with the same bounds as the array.new.)
  2. Adding a new instruction array.new_copy that combines the two, relying on code generators / tool chains to make sure to use these instructions in such cases.

A second very common use case is growing a backing store. For that we'd need at least one more parameter which is the size of the new array. To make it more universally useful, I tried to collect use cases for "create a new array based on (some) contents of an existing array":

  1. Copy an array.
  2. Grow a backing store.
  3. Slice an array. (Array.prototype.slice in JS or arr[a:b] in Python)

Now there could be also use cases where the content of the source array would not appear at the beginning, although those should be rather rare, one example would be "test".rjust(6, "x") in Python which would produce xxtest. (assuming using 1 Byte ASCII arrays)

If we wanted to support all these use cases with an "optimized" instruction, we'd end up with the following parameters:
(source_array, source_start_index, copy_length, target_start_index, target_length, default_value)
with some constraints like copy_length <= min(target_start_index + target_length, array.len(source_array) + source_start_index).

At least for use-case (1) this would already feel unnecessarily complicated to just copy an array.

How do people feel about this? Should it be the responsibility of the engine to optimize such patterns or should WebAssembly provide more specific instructions to be able to express the desired semantic in a more specific way?
And would we be interested in having an array.new_copy as part of the MVP?

Activity

  1. tlively commented on May 2, 2023

    @tlively
    Member

    We discussed this at the meeting this morning and decided more complicated bulk array instructions like this would be in-scope for a post-MVP proposal.

  2. mkustermann commented on Nov 1, 2024

    @mkustermann

    Apart from the fusion of array creation & copy instructions, a array.new_copy instruction would be very valuable to create arrays of const field types:

    Right now one cannot create arrays with const field types of unknown length. The length currently has to be known at compile type and has to be below 10k and the array has to be created using array.new_fixed.

    => A new array.new_copy instruction could solve this limitation by allowing to create const array types of arbitrary length from mutable arrays. See #570

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Post-MVPIdeas for Post-MVP extensions

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions