--
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/730a6796-5b14-4a9e-a1d8-298415c67cd1n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/86a9fc74-2036-4749-8212-29f6802615d0n%40googlegroups.com.
Thanks Alon! That explains it! Yeah I should have thought a little deeper.I am just posting my follow up question in case you did not get a chance to look at it.One follow up question. May be a dumb one. What could be the potential problems with ALLOW_MEMORY_GROWTH missing in PThreads mode? I see that when the Wasm is instantiated, the overall memory that the Chrome tab was taking was similar to the one taken by the WASM built with ALLOW_MEMORY_GROWTH. Is it that, we will not be able to instantiate WASM on low end devices if built with ALLOW_MEMORY_GROWTH=0?
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/9ddd4487-ff48-4b05-a138-900103ec2a4dn%40googlegroups.com.
My bad Alon! I will try to elaborate the scenario.I am trying to understand the implications of switching off ALLOW_MEMORY_GROWTH in our project. (which would be the case if we want PTHREADS enabled).The question is around, what if we set INITIAL_VALUE value to max value (2GB). Does that mean when WASM is instantiated with INITIAL_VALUE=2048MB, 2GB is reserved right upfront, even if not required right away? If yes, does that mean this will reduce the usable JS heap size (by 2GB), right from the beginning?
When I instantiate WASM (in my test app) with an INITIAL_VALUE=2000MB and check for the memory that specific webpage is taking, I see that page does not take 2GB but a lot lesser.
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/f197c8df-ba90-4f68-9018-3590303302ean%40googlegroups.com.
Thanks for the information Alon! That is exactly the information I wanted. Your theory of deferred memory usage pattern might be the reason for browsers reporting used memory differently.It is unfortunate that we will not be able to use PThreads in our main Wasm because of this limitation, as we have lot of JS running alongside Wasm. Any rough timeline on when we can expect ALLOW_MEMORY_GROWTH to work with PTHREADS?
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/a03fe2fa-6203-4342-8e1f-49edaeeac272n%40googlegroups.com.
root:WARNING: USE_PTHREADS + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271
That's interesting to know that ALLOW_MEMORY_GROWTH already works with PThreads. I will try to do some tests and see how that goes.Could you tell if there is any performance impact on writing strings (using Module._malloc()) or binary data to the heap, with ALLOW_MEMORY_GROWTH on PThreads. Also I am assuming there is no/very less impact of going from JS to C++ via ccall or embind. Please correct me if I am wrong.
Also upon enabling ALLOW_MEMORY_GROWTH on our project, there are lots of warning being thrown up in the console. Is there any switch that I could use to disable this warning?root:WARNING: USE_PTHREADS + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271
To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/4175ad68-aab5-4190-9463-749a4fec26den%40googlegroups.com.