I am going to speculate for a bit.

If 32 bit process handles do not translate from 32 bit apartment to a
different 32 bit apartment, then
1)  32 bit processes started by a 32 bit process will have to come out of
the same 4GB process space (yes, this includes the video space so some less
space for programs).  It may be true only if the parent process stores the
process handle of the child.
and
2)  A 32 bit process started by a 64 bit process can get a new 4GB process
space.

jm7


|------------>
| From:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Robert Miles <[email protected]>                                     
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |<[email protected]>                                                 
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |04/27/2012 12:33 PM                                                          
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 20                           
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by:   |
|------------>
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|
  |<[email protected]>                                         
                                                                     |
  
>--------------------------------------------------------------------------------------------------------------------------------------------------|





Then why have I sometimes seen 7 GB used at once when most of the programs
running were 64-bit non-BOINC programs, and without such a drastic
slowdown?

By the way, earlier today, I saw about 4.5 GB of 32-bit programs running
at once,
but enough were non-BOINC to suggest that the 3.5 GB limit I've seen
applies
mostly to BOINC programs.  Could this mean that 64-bit Windows BOINC crowds
all the 32-bit applications it starts into a single 32-bit memoryspace,
even if
running under a version of Windows that does not force such a restriction?
If so, the only other 32-bit programs affected could be those that
happen to run
on the same CPU core as the main BOINC client executable.  If that's the
case,
BOINC needs the ability to set the memory limit for the sum of all 32-bit
executables it runs to be less than the total it can use if 64-bit
executables are
included.

I haven't found a good chance yet to check if something similar happens if
all the workunits available are 64-bit, since such workunits are still
rather scarce.

-  Robert Miles

.
>
> ------------------------------
>
> Message: 6
> Date: Fri, 27 Apr 2012 10:23:01 -0400
> From: "Rom Walton"<[email protected]>
> Subject: Re: [boinc_dev] 32-bit workunits under 64-bit Windows
> To: "Robert Miles"<[email protected]>,
>            <[email protected]>
> Message-ID:
>
<[email protected]>
> Content-Type: text/plain;          charset="us-ascii"
>
> Sounds more like paging than anything else.  Each process is independent
> of each other.
>
> 32-bit processes are not treated like 16-bit tasks running under NTVDM
> back in the day.
>
> I suspect you'll find that the same thing happens when you start a few
> 64-bit processes that use a similar amount of memory.
>
> ----- Rom
>
> -----Original Message-----
> From: Robert Miles [mailto:[email protected]]
> Sent: Friday, April 27, 2012 9:57 AM
> To: [email protected]
> Cc: Rom Walton
> Subject: Re: [boinc_dev] 32-bit workunits under 64-bit Windows
>
>    The 3.5 GB is not for just one process.  It's the total for all 32-bit
> processes running at once, most of which are workunit applications.
>
> The hard drive is a little busy at such times - enough for the hard
> drive light to flash perhaps once a second.
>
> The best I can tell, at least one of the applications HP supplied for
> processing keyboard input is also 32-bit, and therefore more likely to
> be affected by crowding too much into the same 32-bit memoryspace.
>
> - Robert Miles
>
> -----
> Date: Wed, 25 Apr 2012 15:40:51 -0400
> From: "Rom Walton"<[email protected]>
> Subject: Re: [boinc_dev] 32-bit workunits under 64-bit Windows
>
> I'm confused. On Windows, out of the box, the largest amount of memory a
> single 32-bit program can allocate is 2GB (3GB with a special boot
> option). I believe that is even true on a 64-bit system.
>
> When your system starts to slow down, is the hard drive busy?  It sounds
> like what you are experiencing is paging related.
>
> ----- Rom
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Robert Miles
> Sent: Sunday, April 22, 2012 5:36 PM
> To: [email protected]
> Subject: [boinc_dev] 32-bit workunits under 64-bit Windows
>
> I've found that my computer tends to slow down user response quite a bit
> as the total memory used by 32-bit workunits and other 32-bit programs
> approaches 3.5 GB, as I'd expect if all 32-bit programs must fit within
> a single 4 GB memoryspace even though the computer has 8 GB of memory
> installed.  Could you check if this is actually what's happening,
> especially on 64-bit versions of Windows with the lower limits on the
> total amount of memory they can use?  If so, can you find a way to give
> each 32-bit workunit a separate 4 GB memoryspace, even if some of it is
> shared with other workunits?
>
> Another possibility is that the portions of the SysWOW64 software needed
> to run 32-bit programs is similar in size to the programs that need it,
> and therefore you should consider counting SysWOW64 software against the
> memory limit allowed for BOINC.  Or just count 32-bit workunits twice
> against the limit, but 64-bit workunits only once.  Or even allow
> setting the limit for 32-bit BOINC software and workunits to be lower
> than the total amount of memory BOINC can use.
>
> I'm using 64-bit Windows Vista Home Premium SP2 on that computer.  I
> haven't found any way to check which if either of the above
> possibilities is correct.  Currently using BOINC 7.0.25, but I have seen
> the same problem on earlier versions back to at least some of the 6.12.*
> versions.
>
> This may be a good reason for the more memory-hungry BOINC projects to
> start offering 64-bit applications, even if those 64-bit versions offer
> no performance improvements over the 32-bit versions.
>
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.




_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to