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/99ae7133-0f1a-42d6-9964-4315c090aa14n%40googlegroups.com.
