I'm that person. Unlike 16-bit applications back in the day that expected to all exist within the same address space, 32-bit applications have always existed within separate address spaces. You actually have to go through great lengths to share information/memory between processes.
BOINC uses the generic CreateProcess/CreateProcessAsUser Windows API to launch 32-bit/64-bit applications. Windows handles the details as to whether or not to use WOW64 based on the executable header. In any case, both 32-bit and 64-bit applications expect to exist within their own virtualized address space by default. Which applications typically run when you experience this slow down issue you are experiencing? ----- Rom -----Original Message----- From: Robert Miles [mailto:[email protected]] Sent: Friday, April 27, 2012 5:55 PM To: [email protected] Cc: Rom Walton Subject: Re: boinc_dev Digest, Vol 95, Issue 22 It looks to me more like this is saying that 64-bit versions on Windows ALLOW methods of starting processes that will put each 32-bit process in a separate 32-bit address space, but nothing about whether BOINC actually uses these methods. Could we bring someone more familiar with the internals of 64-bit Windows BOINC clients into this discussion to say more about whether the clients actually use such methods? - Robert Miles . > > > -------- > > Date: Fri, 27 Apr 2012 13:51:10 -0400 > From: "Rom Walton"<[email protected]> > Subject: Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 20 > To:<[email protected]>, "Robert Miles" > <[email protected]> > > Microsoft provides a good starting place for this topic: > http://msdn.microsoft.com/en-us/library/aa384249(v=vs.85).aspx > > > From the looks of it, each process (32-bit/64-bit) is contained > > within a > separate virtualized 64-bit address space. 32-bit applications load > the additional WOW64 binaries to handle thunking. kernel handles only > contain 32-bits of relevant information so that they can be truncated > for use by 32-bit applications. > > ----- Rom > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Friday, April 27, 2012 1:24 PM > To: Robert Miles > Cc: [email protected]; [email protected] > Subject: Re: [boinc_dev] boinc_dev Digest, Vol 95, Issue 20 > > 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.
