«

When 32-bit applications run under 64-bit versions of
Windows, are they restricted to running in the lowest
4 GB of memory so that no memory mapping is needed,
or do the 64-bit versions of Windows provide enough
memory mapping that the programs can run when
located above 4 GB? I'm most interested in Vista SP2,
but would also like similar information about the other
64-bit versions of Windows.

If they cannot run above the 4 GB limit that 32-bit addresses
can specify, it seems that 64-bit Windows needs to offer
more information about which programs are using memory
below 4 GB, and how to tell which programs are running
in 32-bit mode and which in 64-bit mode.

Robert Miles

<> wrote:

>When 32-bit applications run under 64-bit versions of
>Windows, are they restricted to running in the lowest
>4 GB of memory so that no memory mapping is needed,
>or do the 64-bit versions of Windows provide enough
>memory mapping that the programs can run when
>located above 4 GB? I'm most interested in Vista SP2,
>but would also like similar information about the other
>64-bit versions of Windows.

No, yes. There is no above/below concept for 32-bit applications. They get
a 4GB pool, and that's that.

>If they cannot run above the 4 GB limit that 32-bit addresses
>can specify, it seems that 64-bit Windows needs to offer
>more information about which programs are using memory
>below 4 GB, and how to tell which programs are running
>in 32-bit mode and which in 64-bit mode.

They don't know they're running on 64-bit Windows, unless they're looking
specifically for that scenario (it can be detected). More importantly,
they don't generally need to know.

Where are these questions leading? What's the underlying scenario that's
brought them up?

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net

"Steve Foster [SBS MVP]" <> wrote in message
news...
> <> wrote:
>
>>When 32-bit applications run under 64-bit versions of
>>Windows, are they restricted to running in the lowest
>>4 GB of memory so that no memory mapping is needed,
>>or do the 64-bit versions of Windows provide enough
>>memory mapping that the programs can run when
>>located above 4 GB? I'm most interested in Vista SP2,
>>but would also like similar information about the other
>>64-bit versions of Windows.
>
> No, yes. There is no above/below concept for 32-bit applications. They get
> a 4GB pool, and that's that.
>
>>If they cannot run above the 4 GB limit that 32-bit addresses
>>can specify, it seems that 64-bit Windows needs to offer
>>more information about which programs are using memory
>>below 4 GB, and how to tell which programs are running
>>in 32-bit mode and which in 64-bit mode.
>
> They don't know they're running on 64-bit Windows, unless they're looking
> specifically for that scenario (it can be detected). More importantly,
> they don't generally need to know.
>
> Where are these questions leading? What's the underlying scenario that's
> brought them up?
>
> --
> Steve Foster [SBS MVP]
> ---------------------------------------
..
Trying to find a reason for the assorted problems I've seen on my 64-bit
8 GB computer for the assorted freezes and drastic slowdowns I often
see when running BOINC workunits, with BOINC allowed to use up
to 50% of the physical memory and with nearly all the workunits compiled
to run in 32-bit mode instead of 64-bit mode.

If all the 32-bit programs on the machine share one 4 GB pool, even
though there are 4 CPU cores within the CPU, that's a good enough
explanation, since I've seen no sign that BOINC applies any separate
memory usage limits to workunits running in 32-bit mode.

Asking for similar information for other 64-bit versions of Windows is
mainly intended to get help for the BOINC developers.

Robert Miles

