On Sep 22, 2015, at 9:15 AM, Stéphane Letz <l...@grame.fr> wrote:
>>
>> It's true that in steady state, asm.js code probably won't allocate memory.
>> But I order to execute the code the engine will parse things, compile
>> things, and generate code - all of which requires memory allocation and may
>> acquire locks held by lower priority threads. So, using JSC from a real time
>> callback seems dangerous even if you're using asm.js.
>
> We perfectly know the "shape" of the generated asm.js code. Basically it has
> an "init" function called only once to init some internal state, then
> "compute" would be called the audio callback. See the "compute" function
> code of a simple example that does a "stereo" in/out process :
>
> function mydspModule(global, foreign, buffer) {
>
> 'use asm';
>
> var HEAP32 = new global.Int32Array(buffer);
> var HEAPF32 = new global.Float32Array(buffer);
>
> var imul = global.Math.imul;
> var log = global.Math.log;
>
> function fmodf(x, y) { x = +x; y = +y; return +(x % y); }
> function log10f(a) { a = +a; return +(+log(a) / +log(10.)); }
>
> function getNumInputs(dsp) {
> dsp = dsp | 0;
> return 2;
> }
>
> function getNumOutputs(dsp) {
> dsp = dsp | 0;
> return 2;
> }
>
> function classInit(dsp, samplingFreq) {
> dsp = dsp | 0;
> samplingFreq = samplingFreq | 0;
> }
>
> function instanceInit(dsp, samplingFreq) {
> dsp = dsp | 0;
> samplingFreq = samplingFreq | 0;
> HEAP32[dsp + 0 >> 2] = (samplingFreq | 0);
>
> }
>
> function init(dsp, samplingFreq) {
> dsp = dsp | 0;
> samplingFreq = samplingFreq | 0;
> classInit(dsp, samplingFreq);
> instanceInit(dsp, samplingFreq);
> }
>
> function setValue(dsp, offset, value) {
> dsp = dsp | 0;
> offset = offset | 0;
> value = +value;
> HEAPF32[dsp + offset >> 2] = value;
> }
>
> function getValue(dsp, offset) {
> dsp = dsp | 0;
> offset = offset | 0;
> return +HEAPF32[dsp + offset >> 2];
> }
>
> function compute(dsp, count, inputs, outputs) {
> dsp = dsp | 0;
> count = count | 0;
> inputs = inputs | 0;
> outputs = outputs | 0;
> var input0 = 0;
> var input1 = 0;
> var output0 = 0;
> var output1 = 0;
> var i = 0;
> input0 = (HEAP32[inputs + (0 << 2) >> 2] | 0);
> input1 = (HEAP32[inputs + (1 << 2) >> 2] | 0);
> output0 = (HEAP32[outputs + (0 << 2) >> 2] | 0);
> output1 = (HEAP32[outputs + (1 << 2) >> 2] | 0);
> for (i = 0; (((i | 0) < (count | 0)) | 0); i = (((i | 0) + 1) | 0)) {
> HEAPF32[output0 + ((i | 0) << 2) >> 2] = +(+(+(HEAPF32[input0 +
> ((i | 0) << 2) >> 2])));
> HEAPF32[output1 + ((i | 0) << 2) >> 2] = +(+(+(HEAPF32[input1 +
> ((i | 0) << 2) >> 2])));
> }
> }
>
> return { getNumInputs : getNumInputs, getNumOutputs : getNumOutputs,
> classInit : classInit, instanceInit : instanceInit, init : init, setValue :
> setValue, getValue : getValue, compute : compute };
> }
Doesn't matter what shape the code is. Parsing and compiling code requires
memory allocation. JSC will parse and compile the code lazily, so we will
continue to allocate memory after the code has already started executing.
>
>>
>>>
>>> - what would be the most efficient manner to transfer C float arrays to the
>>> asm.js code and back? Is there a way to completely avoid copies during the
>>> process? Since JavaScriptCore can be used using a Objective C API (but not
>>> pure C API right?) do we need to use intermediate Objective C arrays to
>>> transfer data?
>>
>> Would this help: https://bugs.webkit.org/show_bug.cgi?id=120112
>
> 1) do you mean "Typed Arrays API" is a "work in progress" thing? If yes any
> idea when it could be part of an WekKet release ? OSX release? iOS release?
We don't usually make such predictions. It would be useful to know if this API
would help your use case.
>
> 2) should I understand also that JavaScriptCore can be used using a pure C
> API, not having to use Objective C API?
Yes.
>
> Thanks.
>
> Stéphane
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
