Personal computing discussed
Moderators: renee, Flying Fox, Ryu Connor
Forge wrote:Hackery? Windows installs, boots, and runs fine with up to 4GB of RAM (there may be hardware ie motherboard limitations requiring slower memory settings or other tweaks). However, the upper ~.5GB is unavailable on 32bit Windows because that overlaps with the DMA area for PCI. 64bit Windows can remap the RAM in that area above the 4GB boundary so it can fully use all 4GB (Server editions of 32bt Windows are also able ot avoid the problem, but that does involve some minor hackery). But 32bit Windows doesn't have a "heart attack" even with 4GB, and will happily use 3GB or more (of course you have to have an application load that actually needs that much memory)..Windows is fine with >2.5GB of ram, also. You won't be able to use it as well on a 32bit version of Windows without some minor hackery, but it works fine, doesn't cause instability or demon possesion.
UberGerbil wrote:Forge wrote:Hackery? Windows installs, boots, and runs fine with up to 4GB of RAM (there may be hardware ie motherboard limitations requiring slower memory settings or other tweaks). However, the upper ~.5GB is unavailable on 32bit Windows because that overlaps with the DMA area for PCI. 64bit Windows can remap the RAM in that area above the 4GB boundary so it can fully use all 4GB (Server editions of 32bt Windows are also able ot avoid the problem, but that does involve some minor hackery). But 32bit Windows doesn't have a "heart attack" even with 4GB, and will happily use 3GB or more (of course you have to have an application load that actually needs that much memory)..Windows is fine with >2.5GB of ram, also. You won't be able to use it as well on a 32bit version of Windows without some minor hackery, but it works fine, doesn't cause instability or demon possesion.
fc34 wrote:Actually, you'll notice I said nothing about applications. Windows gives applications 2GB of virtual memory space. However, some specially-written apps can use more than this (the /3GB switch). In either case, however, this is independent of the amount of physical RAM present in the system. In many cases an app that has allocated 1GB or more of virtual memory isn't using that much physical memory; conversely an app (or the system as a whole) may be using more virtual memory than there is physical memory in the system (this is what the page file is for). And as I said, server versions of Windows can also work with more than 4GB of physical memory (up to 64GB depending on the version and of course motherboard support), even though apps are limited to 2 or 3GB of virtual memory and 32bit Windows itself is limited to 4GB (this is the minor hackery I was referring to, in the form of PAE in hardware and AWE in Windows).Actually, just as a side note, windows 32bit will only allow individual programs to use up to 2GB of RAM, although it does support up to 4GB of total RAM.
UberGerbil wrote:Well, Yonah (and Banias etc) are "modern" chips and they don't support PAE (though Sossaman apparently does) but that's a minor point; as you say, it comes down to chipset limitations and the chipsets for the Pentium M are rather limited in general.
Thankfully this all goes away in x86-64. Smooth flat address space out to 2^48 (for now), physical memory out to 2^40. Of course we'll still be fighting chipset limitations (and RAM slots, and board space...)
Buub wrote:Yes, and Dothan/Yonah support the XD/NX bit as well, which requires the third level of PTEs enabled by PAE. However, the older 400MHz bus versions of the Pentium M didn't have PAE (or XD/NX either), and it was late at night, which is why I misremembered. Anyway, it's moot because they aren't paired with a chipset that would allow more than 4GB of memory anyway.If I'm not mistaken, Dothan and Yonah support PAE, but they don't support x86-64.
Buub wrote:If I'm not mistaken, Dothan and Yonah support PAE, but they don't support x86-64.
Windows 64-bit can support massive GBs of RAM. To go over ~3.5GB of RAM with 32-bit Windows, you need to use PAE, and even then, that's a performance penalty. 32-bit programs that know how to make use of over 2GB of RAM are rare and restricted to mostly server apps (like SQL Server for example). Your average application isn't going to do it.
So the answer is, to make effective use of much more than 2~3GB of RAM, you'll want to be running a 64-bit version of Windows. If you're staying under 3GB, 32-bit Windows will be able to handle it.
Shintai wrote:I'd just like to say that that statement is chock-full with misinformation. That is all.Buub wrote:If I'm not mistaken, Dothan and Yonah support PAE, but they don't support x86-64.
Windows 64-bit can support massive GBs of RAM. To go over ~3.5GB of RAM with 32-bit Windows, you need to use PAE, and even then, that's a performance penalty. 32-bit programs that know how to make use of over 2GB of RAM are rare and restricted to mostly server apps (like SQL Server for example). Your average application isn't going to do it.
So the answer is, to make effective use of much more than 2~3GB of RAM, you'll want to be running a 64-bit version of Windows. If you're staying under 3GB, 32-bit Windows will be able to handle it.
PAE aint a performance hit. AWE is, but PAE is pure HW. And its BS to say you cant use say 2-3GB with 32bit windows. Each single process can use 3GB with /3GB switch alone. then add windows, other apps etc. And its still DX that sets the limitations in 64bit. Until DX10 you are still memory limited by DX.
UberGerbil wrote:And we're getting quite a bit afield from the OP, who mistakenly thought the memory in the IRAM was mapped into Windows' memory space. (I wonder where this "2.5GB barrier" canard got started? I've seen it on several Mac forums -- though admittedly there's a lot of misinformation and cluelessness there when it comes to x86 systems).
mattsteg wrote:Shintai wrote:I'd just like to say that that statement is chock-full with misinformation. That is all.PAE aint a performance hit. AWE is, but PAE is pure HW. And its BS to say you cant use say 2-3GB with 32bit windows. Each single process can use 3GB with /3GB switch alone. then add windows, other apps etc. And its still DX that sets the limitations in 64bit. Until DX10 you are still memory limited by DX.
mattsteg wrote:Shintai wrote:I'd just like to say that that statement is chock-full with misinformation. That is all.Buub wrote:If I'm not mistaken, Dothan and Yonah support PAE, but they don't support x86-64.
Windows 64-bit can support massive GBs of RAM. To go over ~3.5GB of RAM with 32-bit Windows, you need to use PAE, and even then, that's a performance penalty. 32-bit programs that know how to make use of over 2GB of RAM are rare and restricted to mostly server apps (like SQL Server for example). Your average application isn't going to do it.
So the answer is, to make effective use of much more than 2~3GB of RAM, you'll want to be running a 64-bit version of Windows. If you're staying under 3GB, 32-bit Windows will be able to handle it.
PAE aint a performance hit. AWE is, but PAE is pure HW. And its BS to say you cant use say 2-3GB with 32bit windows. Each single process can use 3GB with /3GB switch alone. then add windows, other apps etc. And its still DX that sets the limitations in 64bit. Until DX10 you are still memory limited by DX.
Buub wrote:It's not a reintroduction of anything. It's the same paging that's been going on since Intel introduced virtual memory in the 386. It adds a third layer of Page Table Entries, yes, but that is hardware indirection and it doesn't have a significant impact on performance.First, PAE is an extra level of indirection. It's a reintroduction of paging.
No, it doesn't. It's the same system the hardware has been using all along. And the OS doesn't have to do anything special unless it is trying to work with physical memory above 4GB. When the OS hands off virtual addresses it doesn't concern itself with how the MMU converts them to physical addresses.This adds a layer of complexity both to the hardware addressing and to the software (OS) usage of the memory.
If you are using a CPU that implements the NX/xD bit, and you are running XP SP2 (or Server 2K3) with the execution protection feature turned on (the default) then you are already using PAE and that extra indirection via the third layer of PTEs (that's where the NX bit is stored). They're probably (on Server) or definitely (on XP Pro) all redirecting to addresses below 4GB, but the CPU is using them. Hey, try turning off the no-execute feature. See that noticible increase in performance? You didn't? That's right, because PAE in itself doesn't have any real impact on performance. Hardware indirection using the PTEs is how virtual memory works, it's very fast, and one more level doesn't make any real difference. Note that 64bit OSes use those very same PTEs to address physical memory (above and below 4GB, it's all the same on 64bit) without any significant performance penalty. Again, the "extra layer of indirection" doesn't have any real impact (beyond some minor growth in the data structures tracking the pages).Besides, I was talking about actually using PAE. Just having it present without using it is as useful as not having it present. Now, how can using PAE be pure hardware if 32-bits is 4GB of RAM? Doesn't the OS and/or the application have to do something to access that extra memory above 4GB? PAE doesn't do anything without the interaction of the software.
Be careful to not confuse virtual address space and physical memory (Buub, it looks like you understand this but other readers might not). The /3GB switch (for apps that are written to be large-address aware) allows an application to see and use 3GB of virtual memory addresess (which may or may not be backed by real physical memory -- that's what a page file is for). PAE enables that third level of PTEs, which have 36bits for physical addresses (plus some extra bits, like NX). Windows Server (32bit) can use that to map physical memory to addresses above 4GB, so it doesn't overlap with the PCI addresses. Thus Server can give you access to a full 4GB of physical memory. Applications that are written using the AWE API can use that to manipulate PAE to map physical memory above 4GB into their (32bit) virtual address space. This enables them to exploit more than 2GB of physical memory while remaining a 32bit application with a 2GB virtual address space. As you might imagine, this requires a lot of hairy bookkeeping both by the app and the OS, so this is indeed rather inefficient (and in fact AWE is more inefficient than it could be -- Microsoft is actually massively improving this for Vista, though I'm not sure how much it's going to matter when the world is moving to 64bit anyway).Third, each application can use up to 3GB, yes. But that doesn't mean it will. Most apps are not written to do that.
Fourth, even if they are, they still will not access more than 3GB of RAM unless they use a special API (AWE) to page in additional memory via PAE. This memory does not appear the same as contiguous heap memory, from what I understand (I've only briefly looked at this, and it was some time ago).
