I'm very curious about the ArrayBuffer views into the Emscripten heap. That
sounds interesting. It could be that I'm just writing cancerous Emscripten
code :P
I'm also curious what you mean specifically by generating an array in
asm.js and then handing it off to JavaScript.
For reference, this is the code that I was using to test:
// main.cpp
// em++ --bind -std=c++11 -O3 -Wall -o emu.js main.cpp
#include <emscripten/val.h>
#include <emscripten/bind.h>
auto demo(size_t max, emscripten::val v) -> emscripten::val
{
for (size_t i = 0; i < max; ++i) {
v.set(i, i + 1);
}
return v;
}
EMSCRIPTEN_BINDINGS(emu)
{
emscripten::function("demo", &demo);
}
// demo.js
// node demo.js
'use strict';
const assert = require('assert');
const E = require('./emu');
const timer = function(f) {
const start = new Date().getTime();
f();
const end = new Date().getTime();
return (end - start);
};
const num_vals = 1000000;
const vanilla_demo = function(size, x) {
for (let i = 0; i < size; ++i) {
x[i] = (i + 1);
}
return x;
};
const emscripten_demo = E.demo;
const f = function() {
const x = [];
emscripten_demo(num_vals, x);
};
const g = function() {
const x = [];
vanilla_demo(num_vals, x);
};
console.log(`emscripten_demo: ${timer(f)}`);
console.log(`vanilla_demo: ${timer(g)}`);
On Thursday, January 5, 2017 at 2:04:02 AM UTC-8, jj wrote:
> Interopping between asm.js/wasm and regular JS is slow, since it crosses
> the boundary of two different compilation paths/backends in the JS engine.
> If you want to create a array as quickly as possible and use it from JS
> side, the fastest way is to generate the whole array in asm.js side in a
> tight loop that doesn't allocate memory, and then hand off the whole
> resulting array to JS side (offset+length of the array on the heap to JS,
> and typedArray.set() to copy its contents from the heap). Any kind of
> interop code should not be present in the tight loop to get best
> performance possible.
>
> 2017-01-05 6:12 GMT+02:00 ExBigBoss <[email protected] <javascript:>>:
>
>>
>>
>> On Tuesday, January 3, 2017 at 11:45:22 AM UTC-8, Charles Vaughn wrote:
>>>
>>> Do you have example code? Using emscripten::val with strings will have a
>>> very high overhead in terms of moving strings into and out of the
>>> Emscripten heap. If you're just looking at exposing large homogenous arrays
>>> of int's/floats/doubles you can use ArrayBuffer based views into the
>>> Emscripten heap.
>>>
>>> On Thursday, December 29, 2016 at 5:12:36 PM UTC-8, ExBigBoss wrote:
>>>>
>>>> So today I was writing an embound module and all it really did was set
>>>> the i'th property of an emscripten::val with the i + 1'th value. This was
>>>> done in a for-loop and in vanilla JS, I used simple for-loop with the
>>>> native array and its push method.
>>>>
>>>> Basically, I just wanted to test how fast I could fill an array using
>>>> Emscripten vs vanilla JS.
>>>>
>>>> However, I noticed that my code was 10x slower using emscripten::val!
>>>> And this was done with the -O3 flag being set as well. Using the default
>>>> wrapper around std::vector, I was able to generate asm that was 3x as fast
>>>> as vanilla JS but unfortunately, it doesn't play well with the standard
>>>> vector.
>>>>
>>>> I'm really just wondering, has anybody else noticed poor performance
>>>> when Emscripten and external JS inter-operate with each other?
>>>>
>>> --
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
