Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Liedtke opened this issue Apr 11, 2023 · 1 comment
Open

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

Liedtke opened this issue Apr 11, 2023 · 1 comment
Labels
Post-MVP Ideas for Post-MVP extensions

Comments

@Liedtke
Copy link

Liedtke commented Apr 11, 2023

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?

@tlively
Copy link
Member

tlively commented May 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Post-MVP Ideas for Post-MVP extensions
Projects
None yet
Development

No branches or pull requests

2 participants