I think setting Module.TOTAL_MEMORY can work, but only if the wasm binary accepts it. If the binary has memory growth, then anything from the min to the max size is ok, but without growth, a wasm binary requires a single specific size and accepts nothing else. That does mean it's hard to adjust memory at runtime...
On Thu, Dec 5, 2019 at 1:41 AM Gabriel Cuvillier < gabriel.cuvill...@gmail.com> wrote: > Ok, that make sense. Maybe that's not possible. > > One workaround I am thinking of is to have several builds with different > memory and threading requirements: 64MB, 256MB, 512MB x 1 thread, 2 > threads, 4 threads, 8 threads. And instantiate one that best suit the data > to be processed and the capabilities of the host platform. > > Or maybe it is possible to 'inject' these values in the emscripten > generated .js file. For example, I can see a > "INITIAL_TOTAL_MEMORY=Module["TOTAL_MEMORY"]||536870912" and "var > requestedPoolSize=3" in my output .js file. I wonder if doing some > regexp/replace of these values would simply just work (of course, before > loading the .js file. This "hack" would be done on the server side before > delivering the .js). > > Le 04/12/2019 à 23:22, 'Derek Schuff' via emscripten-discuss a écrit : > > One possible issue with TOTAL_MEMORY IIRC is that the emscripten glue > tries to instantiate the wasm memory very early in script loading to > maximize the chance of getting the reservation of contiguous address space, > before the browser and VM have made so many allocations (believe it or not, > this made a big difference on 32-bit systems). So that might make it harder > to set dynamically. > > On Tue, Dec 3, 2019 at 2:50 AM Gabriel Cuvillier < > gabriel.cuvill...@gmail.com> wrote: > >> Hello, I have some question related to TOTAL_MEMORY and PTHREAD_POOL_SIZE: >> >> Is it possible to define (or override) these value at Wasm instantiation >> time, instead of at compilation/link time. >> >> The reason for TOTAL_MEMORY is the following: when compiling with >> threading support (USE_PTHREADS=1) we can't reliably use >> ALLOW_MEMORY_GROWTH due to potential performance issues, so we have to >> use a fixed memory size through TOTAL_MEMORY. But having to define >> fixed size memory at compilation/link time is not quite good for some >> scenarios as, at compilation time, we are generally lacking context >> about the data size to be processed (example: data size depends on an >> input file provided by the user). So in the end, defining TOTAL_MEMORY >> is mostly empirical/guesswork, and can lead either to crashes (not >> enough memory) or waste of memory on the client machine (too much >> reserved memory). >> >> At runtime however, when a Web App runs from JS space and before >> instantiating a .wasm, there is generally more context: it is sometime >> possible to know in advance how much memory would be needed to process >> some input data. So my question is: is it possible to define or override >> "TOTAL_MEMORY" at Wasm instanciation time? >> >> >> Same question for "PTHREAD_POOL_SIZE". Some C++ programs does not >> support well the fact that Worker threads initialization are >> asynchronous (or are they? I am not sure, but I ran into problems >> recently), and as so, it is preferable to let Emscripten runtime create >> a fixed number of Worker threads before the program starts. But, same >> issue here: it is not possible to know at compilation/link time the >> ideal number of threads to use on a client machine. Still, it is >> possible to have more information when the Web App runs (just have to >> query from JS), and before Wasm have to be started. So the question is: >> is it possible to define or override "PTHREAD_POOL_SIZE" at Wasm >> instantiation time ? >> >> >> Thanks for any insights ! >> >> Cheers, >> >> Gabriel >> >> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/emscripten-discuss/5061b1a4-cb00-59e7-d57b-75793c3e1c5a%40gmail.com >> . >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CAAEAhvfxeUzMBvMDJLZGUhZPEz6L38gTv8PL9bopu75%2Bd6R%3DYw%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAAEAhvfxeUzMBvMDJLZGUhZPEz6L38gTv8PL9bopu75%2Bd6R%3DYw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/219d740f-98dd-3eed-6bf0-50b43bf36e19%40gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/219d740f-98dd-3eed-6bf0-50b43bf36e19%40gmail.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSMjj%3DrcCYUfQUQwm5tPsKEb9XKi%3DT9UxywNUSb1ZvvWw%40mail.gmail.com.
