Hi Alon, I have raised a PR for disabling the USE_PTHREADS + ALLOW_MEMORY_GROWTH warning conditionally. https://github.com/emscripten-core/emscripten/pull/12103
Could you please have a look? Regards, Prashanth Nethi On Wednesday, September 2, 2020 at 5:02:18 PM UTC+5:30 Prashanth Nethi wrote: > Thanks for the information Alon. I would test out and share the results. > > Also I will try to see if I can put a PR for conditionally disabling the > ALLOW_MEMORY_GROWTH + USE_PTHREADS warning. > > Regards, > Prashanth > > On Tuesday, September 1, 2020 at 11:53:23 PM UTC+5:30 [email protected] > wrote: > >> On Tue, Sep 1, 2020 at 9:20 AM Prashanth Nethi <[email protected]> >> wrote: >> >>> 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. >>> >>> >> Writing data from JS to memory can be slower, including writing strings. >> But hopefully not by much. Nothing else should be affected. >> >> >>> 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 >>> >>> >> We could add a flag to allow disabling that warning. I think it could >> use diagnostics.warning() in emcc.py instead of just printing it >> unconditionally. A PR would be welcome, or an issue. >> >> >>> Thanks, >>> Prashanth >>> On Friday, August 28, 2020 at 10:15:38 PM UTC+5:30 [email protected] >>> wrote: >>> >>>> On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi <[email protected]> >>>> wrote: >>>> >>>>> 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? >>>>> >>>> >>>> It already works, but memory access from JS is somewhat slower. In most >>>> cases you won't notice that, though - unless you've already tested and see >>>> overhead? If so that could be useful to mention to the standards bodies >>>> that are considering a spec change that could improve this, it could >>>> increase the priority. >>>> >>>> - Alon >>>> >>>> >>>>> Also about checking the memory usage in devtools, I am using Chrome's >>>>> task manager as well as Activity Monitor (both on Mac) to check the >>>>> webpage's memory footprint. At both the places, the 2GB reserved memory >>>>> is >>>>> not getting reflected. Maybe I am missing on checking other relevant >>>>> fields. But that should be fine, as I got the required information from >>>>> you. >>>>> >>>>> Appreciate the help Alon! >>>>> >>>>> Thanks, >>>>> Prashanth Nethi >>>>> >>>>> On Friday, August 28, 2020 at 12:23:24 AM UTC+5:30 [email protected] >>>>> wrote: >>>>> >>>>>> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 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? >>>>>>> >>>>>> >>>>>> Yes, exactly. An initial value of X means X is allocated right from >>>>>> the start. Yes, this reduces available memory for other things, which >>>>>> can >>>>>> have downsides. >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>> >>>>>> How are you measuring that? >>>>>> >>>>>> It's possible the browser allocates that memory via calloc() or such, >>>>>> and maybe the OS doesn't actually use any physical memory until those >>>>>> pages >>>>>> are touched, though. So maybe only virtual memory is used initially. >>>>>> (But >>>>>> even that can cause problems on 32 bit due to address space limits.) >>>>>> >>>>>> Measuring via browser devtools should report the full 2GB is used >>>>>> immediately. >>>>>> >>>>>> >>>>>>> It is when I start acquiring more memory, the memory usage goes up >>>>>>> until it hits the 2GB limit. Surprisingly this is the same behaviour I >>>>>>> see >>>>>>> with ALLOW_MEMORY_GROWTH =1, USE_PTHREADS=0 (i.e. with PThreads >>>>>>> disabled). >>>>>>> So trying to understand the dynamics and come up with the >>>>>>> recommendation on >>>>>>> whether to enable or not enable PTHREADS in our app. FYI. The app has >>>>>>> the >>>>>>> requirement to load on various browsers and devices, with Chrome and >>>>>>> Chromebook being our majority targets. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Prashanth Nethi >>>>>>> >>>>>>> On Thursday, August 27, 2020 at 10:07:55 PM UTC+5:30 >>>>>>> [email protected] wrote: >>>>>>> >>>>>>>> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> 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? >>>>>>>>> >>>>>>>>> >>>>>>>> I'm not sure what you're asking here? >>>>>>>> >>>>>>>> In general, not having memory growth enabled means that memory >>>>>>>> can't grow. So if you need more than the initial value, the program >>>>>>>> will >>>>>>>> hit a problem. I don't think there's anything special to pthreads in >>>>>>>> that >>>>>>>> case. (The reverse, having growth *enabled*, does have downsides for >>>>>>>> pthreads as the JS use of memory becomes somewhat slower.) >>>>>>>> >>>>>>>> Regards, >>>>>>>>> Prashanth Nethi >>>>>>>>> >>>>>>>>> On Thursday, August 27, 2020 at 2:37:07 AM UTC+5:30 >>>>>>>>> [email protected] wrote: >>>>>>>>> >>>>>>>>>> My guess is that's because of the behavior of std::vector and how >>>>>>>>>> it resizes. Over those appends it will malloc and free repeatedly >>>>>>>>>> and that >>>>>>>>>> may cause fragmentation that prevents a final larger size, which >>>>>>>>>> must be a >>>>>>>>>> single contiguous region. The second version allocates many smaller >>>>>>>>>> ones, >>>>>>>>>> not a single contiguous region. >>>>>>>>>> >>>>>>>>>> - Alon >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Aug 25, 2020 at 11:24 PM Prashanth Nethi < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Thanks Alon! So here is something very weird. I could get the >>>>>>>>>>> memory usage go all the way to 2GB when I changed my testing code. >>>>>>>>>>> This was >>>>>>>>>>> my original test code. So basically I was just adding elements to >>>>>>>>>>> std::vector infinitely. >>>>>>>>>>> >>>>>>>>>>> class TestClass{ >>>>>>>>>>> private: >>>>>>>>>>> int t = 0; >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> struct Data { >>>>>>>>>>> int t; >>>>>>>>>>> TestClass obj; >>>>>>>>>>> }; >>>>>>>>>>> >>>>>>>>>>> typedef std::vector<Data> Vec; >>>>>>>>>>> >>>>>>>>>>> Vec someVec; >>>>>>>>>>> >>>>>>>>>>> using namespace std; >>>>>>>>>>> >>>>>>>>>>> int main() { >>>>>>>>>>> printf("hello, world!\n"); >>>>>>>>>>> >>>>>>>>>>> while(1){ >>>>>>>>>>> Data data; >>>>>>>>>>> someVec.push_back(data); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> return 0; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> With this code, the WASM memory was going all the way to 1GB. >>>>>>>>>>> >>>>>>>>>>> But when I changed the code to this, where I am writing some >>>>>>>>>>> value after acquiring memory, then I am able to see the memory >>>>>>>>>>> usage go all >>>>>>>>>>> the way up to 2 GB. Could this be a bug? I am on emscripten 2.0. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> int main() { >>>>>>>>>>> printf("hello, world!\n"); >>>>>>>>>>> char *p = nullptr; >>>>>>>>>>> int byteSize = 50 * 1024 * 1024; >>>>>>>>>>> while(1){ >>>>>>>>>>> p = new char(byteSize); >>>>>>>>>>> p[byteSize] = 20; >>>>>>>>>>> } >>>>>>>>>>> return 0; >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Also It is very encouraging to see that 4GB is considered for >>>>>>>>>>> PThreads as well! Thanks. >>>>>>>>>>> >>>>>>>>>>> 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? >>>>>>>>>>> >>>>>>>>>>> Greatly appreciate your help Alon! >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Prashanth Nethi >>>>>>>>>>> >>>>>>>>>>> On Saturday, August 22, 2020 at 1:50:57 AM UTC+5:30 >>>>>>>>>>> [email protected] wrote: >>>>>>>>>>> >>>>>>>>>>>> I think you can do any number up to 2GB, including 2GB - 64Kb. >>>>>>>>>>>> So the limit isn't 1GB, unless you see that on some specific >>>>>>>>>>>> browser? Could >>>>>>>>>>>> be a bug. >>>>>>>>>>>> >>>>>>>>>>>> It should soon be possible to do up to 4GB for the initial >>>>>>>>>>>> memory (without growth), thanks to a spec change, >>>>>>>>>>>> https://github.com/WebAssembly/spec/pull/1174 >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Aug 20, 2020 at 8:10 AM Prashanth Nethi < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I am currently building WASM with the following flags, to >>>>>>>>>>>>> enable PThreads in Wasm. >>>>>>>>>>>>> -s USING_PTHREADS=1 -s INITIAL_MEMORY=1999MB -s >>>>>>>>>>>>> MAXIMUM_MEMORY=2GB. >>>>>>>>>>>>> >>>>>>>>>>>>> This works wonderfully for our use cases! In fact we are able >>>>>>>>>>>>> to get 2x performance in some cases! >>>>>>>>>>>>> >>>>>>>>>>>>> When I checked the max memory that the Wasm could use, with >>>>>>>>>>>>> PThreads enabled, it got capped at 1 GB. I am seeing that when >>>>>>>>>>>>> the WASM is >>>>>>>>>>>>> built with ALLOW_MEMORY_GROWTH, the Wasm can use upto 2GB. I know >>>>>>>>>>>>> that >>>>>>>>>>>>> ALLOW_MEMORY_GROWTH with USE_PTHREADS is discouraged so can't >>>>>>>>>>>>> look at that >>>>>>>>>>>>> as a possible solution. >>>>>>>>>>>>> >>>>>>>>>>>>> Is there anyway I can get Wasm to use 2GB (or even potentially >>>>>>>>>>>>> 4GB in the future) with PThreads enabled? Is it that I am missing >>>>>>>>>>>>> using >>>>>>>>>>>>> some configuration options? >>>>>>>>>>>>> >>>>>>>>>>>>> I am really hoping there is a way to increase the WASM cap to >>>>>>>>>>>>> 2GB, as using PThreads, solves our use cases in a big way. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Prashanth Nethi >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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/730a6796-5b14-4a9e-a1d8-298415c67cd1n%40googlegroups.com >>>>>>>>>>>>> >>>>>>>>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/730a6796-5b14-4a9e-a1d8-298415c67cd1n%40googlegroups.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/86a9fc74-2036-4749-8212-29f6802615d0n%40googlegroups.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/86a9fc74-2036-4749-8212-29f6802615d0n%40googlegroups.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/9ddd4487-ff48-4b05-a138-900103ec2a4dn%40googlegroups.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/9ddd4487-ff48-4b05-a138-900103ec2a4dn%40googlegroups.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/f197c8df-ba90-4f68-9018-3590303302ean%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/emscripten-discuss/f197c8df-ba90-4f68-9018-3590303302ean%40googlegroups.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/a03fe2fa-6203-4342-8e1f-49edaeeac272n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/emscripten-discuss/a03fe2fa-6203-4342-8e1f-49edaeeac272n%40googlegroups.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/4175ad68-aab5-4190-9463-749a4fec26den%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/emscripten-discuss/4175ad68-aab5-4190-9463-749a4fec26den%40googlegroups.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/bdf87f5b-7497-49f5-959a-26053fc46edcn%40googlegroups.com.
