The problem was in my code. I succeeded running the final wasm-merged code in the browser. But beside very simple cases where I see a gain, using this emcc compiled fast-code code merged with the Faust generated wasm modules shows big regressions (like 2 to 4 times slower...), I don't understand why ... Any hypothesis ?
Le mardi 28 novembre 2017 20:14:06 UTC+1, Alon Zakai a écrit : > > Hmm, wasm does trap on some float-to-int overflows and things like that, > but "index out of bounds" sounds like a memory access error - could be a > bug in the code being compiled. If it doens't look like that, I can debug a > testcase if you have one. > > On Tue, Nov 28, 2017 at 5:16 AM, <[email protected] <javascript:>> wrote: > >> Thanks, that works well. >> >> Now the 2 modules can be properly linked with wasm-merge and the >> resulting one compiled and instantiated in JS context. >> >> Next problem is this kind of error when running it : "RuntimeError: index >> out of bounds" when calling (for instance...) the fast_log10f function of >> the following code compiled to wasm with emcc 1.17.21 : >> https://raw.githubusercontent.com/grame-cncm/faust/master-dev/architecture/faust/dsp/fastmath.cpp >> >> Is there any specific precautions to take when compiling the fastmath.cpp >> code ? Range issues ? Anything else? >> >> Le lundi 27 novembre 2017 21:45:01 UTC+1, Alon Zakai a écrit : >>> >>> I think emscripten's LEGALIZE_JS_FFI option can help there, -s >>> LEGALIZE_JS_FFI=0 will make it not emit asm.js-compatible function types, >>> so it should have normal f32s. >>> >>> On Sat, Nov 25, 2017 at 3:54 AM, <[email protected]> wrote: >>> >>>> OK. I'll have to checkout for memory segments. And I had to change the >>>> import naming convention off our generated module to use "env". Now "call >>>> merge" are correctly generated. >>>> >>>> One issue still. The "fastmath" C++ module has 2 set of functions, one >>>> using "float" type and one using "double". The code is compiled with emcc >>>> -O3 -s WASM=1 -s SIDE_MODULE=1 xxx but the generated wast/wasm still uses >>>> f64 type even for "float" versions (doing float/double cast...). Why is >>>> that? Is there a way to correctly general f32 versions of the function >>>> when >>>> the original C++ code is using "float" ? >>>> >>>> Thanks. >>>> >>>> Le samedi 25 novembre 2017 03:33:09 UTC+1, Alon Zakai a écrit : >>>>> >>>>> Oh, they have memory segments - do you ensure they don't collide >>>>> manually? No need for runtime relocations? The merger should just work on >>>>> that, but it can't check for errors on it. >>>>> >>>>> The merger resolves imports and exports, if one module exports A and >>>>> the other imports env.A, then in the merged module that import becomes >>>>> something in the module that is called directly. This does make the >>>>> assumption that exports are on "env", which is the convention (wasm >>>>> imports/exports are a little odd in that imports have two components but >>>>> exports have one). See for example >>>>> >>>>> >>>>> https://github.com/WebAssembly/binaryen/blob/master/test/merge/fusing.wast >>>>> >>>>> which merged with >>>>> >>>>> >>>>> https://github.com/WebAssembly/binaryen/blob/master/test/merge/fusing.wast.toMerge >>>>> >>>>> results in >>>>> >>>>> >>>>> https://github.com/WebAssembly/binaryen/blob/master/test/merge/fusing.wast.combined >>>>> >>>>> >>>>> On Thu, Nov 23, 2017 at 6:22 AM, <[email protected]> wrote: >>>>> >>>>>> Both modules have memory segments. >>>>>> >>>>>> By asking the lines (import "env" "memoryBase" (global $memoryBase >>>>>> i32)) and (import "env" "tableBase" (global $tableBase i32)) in our >>>>>> generated oddly, the wasm-merge runs without errors. >>>>>> >>>>>> But I'm still not clear in how functions exported by one module (the >>>>>> fastmath version of math functions) can be imported (= used) but the >>>>>> other >>>>>> one? Is that possible? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Le mercredi 22 novembre 2017 19:08:03 UTC+1, Alon Zakai a écrit : >>>>>>> >>>>>>> We should support both 1 and 2, not hard, just hasn't been done yet. >>>>>>> >>>>>>> But first, let me ask about your use case: the "no memory base was >>>>>>> imported" message is too general (we should fix that), but it is there >>>>>>> because if there isn't a memory base, then memory isn't relocatable, >>>>>>> and we >>>>>>> can't merge memories. So that can only work if the modules don't have >>>>>>> memory segments. Is that the case for you, it's just code, not data? >>>>>>> >>>>>>> If you don't have data, then as a temporary workaround you can just >>>>>>> import the relocatable offsets, adding >>>>>>> >>>>>>> (import "env" "memoryBase" (global $memoryBase i32)) >>>>>>> (import "env" "tableBase" (global $tableBase i32)) >>>>>>> >>>>>>> But we should also make it work if those don't exist, assuming there >>>>>>> is no data. >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 22, 2017 at 2:20 AM, <[email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Our Faust compiler (faust.grame.fr) can directly generate wasm >>>>>>>> modules from the Faust DSP source code. We typically generate modules >>>>>>>> that >>>>>>>> need mathematical functions (log, sin, pow...) which are imported from >>>>>>>> the >>>>>>>> JS context (by generating the appropriate module "import" section). >>>>>>>> >>>>>>>> We would like to test our Faust generated wasm code using more >>>>>>>> optimized mathematical functions (so using a fast_log, fast_sin, >>>>>>>> fast_pow >>>>>>>> versions of the functions). Those functions are coded in a C++ file, >>>>>>>> then >>>>>>>> compiled as a wasm module using emcc -O3 -s WASM=1 -s >>>>>>>> SIDE_MODULE=1 fastmath.cpp -o fastmath.wasm. >>>>>>>> >>>>>>>> Then we tried to link the fastmath.wasm module using the wasm-merge >>>>>>>> tool, so doing (for a given pre-compiled Faust DSP filterBank.wasm >>>>>>>> module) >>>>>>>> : wasm-merge filterBank.wasm fastmath.wasm, but we get the error : >>>>>>>> "Fatal: no memory base was imported" >>>>>>>> >>>>>>>> 1) is the wasm-merge tool ready for that kind of use case? If yes >>>>>>>> how it should be used? >>>>>>>> >>>>>>>> 2) will the wasm-merge code be part of the binaryen.js library, so >>>>>>>> that liking wasm modules could possibly dynamically be done in a Web >>>>>>>> page, >>>>>>>> or used in nodejs context for instance ? >>>>>>>> >>>>>>>> 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 [email protected]. >>>>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>> 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 [email protected] <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
