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.
Le dimanche 20 août 2017 03:07:40 UTC+1, Alon Zakai a écrit : > > 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. > > > > On Sat, Aug 19, 2017 at 1:49 PM, <le...@grame.fr <javascript:>> wrote: > >> 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 ? >> >> >> Le vendredi 18 août 2017 08:45:35 UTC+1, le...@grame.fr a écrit : >>> >>> - 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/ >>>>> <http://faust.grame.fr/modules/faustlive-wasm.html>) 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+unsubscr...@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+unsubscr...@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+unsubscr...@googlegroups.com <javascript:>. >> 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
