I don't know enough details here - what is 2 to 4 times slower, what are the two scenarios being compared?
On Sat, Dec 9, 2017 at 8:14 AM, <[email protected]> wrote: > 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]> 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-de >>> v/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]. >>> 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.