wrote:
> "Steve Foster [SBS MVP]" <> wrote in
> message news...
>> <> wrote:
>>
>>> When 32-bit applications run under 64-bit versions of
>>> Windows, are they restricted to running in the lowest
>>> 4 GB of memory so that no memory mapping is needed,
>>> or do the 64-bit versions of Windows provide enough
>>> memory mapping that the programs can run when
>>> located above 4 GB? I'm most interested in Vista SP2,
>>> but would also like similar information about the other
>>> 64-bit versions of Windows.
>>
>> No, yes. There is no above/below concept for 32-bit applications.
>> They get a 4GB pool, and that's that.
>>
>>> If they cannot run above the 4 GB limit that 32-bit addresses
>>> can specify, it seems that 64-bit Windows needs to offer
>>> more information about which programs are using memory
>>> below 4 GB, and how to tell which programs are running
>>> in 32-bit mode and which in 64-bit mode.
>>
>> They don't know they're running on 64-bit Windows, unless they're
>> looking specifically for that scenario (it can be detected). More
>> importantly, they don't generally need to know.
>>
>> Where are these questions leading? What's the underlying scenario
>> that's brought them up?
>>
>> --
>> Steve Foster [SBS MVP]
>> ---------------------------------------
> .
> Trying to find a reason for the assorted problems I've seen on my
> 64-bit 8 GB computer for the assorted freezes and drastic slowdowns
> I often see when running BOINC workunits, with BOINC allowed to use
> up to 50% of the physical memory and with nearly all the workunits
> compiled to run in 32-bit mode instead of 64-bit mode.
>
> If all the 32-bit programs on the machine share one 4 GB pool, even
> though there are 4 CPU cores within the CPU, that's a good enough
> explanation, since I've seen no sign that BOINC applies any separate
> memory usage limits to workunits running in 32-bit mode.
>
> Asking for similar information for other 64-bit versions of Windows
> is mainly intended to get help for the BOINC developers.
>
> Robert Miles

Each program will get up to 4 GB of *virtual* address space,
independently of each other. The system will use RAM and disk, as
needed, to back up the use.

On the other hand, 4 programs actually using its 4 GB each will run
slower than a single program. The difference should show up as
increased disk activity.


Bo Persson

<> wrote:

>Trying to find a reason for the assorted problems I've seen on my 64-bit
>8 GB computer for the assorted freezes and drastic slowdowns I often
>see when running BOINC workunits, with BOINC allowed to use up
>to 50% of the physical memory and with nearly all the workunits compiled
>to run in 32-bit mode instead of 64-bit mode.

Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
clients - both process the same workunits (at least, AIUI).

If you shut down BOINC, do the freezes and slowdowns stop?

>
>If all the 32-bit programs on the machine share one 4 GB pool, even
>though there are 4 CPU cores within the CPU, that's a good enough
>explanation, since I've seen no sign that BOINC applies any separate
>memory usage limits to workunits running in 32-bit mode.

They don't.


>Asking for similar information for other 64-bit versions of Windows is
>mainly intended to get help for the BOINC developers.

All x64 versions of Windows use the same 32-bit subsystem - WOW64.

Since BOINC is available in both 32 and 64 bit versions, it'd make more
sense to run the 64-bit version if you're running Windows x64.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net

"Steve Foster [SBS MVP]" <> wrote in message
news...
> <> wrote:
>
>>Trying to find a reason for the assorted problems I've seen on my 64-bit
>>8 GB computer for the assorted freezes and drastic slowdowns I often
>>see when running BOINC workunits, with BOINC allowed to use up
>>to 50% of the physical memory and with nearly all the workunits compiled
>>to run in 32-bit mode instead of 64-bit mode.
>
> Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
> clients - both process the same workunits (at least, AIUI).
..
Looks like we aren't quite agreeing on the terminology to use. Each
workunit
specifies a workunit-specific program to run, with the BOINC client
controlling which workunits get to run at any particular time on each of the
CPU cores (and the GPU, if present), and which get at least virtual memory
reserved but are currently suspended. I'm not sure if it also controls
swapping
out the suspended workunits to the swap file. Nearly all the workunits
available for my field of interest specify 32-bit workunit-specific
programs.

The BOINC client uses only about 6 megabytes; the workunit-specific
programs often use much more (500 megabytes and up), with one
workunit-specific program supposed to be running on each CPU core at
any time.

There's also a BOINC manager program that acts as a user interface for
the BOINC client.
>
> If you shut down BOINC, do the freezes and slowdowns stop?
>
Hard for me to do without aborting all the workunits currently in progress -
the freezes and slowdowns usually also freeze or slow down the BOINC
manager program, and the process that starts it when you click on its
icon.

