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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃洡 Bulk memory operations #1114

Closed
binji opened this Issue Jul 24, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@binji
Member

binji commented Jul 24, 2017

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic Bulk memory operations
Champion Ben Smith @binji
Status in progress
Phase Feature proposal
Linked issues #236 #977 #1057
Linked repositories bulk-memory-operations

Details

Copying and clearing large memory regions is very common, and making these
operations fast is architecture dependent. Although this can be done in the MVP
via i32.load and i32.store, this requires more bytes of code and forces VMs
to recognize the loops as well. The following operators can be added to improve
performance:

  • move_memory: Copy data from a source memory region to destination region;
    these regions may overlap: the copy is performed as if the source region was
    first copied to a temporary buffer, then the temporary buffer is copied to
    the destination region
  • set_memory: Set all bytes in a memory region to a given byte

We expect that WebAssembly producers will use these operations when the region
size is known to be large, and will use loads/stores otherwise.

@binji

This comment has been minimized.

Show comment
Hide comment
@binji
Member

binji commented Jul 24, 2017

@jfbastien jfbastien changed the title from Bulk memory operations to 馃洡 Bulk memory operations Jul 25, 2017

@WebAssembly WebAssembly locked and limited conversation to collaborators Jul 25, 2017

@binji binji self-assigned this Jul 27, 2017

@lars-t-hansen

This comment has been minimized.

Show comment
Hide comment
@lars-t-hansen

lars-t-hansen Aug 7, 2017

Contributor

I'm a little concerned about how the temp buffer interacts with shared memory and observability of reads and writes since, in practice, we'll want to avoid using such a buffer. Specifically, the agent that performs the copying creates an order s.t. all reads from the source and writes to the temp buffer are ordered before all reads from the temp buffer and writes to the destination. Another agent can be writing to the source and reading from the target to see what happens; almost certainly that agent can observe that the ordering implied by the temp buffer is violated.

Now, that violation might be allowed by the memory model anyway, since move_memory performs all racy reads and writes. (What memory model? I hear you ask :-) So no big deal, maybe.

Still, I have this nagging thought that we should perhaps spec move_memory by cases (not overlapping; overlapping with src <= target; overlapping with src > target) to avoid unnecessary confusion. Also it would clarify the performance aspect of the instruction somewhat better, since the redundant copy makes it seem more expensive than it is.

Contributor

lars-t-hansen commented Aug 7, 2017

I'm a little concerned about how the temp buffer interacts with shared memory and observability of reads and writes since, in practice, we'll want to avoid using such a buffer. Specifically, the agent that performs the copying creates an order s.t. all reads from the source and writes to the temp buffer are ordered before all reads from the temp buffer and writes to the destination. Another agent can be writing to the source and reading from the target to see what happens; almost certainly that agent can observe that the ordering implied by the temp buffer is violated.

Now, that violation might be allowed by the memory model anyway, since move_memory performs all racy reads and writes. (What memory model? I hear you ask :-) So no big deal, maybe.

Still, I have this nagging thought that we should perhaps spec move_memory by cases (not overlapping; overlapping with src <= target; overlapping with src > target) to avoid unnecessary confusion. Also it would clarify the performance aspect of the instruction somewhat better, since the redundant copy makes it seem more expensive than it is.

@binji

This comment has been minimized.

Show comment
Hide comment
@binji

binji Aug 7, 2017

Member

I wrote up a quick gist w/ some spec text here: https://gist.github.com/binji/acc43b94c0a747e51dfafa1b5b099c9a

This still uses a temp buffer, but I think it makes it clearer that it is just a spec implementation detail. Probably could add a note to that effect as well.

Member

binji commented Aug 7, 2017

I wrote up a quick gist w/ some spec text here: https://gist.github.com/binji/acc43b94c0a747e51dfafa1b5b099c9a

This still uses a temp buffer, but I think it makes it clearer that it is just a spec implementation detail. Probably could add a note to that effect as well.

@binji

This comment has been minimized.

Show comment
Hide comment
@binji
Member

binji commented Oct 16, 2018

@binji binji closed this Oct 16, 2018

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