Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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 alon...@gmail.com 
> wrote:
>
>> On Tue, Sep 1, 2020 at 9:20 AM Prashanth Nethi  
>> 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 alon...@gmail.com 
>>> wrote:
>>>
 On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi  
 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 alon...@gmail.com 
> wrote:
>
>> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi <
>> prashan...@gmail.com> 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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 alon...@gmail.com 
wrote:

> On Tue, Sep 1, 2020 at 9:20 AM Prashanth Nethi  
> 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 alon...@gmail.com 
>> wrote:
>>
>>> On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi  
>>> 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 alon...@gmail.com 
 wrote:

> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi  
> 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Tue, Sep 1, 2020 at 9:20 AM Prashanth Nethi 
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 alon...@gmail.com
> wrote:
>
>> On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi 
>> 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 alon...@gmail.com
>>> wrote:
>>>
 On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi 
 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 alon...@gmail.com
> wrote:
>
>> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
>> wrote:
>>
>>> Thanks Alon! That explains it! Yeah I should have thought a little

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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 alon...@gmail.com wrote:

> On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi  
> 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 alon...@gmail.com 
>> wrote:
>>
>>> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi  
>>> 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 alon...@gmail.com 
 wrote:

> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi  
> 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 
>> 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi 
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 alon...@gmail.com
> wrote:
>
>> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi 
>> 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 alon...@gmail.com
>>> wrote:
>>>
 On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
 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 alon...@gmail.com
> 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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?

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 alon...@gmail.com wrote:

> On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi  
> 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 alon...@gmail.com 
>> wrote:
>>
>>> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi  
>>> 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 alon...@gmail.com 
 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  
> 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi 
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 alon...@gmail.com
> wrote:
>
>> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
>> 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 alon...@gmail.com
>>> 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 
 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 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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. 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 alon...@gmail.com 
wrote:

> On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi  
> 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 alon...@gmail.com 
>> 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  
>>> 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 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 alon...@gmail.com 
 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi 
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 alon...@gmail.com
> 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 
>> 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 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 alon...@gmail.com
>>> 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 
 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 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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?

Regards,
Prashanth Nethi

On Thursday, August 27, 2020 at 2:37:07 AM UTC+5:30 alon...@gmail.com 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  
> 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 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 alon...@gmail.com 
>> 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  
>>> 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 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
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "emscripten-discuss" group.
>> To 

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

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 
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 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 alon...@gmail.com
> 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 
>> 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 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
>>> 
>>> .
>>>
>> --
> 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-discuss+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/emscripten-discuss/86a9fc74-2036-4749-8212-29f6802615d0n%40googlegroups.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 emscripten-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpSZx34yEBhiFv2P2syhoNKqnZo713ROhFMH8qa6G_8gHQ%40mail.gmail.com.

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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 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 alon...@gmail.com 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  
> 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 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
>>  
>> 
>> .
>>
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/86a9fc74-2036-4749-8212-29f6802615d0n%40googlegroups.com.

Re: WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Alon Zakai]

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 
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 emscripten-discuss+unsubscr...@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
> 
> .
>

-- 
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-discuss+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CAEX4NpTsvoiK%2ByUJCbr%3DKCDk7RMSg2YoakhLoiDB%2B2NF2Y0LBg%40mail.gmail.com.

WASM built with USING_PTHREADS=1 can't go beyond 1GB

[Prashanth Nethi]

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 emscripten-discuss+unsubscr...@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.