Re: 32-bit programs on Windows x64
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Thu, 03 Jul 2008 15:37:43 -0400
It is wrong, for the same reasons I gave. It is apparently cribbed from the same
erroneous root information.
I have no idea where they came up with those silly numbers for "paged pool" and "non-paged
pool". They are not even correct in Win32. Perhaps it is referring to the amount of
KERNEL address space which can be in the paged pool (which is not the same as the pageable
memory, and does not at all relate in any meaningful way to any parameter you might
conceivably care about) and the amount which can be in the non-paged pool (the limit
mentioned was fixed in a Win2K service pack years ago and is much larger than the number
quoted; perhaps they were using an obsolete version of Solomon & Russinovich to get the
number). No user program knows or cares about the kernel address space and how it is
split up between the paged pool and the nonpaged pool, but note that the potentially
pageable memory is all that matters in terms of user performance, and this is nearly all
the memory that is on the system.
The limits of VM are erroneous in that they tell about the total address space available,
and this has ZERO impact on user code. The CORRECT statements that affect user code are
the ones I gave: Win32 processes can have 2GB/3GB of VM and Win64 processes can have 8TB
of memory; and Win32 processes on Win64 can have 4GB of VM.
Articles like this merely serve to confuse instead of inform.
And I still don't know what a "system cache" is; that seems to be a term invented by the
author of this article, and would not be recognized by anyone else.
What strikes me as odd is the apparent desire to continue using Win32 as an implementation
strategy for a program that requires massive amounts of data space. If it were coded
credibly, converting it to Win64 (even 2.5Mlines) would take only a couple months.
I've converted 100K lines of correctly-written code in less than a day, and it would have
taken less time if I hadn't been obsessive about removing all the (superfluous) warnings
about value truncation caused by APIs that should have known better.
joe
On Thu, 3 Jul 2008 11:12:02 -0700 (PDT), PeteOlcott <PeteOlcott@xxxxxxxxx> wrote:
On Jul 3, 11:12 am, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:Joseph M. Newcomer [MVP]
Wrong
On Thu, 3 Jul 2008 06:17:36 -0700 (PDT), PeteOlcott <PeteOlc...@xxxxxxxxx> wrote:
On Jul 3, 7:52 am, Tim Slattery <Slatter...@xxxxxxx> wrote:
"Peter Olcott" <NoS...@xxxxxxxxxxxxx> wrote:
Can two 32-bit programs each have access to 4.0 GB of RAM,
if there is 8.0 GB of RAM on the system?
On a 32-bit system, each process gets a 4GB virtual memory space. At
any time, bits of this space are in physical RAM, or on disk, or
noplace (since they haven't been allocated yet). The OS keeps track of
where everything is.
If you've got 8GB of RAM, then you must have a 64-bit system. I'm not
sure what the virtual memory space for each process is on a 64-bit
system, but I'm sure it's much larger than the 4GB, 32-bit limit.
Either way, the amount of physical RAM is *not* a limiting factor.
Since with more physical RAM you can have more bits of the VM spaces
in RAM, things will run faster. But things will continue to run even
with small amounts of physical RAM, just more slowly.
--
Tim Slattery
MS MVP(Shell/User)
Slatter...@xxxxxxxxxxx://members.cox.net/slatteryt
64-bit vs. 32-bit architecture
Address space 64-bit Windows 32-bit Windows
Virtual memory 16 terabytes 4 GB
****
8TB user 2GB/3GB user
This is probably based on the erroneous information provided in
http://technet.microsoft.com/en-us/library/bb496995(TechNet.10).aspx
which incorrectly states
"The 64-bit versions of Windows operating systems support up to 16 terabytes of random
access memory (RAM) whereas 32-bit versions can only support up to 4 gigabytes."
This statement is so egregiously wrong that it is mind-boggling. It confuses virtual
address space (VM) with physical address space (RAM) and confuses total address space with
available user address space. 32-bit Windows provides 4GB of virtual address space but in
Win32-based systems, the upper 2GB/1GB is reserved for the operating system and is not
available for user processes. In Win64, the total VM space is 16TB but only 8TB is
available for a user program.
The correct statement would be
"The 64-bit versions of Windows operating systems provide up to 8TB of user virtual memory
whereas 32-bit versions provide only 2GB or 3GB of user virtual memory (depending on boot
configuration)"
*****>Paging file 512 terabytes 16 terabytes
****
But does it matter? The real limit on the paging
file size is the physical disk space available to it,
so to get 16TB of paging space you would need
enough disk space to hold it. This is typically
impractical, so the practical limit of paging space
is usually under 1TB. The theoretical upper limit
is irrelevant, so why worry about it? And have you
really thought of the performance hit if you had
512TB of VM in use on any real machine?
****>Paged pool 128 GB 470 MB
****
not true; the paged pool/nonpaged pool trade off
dynamically, and the non-paged pool
is limited to 80% of the physical address space
Furthermore, pages can move between the paged pool
and the nonpaged pool because you can't do I/O on
pageable pages down in the kernel, so while a page is
a target of an I/O operation, it is temporarily placed
in the nonpaged pool (conceptually)
****>Non-paged pool 128 GB 256 MB
****
not true; the nonpaged pool is everything that is not in
the paged pool, and is limited by physical memory
(nominally 80%). Furthermore, at any given instant,
some number of pages from the paged pool are
temporarily assigned to the nonpaged pool because
they are I/O target pages.
****>System cache 1 terabyte 1 GB
****
what is a system cache? I never heard of it.
There's an L2 cache (hardware), L1 cache (hardware)
and file system cache (software) among other caches.
The file system cache trades off with the paged pool
and cannot exceed it. So you are not going to get
a file system cache that can exceed physical memory.
****
What I am trying to confirm is whether or not 32-bit applications are
limited to being placed in the lowest 4.0 GB of RAM, thus the total
available RAM available to all 32-bit applications could possibly be
constrained to 4.0 GB. Alternatively, each application could have its
virtual address space map to as much as 4.0 GB of actual RAM. I am
guessing that the latter is true.
****
You really need to understand the concept of virtual memory. It is VIRTUAL. It does not
exist except in the imagination of the processor (as established by the page tables and
the Translation Lookaside Buffer, or TLB). I suggest any basic book on operating systems.
There is no restriction about memory placement, even on 32-bit machines; you are
constantly confusing physical and virtual memory, and they are not related. There is no
limitation on the total number of processes no matter what their VM size is. In Win64,
each 32-bit process has a maximum limit of 4GB of virtual memory, and the amount of
physical memory does not even enter the discussion until you start worrying about paging
performance. The total amount of physical RAM is just a random parameter unrelated to
virtual memory. I could run 40 2GB processes on a 512MB machine. Performance would suck,
but I could run them. There is no correlation between virtual addresses and physical
addresses, and in the course of execution, a particular page in VM might appear in
hundreds or thousands of different physical addresses which can be anywhere in the
physical address space (or, to be precise, anywhere in the paged pool, a concept that
itself changes many times per second)
Once you look under the covers, such as in device drivers, life gets a lot more
interesting because the amount of physical RAM available becomes an important parameter in
the design of a device driver, but that's a concern only to device driver writers (e.g.,
you can't lock down (make temporarily part of the non-paged pool) all the pages of a 1GB
user buffer in a 512MB machine, so you have to deal with "mode neither", handle "partial
MDLs" and do your own "MmProbeAndLockPages" and do it only from "passive level" instead of
"dispatch level" which involves using a "system thread" or "dedicated driver thread", and
locked-down memory is physically discontiguous even if virtually contiguous, which leads
to the need to manage "scatter-gather DMA". Absolutely NONE of this is visible at user
level. (I just covered about two hours' of lecture from my driver course in this
paragraph).
joe
****
Joseph M. Newcomer [MVP]
email: newco...@xxxxxxxxxxxx
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm- Hide quoted text -
- Show quoted text -
Here is the link
http://www.microsoft.com/windowsxp/64bit/facts/top10.mspx
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- 32-bit programs on Windows x64
- From: Peter Olcott
- Re: 32-bit programs on Windows x64
- From: Tim Slattery
- Re: 32-bit programs on Windows x64
- From: PeteOlcott
- Re: 32-bit programs on Windows x64
- From: Joseph M . Newcomer
- Re: 32-bit programs on Windows x64
- From: PeteOlcott
- 32-bit programs on Windows x64
- Prev by Date: Re: Cannot run program on computer without Visual Studio installed?
- Next by Date: Re: Cannot run program on computer without Visual Studio installed?
- Previous by thread: Re: 32-bit programs on Windows x64
- Next by thread: Re: 32-bit programs on Windows x64
- Index(es):
Relevant Pages
|
