All,
How much memory a 32bit server running Windows 2003 Server edition can address?
Rgds,
MK
Depends on what edition.
Have a look at this. What Windows will actually SEE in 32-bit editions is a bit different.
Also, have a read through Physical Address Extensions (PAE) which, as others have mentioned, allows 32-bit Windows to address more than 4 GB of memory.
4 GiB for Standard edition (with PAE). Otherwise:
http://technet.microsoft.com/en-us/library/cc758523(WS.10).aspx
64 GiB is the absolute maximum for the 32bit versions. I think that limitation is the limitation in PAE.
This is how you calculate it
2^32 = 4294967296 bytes .
Related
I know this question seems obvious, but I don't manage to find a precise answer.
If on my laptop it is written "Windows 8 64 bit", what "64 bit" exactly refers to? (I know that "Windows 8" is just the name and version of the OS).
I have a few interpretations, but none of them make me entirely happy:
The virtual address space of a process is of size 2^64 units (with unit being some small size). This definition does not make me happy, because even with disc storage, the total storage of my computer is far less than that. So I would never be able in a program to initialize an array of size 2^64.
The registers in memory have a capacity of 64 bits. This also does not make me entirely happy, because my machine could have both 64 bit and 32 bit registers, and perhaps registers of smaller size.
The maximum capacity of registers is 64 bits. This definition could be sensible, but looks "iffy".
So could anyone give me a clear definition, or at least tell that one of the above is correct?
"Windows 64 bit" means that the operating system supports 64-bit addressing.
This, in turn, implies that the CPU also supports 64-bit addressing.
The OS and the CPU are two entirely different things.
Runtime binaries (.exes and .dlls for Windows) are yet another "different thing". 32-bit and 64-bit .exe's have different binary formats, are loaded differently by the OS, and use different runtime resources.
You can't run a 64-bit OS on a 32-bit CPU. But you can run a 32-bit OS on a 64-bit CPU. Similarly, you can't use a 64-bit shared library or executable program on a 32-bit OS.
The key aspect of "64-bit" is 64-bit addressing: that both the CPU and the running program can address up to 2^64 bytes of virtual memory:
In practice, a running program will likely be able to address only a portion of that address space.
You can read more here:
https://en.wikipedia.org/wiki/64-bit_computing
PS:
Yes: CPU registers come in all different sizes. For example, ah is 8-bits, ax 16 bits, eax 32 bits and rax is 64 bits. Furthermore, different registers do "different things". For "64-bit computing", we're primarily interested in those registers that load from and store to virtual memory.
Until now I thought that a 32-bit processor can use 4 GiB of memory because 232 is 4 GiB, but this approach means processor have word size = 1 byte. So a process with 32-bit program counter can address 232 different memory words and hence we have 4 GiB.
But if a processor has word size larger than 1 byte, which is the case with most of processors now days I believe (My understanding is that word size is equal to the width of data bus, so a processor with 64-bit data bus must have a word size = 8 bytes).
Now same processor with 32 bit Program counter can address 2^32 different memory words, but in this case word size is 8 bytes hence it can address more memory which contradicts with 4 GiB thing, so what is wrong in my argument ?
Your premise is incorrect. 32-bit architectures can address more than 4GB of memory, just like most (if not all) 8-bit microcontrollers can use more than 256 bytes of memory. Indeed a 32-bit program counter can address 232 different memory locations, but word-addressable memory is only used in architectures for very special purposes like DSPs or antique architectures in the past. Modern architectures for general computing all use byte-addressable memory
See Why byte-addressable memory and not 4-byte-addressable memory?
Even in 32-bit byte-addressable architectures there are many ways to access more than 4GB of memory. For example 64-bit JVM can address 32GB of memory with 32-bit pointer using compressed Oops. See the Trick behind JVM's compressed Oops
32-bit x86 CPUs can also address 64GB (or more in later versions) of memory with PAE. It basically adds a another level of indirection in the TLB with a few more bits in the address. That allows the whole system to access more than 4GB of memory. However the pointers in applications are still 32-bit long so each process is still limited to 4GB at most. The analog on ARM is LPAE.
The 4GB address space of each process is often split into user and kernel space (before Meltdown), hence limited the user memory even more. There are several ways to workaround this
Spawning multiple processes, which is used in Adobe Premiere CS4
Mapping the needed part of memory into the current address space, like Address Windowing Extensions on Windows
...
CPU (at least x86 family 32-bit) must be able to access any byte/word/dword in 4GB space. So an instruction is encoded such a way that target word size and memory address (usually) belong to different bit-fields. So it doesn't matter whether CPU accesses byte or dword, but the encoded memory address must be the same.
Note that 32-bit OS and x86 CPU technically is able to acccess more than 4GB address space using PAE mode. But it is not supported by, say, the current Windows OS family (except Server editions). Some versions of WinXP, as well as Linux and other 32-bit OS can address 64GB of memory on x86 CPU.
Also, usually OS reserves some part of virtual address space (for OS kernel, Video memory etc.), so user programs may use, say, no more than 3 GB of RAM of the 4GB an OS can address within each process.
I'm a beginner. I came across an article, http://en.wikipedia.org/wiki/Physical_Address_Extension
Though I could partially understand it, I couldn't understand the practical advantage of increasing the physical address. Could anyone kindly explain it? Thank you.
Increasing the physical address space beyond 32 bits allows the operating system to access more than 4GB of memory. However, the virtual address space (pointer size) is still 32 bits, and applications need to use special APIs to change where their virtual address space addressed. PAE was a stopgap to allow applications to use more than 4GB of memory on a 32-bit processor.
There is no practical use for PAE today with the widespread implementation of x86-64, which has 64-bit pointers.
What is the limitation on the virtual address space available to a process ?
Is it
32 bit Vs 64 bit Address bus ?
32 bit vs 64 bit Processor ?
Secondary storage available ?
Maximum swap space configured ?
Thanks in advance
Secondary storage / swap space have nothing to do with it, because pages can be mapped into your address space without being allocated. And the same page can be mapped at multiple virtual addresses. ([edit] This is the default behavior, but the vm.overcommit_memory sysctl setting can be used to prevent the mapping of VM pages for which there is no RAM or swap available. Do a search on that sysctl setting for more information.)
The CPU certainly puts an upper limit, and that is essentially the only limit on 64-bit systems. Although note that current x86_64 processors do not actually let you use the entire 64-bit space.
On 32-bit Linux, things get more complicated. Older versions of Linux reserved 2GB of virtual space of each process for the kernel; newer ones reserve 1GB. (If memory serves, that is. I believe these are configurable when the kernel is compiled.) Whether you consider that space "available to a process" is a matter of semantics.
Linux also has a per-process resource limit RLIMIT_AS accessible via setrlimit and getrlimit.
The Memory that i'm trying to allocate is not huge or any thing. i just cant allocate
1.5 to 1.7 gigabyte of contagious memory. From what i know, windows gives you 2 gigabytes of virtual space to use in your application. so, a call like malloc(1500*1024*1024) is not totally crazy. i tried malloc ,new[], VirtualAlloc all didn't work.
is there something i'm missing here?
someone told me it has something to do with physical memory, i totally dismissed that because why was virtual space ,address translation tables and TLBs invented if i'm allocating physical memory.
if i'm allocating a 1.5 gig on a machine with 256 megabytes of ram and i try to access shouldn't the system be thrashing but working?
Different versions of Windows have different memory restrictions. If you're using a 32-bit version, you may need to use the 4GB tuning techniques to allocate more than 2GB.
If you are running a 32 bit version of windows, you have a max of 2Gb of virtual space. Your compiled programs and the C/C++ runtime libraries each use up some part of it, along with preallocated code and data segments. If you run a 32 bit windows, you have less memory space than you think. I'll agree that 1.5 Gb doesn't sound unreasonable, but then you would think that MS products weren't unreasonable, too, right?
Try samller pieces as a sanity check, (e.g., 1Gb); I suspect that will succeed. And try big allocations on a 64 bit system, where there isn't any practical upper limit.
Are you using ODBC? The ODBC dlls in 32-bit windows seem to insert themselves at an awkward place in the virtual address space, causing large allocations like yours to fail. A workaround is to configure your app to delay load the ODBC dlls, and then make sure you allocate your big chunk before you call anything that uses ODBC.