If I manage to suspend the BOINC client, and therefore all the
workunit-specific programs, I free the CPU time but not the memory
reserved for the various workunits. This does not stop the freezes and
slowdowns.
>>
>>If all the 32-bit programs on the machine share one 4 GB pool, even
>>though there are 4 CPU cores within the CPU, that's a good enough
>>explanation, since I've seen no sign that BOINC applies any separate
>>memory usage limits to workunits running in 32-bit mode.
>
> They don't.
>
Whether it's important depends on how independant the 4 GB space
assigned to each workunit using a 32-bit workunit specific program
is of the 4 GB space assigned to any other workunits, suspended or
not, assigned to the same CPU core, the 4 GB spaces assigned to
workunits assigned to different CPU cores, and of the 4 GB space
assigned to any other non-workunit 32-bit program running on the same
CPU core.
>
>>Asking for similar information for other 64-bit versions of Windows is
>>mainly intended to get help for the BOINC developers.
>
> All x64 versions of Windows use the same 32-bit subsystem - WOW64.
..
It's not immediately clear whether WOW64 or the BOINC client is
responsible for deciding how independent these 4 GB spaces are.
>
> Since BOINC is available in both 32 and 64 bit versions, it'd make more
> sense to run the 64-bit version if you're running Windows x64.
>
It's hard to tell the difference, but as far as I know I'm using a 64-bit
BOINC client, with nearly all the workunit-specific programs 32-bit.
I haven't found information on whether the BOINC manager program
is 32-bit or 64-bit.

For this reason, I'd like a way to tell the difference between 32-bit
programs and 64-bit programs if the program developers don't see
it useful to tell me which they are.
> --
> Steve Foster [SBS MVP]
> ---------------------------------------
> MVPs do not work for Microsoft. Please reply only to the newsgroups.
> For SSL Certificates, Domains, etc, visit.:
> https://netshop.virtual-isp.net

Robert Miles

In message <#cOu$>
<> was claimed to have wrote:

>For this reason, I'd like a way to tell the difference between 32-bit
>programs and 64-bit programs if the program developers don't see
>it useful to tell me which they are.

IIRC, boinc runs each WU in a separate process, correct? If so, modern
versions of Windows' Task Manager show a "*32" beside 32-bit processes.

However, whether an app is 32-bit or 64-bit is likely not related to any
lockups or stalls, I'd probably look to memory bandwidth saturation.

One other thought, you're not on a P4 based CPU are you? If so, turn
off Hyperthreading in the BIOS and see if the problem goes away.

<> wrote:

>"Steve Foster [SBS MVP]" <> wrote in message
>news...
>><> wrote:
>>
>>>Trying to find a reason for the assorted problems I've seen on my 64-bit
>>>8 GB computer for the assorted freezes and drastic slowdowns I often
>>>see when running BOINC workunits, with BOINC allowed to use up
>>>to 50% of the physical memory and with nearly all the workunits compiled
>>>to run in 32-bit mode instead of 64-bit mode.
>>
>>Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
>>clients - both process the same workunits (at least, AIUI).
>.
>Looks like we aren't quite agreeing on the terminology to use. Each
>workunit
>specifies a workunit-specific program to run, with the BOINC client
>controlling which workunits get to run at any particular time on each of
>the
>CPU cores (and the GPU, if present), and which get at least virtual memory
>reserved but are currently suspended. I'm not sure if it also controls
>swapping
>out the suspended workunits to the swap file. Nearly all the workunits
>available for my field of interest specify 32-bit workunit-specific
>programs.

Work units do not specify anything (other than what type they are).

The BOINC client downloads the right sort of application to process the
workunits automatically. I thought that the 64-bit BOINC client would
download 64-bit applications, but it appears that the SETI@Home folks
haven't written/ported these applications to x64 yet (on Windows at
least), so the BOINC client actually runs 32-bit crunching applications
regardless of whether it is 32 or 64 bit itself.


>The BOINC client uses only about 6 megabytes; the workunit-specific
>programs often use much more (500 megabytes and up), with one
>workunit-specific program supposed to be running on each CPU core at
>any time.

