asm-js / validator

A reference validator for asm.js.
Apache License 2.0
1.78k stars 148 forks source link

Support typed arrays as parameters #51

Open kersam-bl opened 11 years ago

kersam-bl commented 11 years ago

It would be great if typed arrays could be used as parameters for functions written in asm.js.

Why? In order to speed up image processing algorithms, asm.js would be an ideal candidate. To accomplish that, you need some way to pass the image data to the asm.js code. The image data is usually provided by .getImageData() which returns an object containing the image in an UInt8ClampedArray. It would be great when we could pass this data directly to asm.js

kripken commented 11 years ago

You can copy them in now using typed array .set(). (Also, you likely anyhow do not want to do processing on a clamped array for speed purposes, I think?)

asm.js currently wants to bind tightly to its typed array, for speed purposes, so passing over a new one each call would not fit that model.

pyalot commented 9 years ago

Not acceptable. Man ctypes, actually useful FFI. Passing in arrays is a mandatory feature.

asm.js currently wants to bind tightly to its typed array, for speed purposes, so passing over a new one each call would not fit that model.

The fuck?!

kripken commented 9 years ago

The asm.js model is very simple: a singleton typed array for data storage. This is what makes it super-easy to optimize to native-like speeds.

If the asm spec allowed passing in typed arrays, accessing them would necessary entail the usual type checks, bound checks, bailouts, etc. - meaning it would not run at typical asm.js speed. It could still run pretty fast, because modern JS engines are fast. But it couldn't benefit from the predictable level of performance you can expect from asm.js.

But the important thing is that the singleton typed array in asm.js is not owned by it - it's a normal typed array, accessible from outside the asm module as well. That means you can access other typed arrays in outside code, and that code can also access the asm.js typed array,

var asm = (function asmModule(buffer, stdlib, ffi) {
  "use asm";
  // ...
})(buffer, stdlib, ffi);

function extFunction(newArray) {
  // operations on both buffer and newArray
}

That extFunction can run very quickly. Not typical asm.js speed, but still, if all it does is access some typed arrays and so basic math, that is stuff that modern JS engines can optimize well. And that speed is basically the limit - you couldn't get better from writing that code in asm.

Therefore, there isn't a strong reason to add passing in new arrays to asm code.

ghost commented 9 years ago

With non-trivial effort (and thus significant justification required), asm.js modules could have a second heap:

function f(stdlib, ffis, buffer1, buffer2) { "use asm"; ... }

The existing change heap asm.js extension could then be used to arbitrarily swap buffer1 and buffer2. Thus, you could change-heap buffer2 to the result of getImageData() and then pound on this in a subsequent asm.js function call.

I'm not sure how this would be reflected in C++/Emscripten, though. In particular, every heap access would need to statically know which heap to load from and there is no natural way I know of to express this in C++ since the memory model assumes a single linear address space. Some sort of extra annotations would be required (or a bunch of EM_ASM).