Optimization in binaryen.js library

[le...@grame.fr]

Hi, 

Our compiler directly generates (probably sub-optimal) wasm code. I see that then binaryen "optimize" in binaryen.js library could possibly be used to later optimize the code.

What kind of optimisation and so speed gain can be expect?  Will binaryen possibly to SIMD auto-vectorization optimisations in the future, when SIMD will be part of wasm spec ? Any other useful optimisation to expect ?

Thanks.

[Alon Zakai]

How faster and smaller binaryen can optimize code depends on the type of code, but often it makes a big difference, for example asm2wasm's hello worlds size shrinks to almost half. Speed gains can be similar. (See src/passes in binaryen for details of what optimizations it does.)

Autovectorization is definitely a possibility in the future, certainly worth exploring.

Btw, if you try binaryen's optimizer on your compiler's output, I'd be interested to see measurements on how it works. Feedback from different compilers is very helpful.

--
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 emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

Our compiler (for the Faust DSP audio language http://faust.grame.fr/) generates numerical processing code. Precompiled pages containing Faust generated WebAudio nodes can be found here: http://faust.grame.fr/modules/, using the RUN button to load actual pages with the JS + wasm WebAudio node. 

The compiler itself (compiled with Emscripten) is usable here: http://faust.grame.fr/modules/faustlive-wasm.html. URL for the DSP on the modules page can be used, by just doing a "drag/drop" from the "FAUST" button (the actual .dsp file URL) to the drop zone.

What measurements tools do you advice to use?

Thanks.

[Alon Zakai]

Interesting, I see. Yes, it does sound like autovectorization could be important for code like that.

I would measure code size after running binaryen's optimizer (say, wasm-opt -Oz) on your output. Or are these usually small programs anyhow, and code size isn't an issue for you? If you have existing benchmarks then measuring the speed of the optimized binaries is also interesting.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

- yes autovectorization usually helps a lot with this kind of code, as we can see when we produce C/C++ code from the Faust compiler.

- code size is usually not an issue, but speed is

- for speed measurement, should I simply use all Date.getTime kind of API ? Or are they any more sophisticated tools available in the different browsers ? (or Node.js maybe ?)

Thanks.

Le jeudi 17 août 2017 21:56:59 UTC+2, Alon Zakai a écrit :

Interesting, I see. Yes, it does sound like autovectorization could be important for code like that.

I would measure code size after running binaryen's optimizer (say, wasm-opt -Oz) on your output. Or are these usually small programs anyhow, and code size isn't an issue for you? If you have existing benchmarks then measuring the speed of the optimized binaries is also interesting.

On Thu, Aug 17, 2017 at 9:31 AM, <le...@grame.fr> wrote:

Our compiler (for the Faust DSP audio language http://faust.grame.fr/) generates numerical processing code. Precompiled pages containing Faust generated WebAudio nodes can be found here: http://faust.grame.fr/modules/, using the RUN button to load actual pages with the JS + wasm WebAudio node. 

The compiler itself (compiled with Emscripten) is usable here: http://faust.grame.fr/modules/faustlive-wasm.html. URL for the DSP on the modules page can be used, by just doing a "drag/drop" from the "FAUST" button (the actual .dsp file URL) to the drop zone.

What measurements tools do you advice to use?

Thanks.

Le jeudi 17 août 2017 17:14:50 UTC+2, Alon Zakai a écrit :

How faster and smaller binaryen can optimize code depends on the type of code, but often it makes a big difference, for example asm2wasm's hello worlds size shrinks to almost half. Speed gains can be similar. (See src/passes in binaryen for details of what optimizations it does.)

Autovectorization is definitely a possibility in the future, certainly worth exploring.

Btw, if you try binaryen's optimizer on your compiler's output, I'd be interested to see measurements on how it works. Feedback from different compilers is very helpful.

On Thu, Aug 17, 2017 at 6:44 AM, <le...@grame.fr> wrote:

Hi, 

Our compiler directly generates (probably sub-optimal) wasm code. I see that then binaryen "optimize" in binaryen.js library could possibly be used to later optimize the code.

What kind of optimisation and so speed gain can be expect?  Will binaryen possibly to SIMD auto-vectorization optimisations in the future, when SIMD will be part of wasm spec ? Any other useful optimisation to expect ?

Thanks.

--
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 emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

I did optimization tests on a bunch of Faust compiled DSP sources files, using wasp-opt (-03 or 0z), testing on nodejs (version 8.4.0) on OS X El capitan:

- something like 10 to 25% maximum save in binary code size

- using Date.getTime API to measure the actual audio DSP loop, I could not find any real change (results are noisy and can be better or worse by a few percents)

BTW, I guess the wasm module is finally optimized by the JS execution machine (in browsers or nodejs...) So what kind of gain with wasp-opt on speed can we expect? I mean what optimization passes that the final execution engine would not do itself ?

[Alon Zakai]

Thanks for the info. Makes sense to see that kind of size benefit, and I guess it's not surprising there isn't a speed difference in this type of code.

Yes, the VM will also optimize the code at runtime. But in general browsers are limited by speed (optimization passes need to be fast), correctness (they can't change behavior at all), and convention (they assume some opts are done beforehand).

For example, Binaryen has an inlining pass, and I believe most wasm VMs don't inline currently, they leave it to the toolchain. This might change eventually, but it make sense in that the toolchain might as well do it, and if it does then it's less work at runtime (faster) and also will be more consistent between VMs. Other optimizations done by Binaryen and not VMs include turning an if into a select and vice versa, a large set of bitwise optimizations (replace shifts with and etc.), etc.

Also, Binaryen can optionally optimize while ignoring traps (--ignore-implicit-traps). For example, every load and store might trap in theory, which limits how code can be reordered when preserving strict correctness. For code where those traps will never occur, this lets Binaryen do more things.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
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 emscripten-discuss+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[le...@grame.fr]

I see. 

Then I guess we can use the "wasp-opt" tool when we prepare wasm modules "statically" (that is in advance before deploying them in the Web). But I guess that when doing "dynamic compilation" (that is producing the wasm binary module on the fly with the embedded Faust compiler, as it is done in http://faust.grame.fr/modules/faustlive-wasm.html), then using the "binary.js" library inside the Web page make less sense, since there is nothing to gain on "code size" in this case, and there is no real gain in "code speed" for now.

To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 emscripten-discuss+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.