Array passing back and forth between JS and AS

[jbousquie]

Hello,

I'm one the core team member of the BabylonJS 3D framework (https://github.com/BabylonJS/Babylon.js) and I'm evaluating the opportunity to port some parts of BabylonJS to AS.
A 3D engine needs to compute fast many maths between two frames (so ideally in less than 16 milliseconds to get a framerate 60 fps) and to lower the GC impact for performance reasons.

In my test, I would like to :

• allocate once some big size-fixed float32 typed array. Say, more than 1 million floats. No matter where it's allocated, JS or WASM side, as long as it's shared and re-usable along the render loop
• populate this array with float32 values JS side once
  then each frame :
• update the array JS side with new values (new mesh coordinates along time)
• call an AS function that compute some trigonometry on this array values, store the results (million float32 also) in the array in a free reserved zode (note that we could also use 2 arrays, one for the input, the other for the output, as long as they remain allocated for ever, shared, accessible and uptadable/readable either from JS as from AS).
• read the results, so the updated shared array, from JS and copy these results to the WebGL buffer.

What I found so far in the Wiki or in the github issues is how to allocate an array AS side and return the pointer to JS, then to read its values with the right typed view or the right offset.
We are really concerned by allocating once only the memory and by sharing it between JS and AS. I guess that I unfortunately copied or reallocated the memory each call either JS side, either AS side as I didn't understand how to access the same initial array both sides in my AS test so far.

Would you please mind to provide a snippet JS and AS side to achieve this ? mainly, the creation of the persistent array among JS and TS and how to access it again and again along the computation calls then.

[dcodeIO]

In such a case, I'd most likely allocate a Float32Array on the JS side, use it as the memory of the WebAssembly module, and manually load<f32>(atOffset) / store<f32>(atOffset) them in AS to achieve the best performance. This way around you can access the values, without any sort of copying involved, by keeping a Float32Array view on the same buffer around on the JS side. When copying to a WebGL buffer, you'd then just .set the region of interest from WASM memory to a WebGL buffer to issue a memcpy.

If there's more memory necessary than just those f32 values, there's the --memoryBase compiler option that reserves a fixed amount of memory in front, while putting anything else (i.e. static strings or otherwise allocated on the AS side) behind, so with --memoryBase 4000000 there'd be enough space for 1.000.000 32-bit floats from offset 0 to 3999996.

It's not strictly necessary to import the memory, actually, as you could simply new Float32Array(myModule.memory.buffer, 0, 1000000) on the memory as well to obtain the view on the reserved f32 values after instantiating the module.

One thing to take care of, when keeping a view on the memory around in JS, is that if the WASM memory resizes (i.e. through a memory.grow instruction), that the view is invalidated because the original memory becomes detached (and a new view on the updated memory must be created). Pre-allocating a sufficient amount of pages works around this (see also).

[jbousquie]

Thank you for your fast answer and the warning about the memory resize concern :-)

Do you mean to load and to store float by float in a big loop ?
How to get AS side the pointer on the first position of the allocated Float32Array JS side ?

[dcodeIO]

Yeah, you'd simply write load<f32>(index << 2) in AS instead of myArray[index] in JS. Here, load simply compiles to a f32.load instruction. Same goes for store<f32>(index << 2, someValue).

The pointer in this case is index << 2, i.e. 0 for the first element (JS: myArray[0]), 4 for the second (JS: myArray[1]) etc. This works because your f32 array is at the beginning of the WASM memory. If you had two arrays (another one not starting at 0), you'd simply add its start offset, like so: load<f32>(startOffset + (index << 2)). If all array sizes are constant, you can also provide the start offset as an additional constant argument, like so: load<f32>(index << 2, startOffset), which is equivalent to f32.load offset=CONSTANT, if startOffset is constant.

Example:

const INPUT_START: usize = 0; // 500000 elements
const OUTPUT_START: usize = 4 * 500000; // 500000 elements

@inline function getInput(index: i32): f32 {
  return load<f32>(index << 2, INPUT_START);
}

@inline function setOutput(index: i32, value: f32): void {
  store<f32>(index << 2, value, OUTPUT_START);
}

The Game of Life example does something like this as well.

[kyr0]

Also:

WebAssembly/design#1231

[MaxGraey]

@jbousquie I do similar interop for earcut AS port. See this and this. Also you could do even faster and avoid TypedArray#set: WebAssembly/design#1231 (comment)

[kyr0]

@dcodeIO and @MaxGraey Are you fine with me implementing the WebAssembly/design#1231 proposals in lib/loader and PR?

[dcodeIO]

Possibly related: #136

Note though, that an implementation of getArray etc. would have one level of indirection, whereas the solution proposed here is as direct as it can get.

[MaxGraey]

@dcode I think much better use code-generation as postprocess for js <-> wasm interop like wasm-bindgen does.

[dcodeIO]

Well, that would still use the loader, or something very similar, for array interop, because arrays in AS can be at any offset anyway (with a buffer being referenced from anywhere), and there is no concept of a C-like static array in TS (hence the proposed load/store here).

[kyr0]

@MaxGraey Yeah, I was about to write another comment that code generation would be much better. But then I thought again... maybe not everybody wants to use a generated facade? So maybe having both options would be nice. Having it available in the lib, and code generation probably using this lib code.

[kyr0]

Well, that would still use the loader, or something very similar, for array interop, because arrays in AS can be at any offset anyway, and there is no concept of a C-like static array in TS (hence the proposed load/store here).

Yeah, and it would be cool if there would be a separation of the API's for the two different behaviors: copy or "pass-by-reference". And having both available in a simple, yet easy to understand way. And to put some docs towards this in the wiki etc. as I see more and more issues here popping up just to ask for help how to do it :)

[kyr0]

I'll write a PoC tonight... and maybe it is good or you decide to throw it ;)

[dcodeIO]

Also note that these things will become more convenient once reference-types/GC are there. With that, there can be typed array types on the AS side that can flow out to/in from JS naturally.

[kyr0]

Also note that these things will become more convenient once reference-types/GC are there. With that, there can be a typed array types on the AS side that can flow out to JS naturally.

Good point. I just feel that it is maybe a good idea not to wait until this lands in all WASM supporting engines as this might take some time.

But it basically means that the support for this should probably be flagged as experimental in the loader lib because the internal implementation will surely change once reference-types/GC lands and so will the lib's API as ptr arguments might not be necessary anymore by then (?)

But being one of the first projects to support passing TypedArrays between JS/WASM forth and back easily might be a big deal for this project as I guess many dev's are not soo much into "bit dancing" :))

[jbousquie]

thanks guys, I'll make a test these next days with your proposal :-)