Defining TOTAL_MEMORY and PTHREAD_POOL_SIZE at wasm instantiation time

[Gabriel Cuvillier]

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

[Derek Schuff]

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.

--
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-disc...@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.

[Gabriel Cuvillier]

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).

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAAEAhvfxeUzMBvMDJLZGUhZPEz6L38gTv8PL9bopu75%2Bd6R%3DYw%40mail.gmail.com.

[Alon Zakai]

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...

To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/219d740f-98dd-3eed-6bf0-50b43bf36e19%40gmail.com.