Indeed, useful stuff, thanks. Unfortunately cannot really use for this case as the issues are in the browsers and not in Emscripten.
2016. augusztus 1., hétfő 21:42:19 UTC+2 időpontban jj a következőt írta: > > Thanks - there is also --threadprofiler for -s USE_PTHREADS=1 builds, > which gives a glimpse to the utilization rate of threads and if some > threads might be deadlocked. The UI for each of these tools is developed > mostly based on specific demand in the past for being able to debug some > things (rather than a top down approach), so if there are some suggestions > to improve, feature requests are welcome. > > 2016-08-01 19:40 GMT+03:00 Floh <[email protected] <javascript:>>: > >> Wow I was totally not aware of the --memoryprofiler and --cpuprofiler >> flags, that's awesome! (I wish native build environment had something like >> this). >> >> Am Montag, 1. August 2016 12:14:27 UTC+2 schrieb jj: >>> >>> If it might be useful, Emscripten provides a built-in memory profiling >>> feature that allows you to get an overview of the application's memory >>> consumption. Use the linker flag `--memoryprofiler` to enable that for your >>> build. See here for an example: >>> http://clb.demon.fi/emcc/cpu_mem_profiler/hello_world_gles_cpu_mem_profiled.html >>> >>> (that one has also --cpuprofiler in it, which is the top block, >>> memoryprofiler is at the bottom). >>> >>> 2016-07-28 23:06 GMT+03:00 Alon Zakai <[email protected]>: >>> >>>> To set total memory at runtime, you can do the same in a worker as in >>>> the main thread, set Module.TOTAL_MEMORY. >>>> >>>> asm.js officially stopped supporting memory growth. It should be the >>>> same on all browsers - none should be doing asm.js opts when memory growth >>>> is used. Definitely chrome and firefox do not. (In WebAssembly we'll have >>>> memory growth fully optimized, so people are focusing on that.) >>>> >>>> On Thu, Jul 28, 2016 at 8:28 AM, 'Peter Nemeth' via emscripten-discuss >>>> <[email protected]> wrote: >>>> >>>>> Right, those were my thoughts as well. >>>>> >>>>> Meanwhile I've bumped into the limitations of large ArrayBuffers in 32 >>>>> bit buffers, i.e. even if I work out the required memory it can end up >>>>> being quite high which is not possible on 32 bit browsers. Based on my >>>>> tests the limits is around 0.5-1GB depending on the browser. Found some >>>>> relevant discussion here >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=927182 and here >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=965880 about virtual >>>>> address space, committed memory, etc. Also found this 32 bit related >>>>> initiative in Firefox: >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1277066 >>>>> >>>>> A few more questions: >>>>> - how to set the TOTAL_MEMORY for a worker at runtime? >>>>> - is it known in which browser does ALLOW_MEMORY_GROWTH disable >>>>> asm.js? I know Chrome has an issue ( >>>>> https://bugs.chromium.org/p/v8/issues/detail?id=3907) but what about >>>>> other? >>>>> - any experience with using WORKERFS in a 32 bit browser? How do Blobs >>>>> relate to the virtual address space, i.e. do browsers remove them from >>>>> the >>>>> address space when not in use or on tight memory? >>>>> >>>>> Thanks >>>>> >>>>> 2016. július 27., szerda 19:19:11 UTC+2 időpontban Alon Zakai a >>>>> következőt írta: >>>>>> >>>>>> Emscripten allocates an ArrayBuffer for memory. In principle, >>>>>> browsers call internally allocate it using calloc(), which would let >>>>>> most >>>>>> OSes only create physical pages when actually needed. However, in >>>>>> practice, >>>>>> some browsers have optimizations for the location of asm.js typed >>>>>> arrays, >>>>>> which can remove some bounds checks, but it does limit the effectiveness >>>>>> of >>>>>> calloc(). >>>>>> >>>>>> In general, it is best to assume that TOTAL_MEMORY will use physical >>>>>> memory immediately. Memory growth is an option to use memory more >>>>>> flexibly, >>>>>> but as you said, it has perf limittaions. >>>>>> >>>>>> On Wed, Jul 27, 2016 at 8:11 AM, 'Peter Nemeth' via >>>>>> emscripten-discuss <[email protected]> wrote: >>>>>> >>>>>>> I was digging this a bit more and it's not the browser but the OS. >>>>>>> What Activity Monitor / Task Manager shows is the resident memory. The >>>>>>> about:memory page of Firefox clearly shows everything related >>>>>>> (resident, >>>>>>> vsize, js engine, asm.js, ...). >>>>>>> >>>>>>> The questions still apply though. Can I rely on this in practice >>>>>>> (given the browser is 64 bit, 32 bit browsers are worse from this >>>>>>> point)? >>>>>>> Tips for production? >>>>>>> >>>>>>> >>>>>>> 2016. július 26., kedd 15:10:27 UTC+2 időpontban Peter Nemeth a >>>>>>> következőt írta: >>>>>>>> >>>>>>>> I'm trying to find out the best memory configuration for our >>>>>>>> application. It's using a lot of user generated content so we cannot >>>>>>>> be >>>>>>>> sure about the required TOTAL_MEMORY at compile time. We could >>>>>>>> calculate >>>>>>>> that upfront on the backend and set in the Module before loading but I >>>>>>>> would like to avoid that if possible. Also don't want to enable memory >>>>>>>> growth because of its performance drawbacks. After checking some >>>>>>>> browsers >>>>>>>> with a simple test it seems like they are smart enough not to allocate >>>>>>>> the >>>>>>>> whole buffer in C++ regardless the requested size of the ArrayBuffer. >>>>>>>> Do >>>>>>>> you know if this works in practice? How is Emscripten handling the >>>>>>>> HEAP >>>>>>>> stack-, and heap-wise? Where are they located in the HEAP? Any tips >>>>>>>> from >>>>>>>> production applications how they solve memory configuration? >>>>>>>> >>>>>>> -- >>>>>>> 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.