I've never seen a crunching application use that much memory. SETI@Home
Enhanced usually uses between 30-50MB, Astropulse a bit more. Note that
S@H don't seem to be sending out many Astropulse work units at present
(all my machines are only getting S@H Enhanced work units to process, and
have been for the last week or two).

If you let it, the BOINC client will indeed run an instance of the
crunching applications for each CPU core.

>There's also a BOINC manager program that acts as a user interface for
>the BOINC client.
>>
>>If you shut down BOINC, do the freezes and slowdowns stop?
>>
>Hard for me to do without aborting all the workunits currently in progress
>-
>the freezes and slowdowns usually also freeze or slow down the BOINC
>manager program, and the process that starts it when you click on its
>icon.

Stopping the BOINC client (and therefore the crunching applications) does
not abort work units. All computation carried out so far is preserved, and
work resumes from the same point when the BOINC client is restarted.
Obviously, if the BOINC client is down for too long, the deadline for
reporting completed units might expire, but those are generally fairly
generous.

Incidentally, do you run the BOINC client as a service (you have to
specify the Advanced settings during install to get it installed as a
service)?

>If I manage to suspend the BOINC client, and therefore all the
>workunit-specific programs, I free the CPU time but not the memory
>reserved for the various workunits. This does not stop the freezes and
>slowdowns.
>>>
>>>If all the 32-bit programs on the machine share one 4 GB pool, even
>>>though there are 4 CPU cores within the CPU, that's a good enough
>>>explanation, since I've seen no sign that BOINC applies any separate
>>>memory usage limits to workunits running in 32-bit mode.
>>
>>They don't.
>>
>Whether it's important depends on how independant the 4 GB space
>assigned to each workunit using a 32-bit workunit specific program
>is of the 4 GB space assigned to any other workunits, suspended or
>not, assigned to the same CPU core, the 4 GB spaces assigned to
>workunits assigned to different CPU cores, and of the 4 GB space
>assigned to any other non-workunit 32-bit program running on the same
>CPU core.

Is this supposed to mean something? It's complete gibberish.





>>>Asking for similar information for other 64-bit versions of Windows is
>>>mainly intended to get help for the BOINC developers.
>>
>>All x64 versions of Windows use the same 32-bit subsystem - WOW64.
>.
>It's not immediately clear whether WOW64 or the BOINC client is
>responsible for deciding how independent these 4 GB spaces are.

There is no decision to make. Every 32-bit application gets its own
distinct 4GB virtual memory space (ie each 32-bit application can request
a memory allocation of up to 4GB for itself [if it's LARGEMEMORYAWARE, 2GB
otherwise]). There is no sharing, no overlap, no CPU dependency, nothing.
The OS manages the memory allocation of RAM or paging file as the
applications request memory, just like every other Windows application.


>>Since BOINC is available in both 32 and 64 bit versions, it'd make more
>>sense to run the 64-bit version if you're running Windows x64.
>>
>It's hard to tell the difference, but as far as I know I'm using a 64-bit
>BOINC client, with nearly all the workunit-specific programs 32-bit.
>I haven't found information on whether the BOINC manager program
>is 32-bit or 64-bit.

If you downloaded the x64 version, you're running the 64-bit BOINC client.
As we've discovered (and discussed), that doesn't mean all the constituent
parts are x64.

>For this reason, I'd like a way to tell the difference between 32-bit
>programs and 64-bit programs if the program developers don't see
>it useful to tell me which they are.

You can tell whether any particular process is 32-bit or 64-bit from Task
Manager. 32-bit processes are marked with "*32" after the executable name,
64-bit processes have no suffix.

--
Steve Foster [SBS MVP]
---------------------------------------
MVPs do not work for Microsoft. Please reply only to the newsgroups.
For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net

"Dave Warren" <dave-> wrote in message
news:...
> In message <#cOu$>
> <> was claimed to have wrote:
>
>>For this reason, I'd like a way to tell the difference between 32-bit
>>programs and 64-bit programs if the program developers don't see
>>it useful to tell me which they are.
>
> IIRC, boinc runs each WU in a separate process, correct? If so, modern
> versions of Windows' Task Manager show a "*32" beside 32-bit processes.
>
> However, whether an app is 32-bit or 64-bit is likely not related to any
> lockups or stalls, I'd probably look to memory bandwidth saturation.
>
> One other thought, you're not on a P4 based CPU are you? If so, turn
> off Hyperthreading in the BIOS and see if the problem goes away.

