OK. "Looking at the generated IR code can confirm" ==> do you mean : LLVM IR yes ? I don't really understand how I can check the IR code then... Maybe we have to wait for the LLVM wasm backend to be ready, and compare the LLVM IR ==> wasm step (and speed of resulting code) with the speed of the code generated by our own direct Faust wasm backend?
Le mercredi 23 août 2017 20:53:23 UTC+1, Alon Zakai a écrit : > > It might be cache locality. Otherwise there is nothing magical about the > stack in both native code and wasm, it's just another region of memory, > reading and writing from it is the same as reading or writing anywhere else > (again, minus locality issues - which might be different in wasm). > > If not cache locality, it could be that the C++ compiler's optimizer > happens to do better on your stack version. Looking at the generated IR > code can confirm. This seems more likely to me. > > > On Wed, Aug 23, 2017 at 11:22 AM, <[email protected] <javascript:>> wrote: > >> Refining the question then (I'm discussion here at the Web Audio >> Conference with Paul Adenot working on WebAudio at Mozilla...). >> >> It appears that when compiling from Faust to a C++ class, having those >> arrays allocated on the stack (when we can afford it because they contain a >> state that does not live outside of the function scope), the code is faster >> compared to when we move those arrays as class fields. With Paul we were >> exploring reasons for that: better cache locality ? faster access of data >> allocated on the stack compared to the same data in the class field so >> allocated in the heap? >> >> Anyway: since in WebAssembly the stack is basically a part of the wasm >> module memory block, then is seems that we'll never be able to achieve this >> kind of "when compiled in C++, local stack data is faster to access than >> the same data on the heap..." property. Or is this part of the wasm >> compilation step strategy ? >> >> Paul told me that Luke Wagner of Benjamin Bouvier at Mozilla could >> possibly answer this kind of "wasm compilation strategy" questions. Do they >> read this group? >> >> Thanks. >> >> >> Le mardi 15 août 2017 16:50:28 UTC+1, Alon Zakai a écrit : >>> >>> Yes, in the end all the data has to live in the wasm memory (or in wasm >>> globals). So it's basically up to you how to use that memory, which is sort >>> of like defining your own ABI, if you choose not to use an existing one. >>> >>> On Tue, Aug 15, 2017 at 12:43 AM, <[email protected]> wrote: >>> >>>> We are directly compiling to wasm. Our code also generates a data >>>> structure with fields (scalar and arrays). A solution we may use for now >>>> is >>>> to move those stack allocated data in the structure, since I understand >>>> that in any case the data finally live in a wasm memory region (this this >>>> should not cause any performances changes yes ?). But having support in >>>> binaryen could be interesting, although it somewhat link the generated >>>> wasm >>>> model to binaryen API, something we may ant to avoid in case the generated >>>> module is deployed in another context. >>>> >>>> >>>> Le lundi 14 août 2017 18:42:40 UTC+2, Alon Zakai a écrit : >>>>> >>>>> What emscripten would do is set aside a range of memory for the stack, >>>>> and maintain a stack pointer. Then "foo" would be assigned a region at >>>>> the >>>>> top of the stack on entry to that function, and the stack would be >>>>> unwound >>>>> when the function is exited. >>>>> >>>>> Are you compiling directly to wasm yourself? Or to LLVM bitcode? If >>>>> bitcode then you can easily reuse the emscripten runtime to do a lot of >>>>> this for you. Otherwise you may need to do more yourself, but perhaps we >>>>> should find ways to make that easier (e.g., maybe in binaryen's APIs for >>>>> generating wasm we could add stack support). >>>>> >>>>> >>>>> On Mon, Aug 14, 2017 at 8:16 AM, <[email protected]> wrote: >>>>> >>>>>> OK. Then how the equivalent C code should be generated then ? Where >>>>>> is "foo" array memory supposed to be allocated ? >>>>>> >>>>>> void test() >>>>>> { >>>>>> float foo[36]; >>>>>> float* foo_ptr = &foo[4]; >>>>>> ... >>>>>> code that uses foo_ptr >>>>>> ... >>>>>> } >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Le lundi 14 août 2017 17:07:38 UTC+2, jj a écrit : >>>>>>> >>>>>>> Stack is optional. If you are targeting Wasm directly, you do not >>>>>>> need >>>>>>> to have a stack at all if your language domain does not need it. >>>>>>> What >>>>>>> Emscripten does with the stack is it blocks out a linear chunk of >>>>>>> memory at startup and calls that the stack, and whenever compiled >>>>>>> code >>>>>>> does things like takes the address of a local variable, it must be >>>>>>> pushed to the WebAssembly Memory out from a Wasm function local, so >>>>>>> that it can be referenced by a pointer in other functions. >>>>>>> WebAssembly >>>>>>> itself does not care about Emscripten's STACKTOP etc., but all it >>>>>>> operates on are the get_local and set_local type of opcodes for >>>>>>> function local data. >>>>>>> >>>>>>> 2017-08-14 17:18 GMT+03:00 <[email protected]>: >>>>>>> > Hi, >>>>>>> > >>>>>>> > We are compiling to wasm code from our Faust DSP compiler (so >>>>>>> producing our >>>>>>> > own wasm modules). >>>>>>> > >>>>>>> > In our wasm code, it is not clear yet how we could possibly define >>>>>>> stack >>>>>>> > allocated arrays. Compiling a C++ code example, I see that >>>>>>> Emscripten >>>>>>> > runtime code has some stack operations (like >>>>>>> > stackSave/stackAlloc/stackRestore...) and generates stack related >>>>>>> code in >>>>>>> > the function header. So I understand that Emscripten runtime >>>>>>> allocates a >>>>>>> > block of memory to be used for the stack yes?, but what to do in >>>>>>> if we don't >>>>>>> > interact with the Emscripten runtime? Do we need to manage our own >>>>>>> stack in >>>>>>> > a similar way as Emscripten runtime does? Or are they any simpler >>>>>>> > recommended way? >>>>>>> > >>>>>>> > Thanks. >>>>>>> > >>>>>>> > Stéphane Letz >>>>>>> > >>>>>>> > -- >>>>>>> > 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.
