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