..
Thank you.

I've now seen a similar problem on my 32-bit Vista SP2 machine,
which only has 2 GB. To me this suggests that the problem is
actually that BOINC can't handle using a full 50% of the memory
or more well. I've currently set it to allow BOINC to use only
40% of the physical memory on my 64-bit machine, and this seems
to have eliminated most of the hard faults and most of the slowdowns

How do I check for memory bandwidth problems?

The CPU is more recent than P4, has 4 CPU cores, and does not
have hyperthreading.

Robert Miles

"Steve Foster [SBS MVP]" <> wrote in message
news...
> <> wrote:
>
>>"Steve Foster [SBS MVP]" <> wrote in message
>>news.. .
>>><> wrote:
>>>
>>>>Trying to find a reason for the assorted problems I've seen on my 64-bit
>>>>8 GB computer for the assorted freezes and drastic slowdowns I often
>>>>see when running BOINC workunits, with BOINC allowed to use up
>>>>to 50% of the physical memory and with nearly all the workunits compiled
>>>>to run in 32-bit mode instead of 64-bit mode.
>>>
>>>Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
>>>clients - both process the same workunits (at least, AIUI).
>>.
>>Looks like we aren't quite agreeing on the terminology to use. Each
>>workunit
>>specifies a workunit-specific program to run, with the BOINC client
>>controlling which workunits get to run at any particular time on each of
>>the
>>CPU cores (and the GPU, if present), and which get at least virtual memory
>>reserved but are currently suspended. I'm not sure if it also controls
>>swapping
>>out the suspended workunits to the swap file. Nearly all the workunits
>>available for my field of interest specify 32-bit workunit-specific
>>programs.
>
> Work units do not specify anything (other than what type they are).
>
> The BOINC client downloads the right sort of application to process the
> workunits automatically. I thought that the 64-bit BOINC client would
> download 64-bit applications, but it appears that the SETI@Home folks
> haven't written/ported these applications to x64 yet (on Windows at
> least), so the BOINC client actually runs 32-bit crunching applications
> regardless of whether it is 32 or 64 bit itself.
>
The BOINC projects I'm subscribed to do not inclide SETI@Home,
and few if any of them have 64-bit applications ready to run their
workunits.

