Re: Native code function call overhead vs webassembly

In general, you get pretty good JS/wasm and wasm/JS intercalling
performance if the JS code has been jitted and accepts known types (as will
happen once you've run the code a few times), and if the JS compiler can
determine the types you'll also get good performance of the JS code.  (And
if performance remains poor we'd probably like to hear about it.)  If you
have a large library already and don't want to port it to C++, I would
probably stick with this code until profiling shows that the overheads are
unaffordable.

However, you're likely to see better performance by converting the code to
C++ and compiling that to wasm.  Procedure call overheads will be
significantly lower - it's not cheap to cross the wasm/JS boundary even in
the best case - and the C++ compiler is likely to have more sophisticated
optimizations than the JS jit, as well as better type information to work
from, and it will need to insert no run-time type guards.

(A final possibility is to port to C++ and then compile the C++ into the
wasm engine, and invoke it using custom instructions, but this is rather a
large project.)

--lars

On Mon, Mar 8, 2021 at 9:00 AM Bellaz89 <[email protected]> wrote:

> Hi everyone,
>
> I am working with an application that uses SM78 as its scripting engine.
> This application has a bunch of mathematical libraries in pure JS that I
> want to port to emscripten/webassembly. I see that some years ago progress
> was made in improving the call overhead between JS <-> webassembly (
> https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/).
> This is highly beneficial for me. However, I wonder how this compares to
> functions/modules implemented using the native code interface in C++. How
> much is the native code call overhead? How does it compare to webassembly?
> Is there an advantage in using one solution (wasm or native c++) for
> 'short' functions?
>
> Thanks in advantage and sorry if the question is a bit vague.
>
> Andrea
> _______________________________________________
> dev-tech-js-engine mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>