Running 32-bit applications under 64-bit Windows, especially Vista SP2

Discussion in 'Windows 64bit' started by Guest, Jul 11, 2009.

  1. Guest

    Guest Guest

    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
     
    Guest, Jul 11, 2009
    #1
    1. Advertisements

  2. No, yes. There is no above/below concept for 32-bit applications. They get
    a 4GB pool, and that's that.
    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], Jul 13, 2009
    #2
    1. Advertisements

  3. Guest

    Guest Guest

    ..
    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
     
    Guest, Jul 14, 2009
    #3
  4. Guest

    Bo Persson Guest

    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
     
    Bo Persson, Jul 14, 2009
    #4
  5. 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?
    They don't.

    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], Jul 21, 2009
    #5
  6. Guest

    Guest Guest

    ..
    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.
    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.
    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.
    ..
    It's not immediately clear whether WOW64 or the BOINC client is
    responsible for deciding how independent these 4 GB spaces are.
    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.
    Robert Miles
     
    Guest, Jul 24, 2009
    #6
  7. Guest

    Dave Warren Guest

    In message <#cOu$>
    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.
     
    Dave Warren, Jul 24, 2009
    #7
  8. 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 [email protected] 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.

    I've never seen a crunching application use that much memory. [email protected]
    Enhanced usually uses between 30-50MB, Astropulse a bit more. Note that
    [email protected] don't seem to be sending out many Astropulse work units at present
    (all my machines are only getting [email protected] 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.
    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)?
    Is this supposed to mean something? It's complete gibberish.




    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.

    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.
    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], Jul 26, 2009
    #8
  9. Guest

    Guest Guest

    ..
    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
     
    Guest, Aug 6, 2009
    #9
  10. Guest

    Guest Guest

    The BOINC projects I'm subscribed to do not inclide [email protected],
    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.
    ..
    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 [email protected]
    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 [email protected],
    [email protected], 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.
    ..
    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.
    ..
    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.
    As a service on my 32-bit machine, but not also on my 64-bit machine.
    ..
    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.
    ..
    I have the 64-bit client, but nearly all of the application programs for
    specific workunits are available only in a 32-bit version.
    ..
    Thanks, the *32 imformation was much of what I needed.

    Robert Miles
     
    Guest, Aug 6, 2009
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.