All of them seem to know that the 64-bit version of BOINC can run
workunits with only 32-bit applications ready, IF those applications
can be downloaded using the names the 64-bit applications should have
if they were ready.
>
>>The BOINC client uses only about 6 megabytes; the workunit-specific
>>programs often use much more (500 megabytes and up), with one
>>workunit-specific program supposed to be running on each CPU core at
>>any time.
>
> I've never seen a crunching application use that much memory. SETI@Home
> Enhanced usually uses between 30-50MB, Astropulse a bit more. Note that
> S@H don't seem to be sending out many Astropulse work units at present
> (all my machines are only getting S@H Enhanced work units to process, and
> have been for the last week or two).
..
I just saw The Lattice Project give me three workunits that required 750 MB
each to run the application; they sat to occasionally expect some that take
1 GB.
BOINC tried to run all three of the 750 MB workunits at the same time,
which may be part of ny recent problems I've heard that Superlink@Technion
also needs over 500 MB to run each workunit, but haven't been able to
observe
one in progress yet. I regularly have workunits from Rosetta@home,
RALPH@home, and some of the World Community Grid projects that take
500 MB to run. The application programs are probably smaller, but the total
memory they take to run is more important.
>
> If you let it, the BOINC client will indeed run an instance of the
> crunching applications for each CPU core.
..
I normally run a separate workunit on each of the 4 CPU cores; none of
the application programs can handle spreading work for the same
workunit to more than one CPU core.
>
>>There's also a BOINC manager program that acts as a user interface for
>>the BOINC client.
>>>
>>>If you shut down BOINC, do the freezes and slowdowns stop?
>>>
>>Hard for me to do without aborting all the workunits currently in
>>progress -
>>the freezes and slowdowns usually also freeze or slow down the BOINC
>>manager program, and the process that starts it when you click on its
>>icon.
>
> Stopping the BOINC client (and therefore the crunching applications) does
> not abort work units. All computation carried out so far is preserved, and
> work resumes from the same point when the BOINC client is restarted.
> Obviously, if the BOINC client is down for too long, the deadline for
> reporting completed units might expire, but those are generally fairly
> generous.
..
Then maybe I don't know enough about how to stop and restart it; the
way I'm familiar with does abort all the workunits in progress.
>
> Incidentally, do you run the BOINC client as a service (you have to
> specify the Advanced settings during install to get it installed as a
> service)?
>
As a service on my 32-bit machine, but not also on my 64-bit machine.
..
>>If I manage to suspend the BOINC client, and therefore all the
>>workunit-specific programs, I free the CPU time but not the memory
>>reserved for the various workunits. This does not stop the freezes and
>>slowdowns.
>>>>
>>>>If all the 32-bit programs on the machine share one 4 GB pool, even
>>>>though there are 4 CPU cores within the CPU, that's a good enough
>>>>explanation, since I've seen no sign that BOINC applies any separate
>>>>memory usage limits to workunits running in 32-bit mode.
>>>
>>>They don't.
>>>
>>Whether it's important depends on how independant the 4 GB space
>>assigned to each workunit using a 32-bit workunit specific program
>>is of the 4 GB space assigned to any other workunits, suspended or
>>not, assigned to the same CPU core, the 4 GB spaces assigned to
>>workunits assigned to different CPU cores, and of the 4 GB space
>>assigned to any other non-workunit 32-bit program running on the same
>>CPU core.
>
> Is this supposed to mean something? It's complete gibberish.
>
It was supposed to mean that the memory mapping for different workunits
that get time slices on the same CPU core might not be fully independent,
but it now seems more likely that BOINC is poor at assigning more than
50% of the physical memory at the same time.
>
>>>>Asking for similar information for other 64-bit versions of Windows is
>>>>mainly intended to get help for the BOINC developers.
>>>
>>>All x64 versions of Windows use the same 32-bit subsystem - WOW64.
>>.
>>It's not immediately clear whether WOW64 or the BOINC client is
>>responsible for deciding how independent these 4 GB spaces are.
>
> There is no decision to make. Every 32-bit application gets its own
> distinct 4GB virtual memory space (ie each 32-bit application can request
> a memory allocation of up to 4GB for itself [if it's LARGEMEMORYAWARE, 2GB
> otherwise]). There is no sharing, no overlap, no CPU dependency, nothing.
> The OS manages the memory allocation of RAM or paging file as the
> applications request memory, just like every other Windows application.
>
>
>>>Since BOINC is available in both 32 and 64 bit versions, it'd make more
>>>sense to run the 64-bit version if you're running Windows x64.
>>>
>>It's hard to tell the difference, but as far as I know I'm using a 64-bit
>>BOINC client, with nearly all the workunit-specific programs 32-bit.
>>I haven't found information on whether the BOINC manager program
>>is 32-bit or 64-bit.
>
> If you downloaded the x64 version, you're running the 64-bit BOINC client.
> As we've discovered (and discussed), that doesn't mean all the constituent
> parts are x64.
..
I have the 64-bit client, but nearly all of the application programs for
specific workunits are available only in a 32-bit version.
>
>>For this reason, I'd like a way to tell the difference between 32-bit
>>programs and 64-bit programs if the program developers don't see
>>it useful to tell me which they are.
>
> You can tell whether any particular process is 32-bit or 64-bit from Task
> Manager. 32-bit processes are marked with "*32" after the executable name,
> 64-bit processes have no suffix.
>
> --
> Steve Foster [SBS MVP]
> ---------------------------------------
> MVPs do not work for Microsoft. Please reply only to the newsgroups.
> For SSL Certificates, Domains, etc, visit.:
> https://netshop.virtual-isp.net
..
Thanks, the *32 imformation was much of what I needed.

Robert Miles