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
<[email protected] <mailto:[email protected]>> 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 [email protected]
<mailto:emscripten-discuss%[email protected]>.
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 [email protected]
<mailto:[email protected]>.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/emscripten-discuss/219d740f-98dd-3eed-6bf0-50b43bf36e19%40gmail.com.
