Does PR work better with 4GB of RAM?
-
Shining Arcanine
- Posts: 429
- Joined: 2006-05-29 21:09
Does PR work better with 4GB of RAM?
My computer's motherboard died two months shortly after I ordered additional RAM to bring my computer's RAM to 4GB. Now that I have it fixed (I have been busy with summer classes) and I have PR 0.6 installed, my framerates seem to be higher than they were with 2GB of RAM when using 0.5 (in the 40-45 range, rather than the 30-35 range according to FRAPS). There also seems to be less lag. This is despite having 5-5-5-15 memory timings (I have not tightened them yet; I have been having trouble getting memtest86+ working). I have not changed any of my graphics settings. They are all the same as they were when my computer's motherboard died. I recall purchasing 4GB of RAM because background processes consume several hundred megabytes of RAM on my PC, so PR 0.5 would regularly push my memory usage to 2.2GB and beyond.
Does anyone think that it is the additional memory or is it that PR's developers are simply really good at optimizing things?
Does anyone think that it is the additional memory or is it that PR's developers are simply really good at optimizing things?
-
LtSoucy
- Posts: 3089
- Joined: 2007-03-23 20:04
-
El_Vikingo
- Posts: 4877
- Joined: 2006-11-27 01:50
-
Aljen
- Posts: 399
- Joined: 2006-11-14 14:48
I have found this thread about 4GB.
http://bink.nu/forums/8805/ShowPost.aspx
"Also take note, that with 4 x 1 gig memory modules, the latency (clock cycle time) is slower than 512mb modules. Your system would perform faster with 4x512mb (2gig), than 4x1gb (4gig)."
" As far as benchmarks go, you'd see some performance hits....but for most games, you probably won't."
.... I have no idea if it is true.
http://bink.nu/forums/8805/ShowPost.aspx
"Also take note, that with 4 x 1 gig memory modules, the latency (clock cycle time) is slower than 512mb modules. Your system would perform faster with 4x512mb (2gig), than 4x1gb (4gig)."
" As far as benchmarks go, you'd see some performance hits....but for most games, you probably won't."
.... I have no idea if it is true.
Truth needs no law to enforce it
Evolution: The realization by the organism that those things inside the white lab coats are pretty damned tasty!
Evolution: The realization by the organism that those things inside the white lab coats are pretty damned tasty!
-
El_Vikingo
- Posts: 4877
- Joined: 2006-11-27 01:50
http://www.microsoft.com/windowsxp/usin ... ngx64.mspx
Description of Windows XP Professional x64 Edition
Windows XP Professional x64 Edition is a near feature-complete version of Windows XP Professional that runs on x64 processors. Windows XP Professional x64 Edition supports 128 GB of RAM and 16 terabytes of virtual memory address space, as compared to 4 GB of both physical RAM and virtual memory address space for 32-bit Windows XP Professional.

If you are reading this dont stop, cause if you do, I'll kick you in the balls.
-
Shining Arcanine
- Posts: 429
- Joined: 2006-05-29 21:09
Technically speaking, it can address 4GB of RAM, but because the people who design hardware drivers decided in the 1980s to use the memory address space instead of the I/O address space for almost everything but USB, almost everything is mapped to the system's memory address space, which limits the amount of actual RAM that Windows can address. On my PC, it only addresses 3.25GB of RAM, as there are many things integrated with my motherboard, my graphics card has 256MB of RAM and I have two other PCI cards.ZZEZ wrote:32bit XP can only address 3.5gig of RAM, including VRAM - so it will be a waste unless your planning on switching to a 64bit OS which can address up to 8042 gig of RAM, I'm not sure if BF2/PR works on 64bit![]()
A 64bit OS can theoretically address 16 exabytes of RAM (2^64), but because of how AMD designed the 64bit implementation of x86, I believe that it is hardware limited to ~52 bits of address space (2 bits are reserved for NX-bit and 10 are reserved bits for future extensions if I recall correctly), which is 4 petabytes. Microsoft's implementation of 64bits in Windows might further limit the total amount of memory address space available, but I doubt that it limits it to 8042GB, which is not a power of 2.
By the way, I was asking if the extra RAM helped my gaming, rather than if buying it would be worthwhile, as I had already purchased it.
Games are typically more GPU limited than CPU limited, so the memory timings (as far as system memory is concerned) are not that important, but the amount of memory (system memory) is fairly important, because if the game's memory requirements exceed the available physical memory, the system will start swapping and from a performance perspective, things will only go downhill from there.Aljen wrote:I have found this thread about 4GB.
http://bink.nu/forums/8805/ShowPost.aspx
"Also take note, that with 4 x 1 gig memory modules, the latency (clock cycle time) is slower than 512mb modules. Your system would perform faster with 4x512mb (2gig), than 4x1gb (4gig)."
" As far as benchmarks go, you'd see some performance hits....but for most games, you probably won't."
.... I have no idea if it is true.
So 64bit versions of Microsoft Windows have 37 bit physical address space and 44 bit virtual address space.El_Vikingo wrote:http://www.microsoft.com/windowsxp/usin ... ngx64.mspx
I already purchased and installed the memory. My question concerns whether or not it helped rather than whether or not to purchase it.WorfoSAUR wrote:I would definitely suggest sticking with just 2 GB. The game can actually run slower with 4 GB, and even then, you could spend the extra money on a different part of your computer that actually needs updating.
-
Shining Arcanine
- Posts: 429
- Joined: 2006-05-29 21:09
-
Tweaky
- Posts: 107
- Joined: 2007-07-07 19:02
I've got 4gig, but I don't know the difference from anything less to be honest (Haven't tested myself personally).
I do know that the more memory you have on both your system and gfx card (running 640mb on gfx (you need a lot for BF2, it loads a heavy set of textures and shaders)), it will improve load times for maps, and loading of objects before you choose your spawnpoint (the moment you join the game). I load before everyone else, really only takes about 10-15 secs to load a map. But I bought my 4 gigs not for gaming, but for graphics applications and other publishing software. Gaming really will do just fine with 2 gigs.
Also to point out here, any 32-bit operating systems will not show a full 4gb of ram on your system, you need a 64-bit OS and 64-bit CPU to get the most out of everything. I run WinXP 64-bit (Not gonna switch to Vista atm), and it runs great. If you just have a 32-bit CPU and OS, stick with 2gb, trust me. 4gb just wont run at its fullest potential without 64-bit backend.
I do know that the more memory you have on both your system and gfx card (running 640mb on gfx (you need a lot for BF2, it loads a heavy set of textures and shaders)), it will improve load times for maps, and loading of objects before you choose your spawnpoint (the moment you join the game). I load before everyone else, really only takes about 10-15 secs to load a map. But I bought my 4 gigs not for gaming, but for graphics applications and other publishing software. Gaming really will do just fine with 2 gigs.
Also to point out here, any 32-bit operating systems will not show a full 4gb of ram on your system, you need a 64-bit OS and 64-bit CPU to get the most out of everything. I run WinXP 64-bit (Not gonna switch to Vista atm), and it runs great. If you just have a 32-bit CPU and OS, stick with 2gb, trust me. 4gb just wont run at its fullest potential without 64-bit backend.
Last edited by Tweaky on 2007-08-15 00:47, edited 1 time in total.
-
Long Bow
- Posts: 1100
- Joined: 2007-03-21 14:41
There is also the issue of virtual address space being limited to 2GB by 32 bit operating systems. Even if you have 2+ GB windows will throw a fit if the game actually tries to use more then the 2GB virtual address space i.e. crash. The 64 bit OS systems don't have this same 2GB limitation in place, however the games need to be programed to work properly with this. Point is 4GB can't be properly used or may not be necessary except for with 64bit for the most part.
Linky for article this was taken from. I did paraphrase it so to speak by not including a few sections here and there. A good read, there are three articles in the series, very good read for those with Vista.
http://www.anandtech.com/gadgets/showdoc.aspx?i=3034&p=1
An artifact of the design of 32bit processors and the 32bit API for Windows, the 2GB barrier is a cap on how much addressing space (related to but not equivalent to memory usage) a single application can use. This isn't a bug but rather the result of how hardware and software was created so many years ago,
In 1986, Intel released the 386 processor, which offered support for a new instruction set (IA32), that was an extension of the original x86 instruction set. Among the most notable features in IA32 was an increase in the amount of memory the CPU could address, moving from 20bit addressing(1MB) to 32bit addressing(4GB)(ed: this is not including the convoluted mess that was segmented addressing). All x86 CPUs released since then have supported the same instruction set, including the same 4GB limit. Only recently have 64bit x86 CPUs been released, and while they support more than 4GB of memory, still are limited to 4GB when operating in 32bit mode.
As we have mentioned in previous articles, most modern system running in 32bit x86 mode have trouble seeing and using more than roughly 3GB of memory. This is because part of the total 4GB of memory space (not the physical memory) is reserved for various functions, such as computer components transferring data between each other using memory-mapped input-output(MMIO). The textbook example of this is the CPU transferring data to the memory of a video card, where a chunk of the address space equal to the size of the memory of the video card is reserved by the video card, and any data sent to those addresses actually ends up going to the video card. This design has many technical merits, but it makes the consumed memory addresses unavailable for use with physical memory.
Things only get more complex as we start including the operating system (in this case Windows) in to the equation. The above is actually handled by a combination of Windows and the BIOS, meanwhile Windows also needs some address space so that programs can communicate with the Windows kernel, for storing buffers, for storing memory tables, etc; all of which means we have lost even more address space. All of the above besides preventing us from addressing 4GB of physical memory are also the cause of the actual 2GB barrier that is the problem.
Quickly, there is one more pre-requisite piece of information: virtual address space. For a 32bit Windows application(Win32), each application has a full 4GB worth of private addressing space that it can use, which again is 32bits and a result of how a 32bit processor works. How the above exactly works is beyond the scope of this article, but it's sufficient to say that at some point virtual addresses get translated in to other addresses for mapping data between the application and physical memory or the swap file. The important thing to take from this is that each application has its own 4GB virtual address space, regardless of the hardware the computer contains or what applications are running. Now we may begin to understand the 2GB barrier.
Due to design reasons outside the scope of this article, Windows takes a pre-determined portion of each application's virtual address space and reserves it for itself. Windows uses its portion of the virtual address range for all of the address needs listed above. At the end of the day, and what really matters, is that in designing Windows Microsoft opted to split up the virtual address space of an application in half; 2GB goes to Windows (kernel space) and 2GB goes to the application (user space). Under normal circumstances this 2GB of space is all a 32bit application has to work with, this is the 2GB barrier and as we'll see is the cause of the problems with Supreme Commander.
It is also worth noting at this point that virtual address space is not directly correlated to physical memory size. Windows and any applications running under it may use up to all of their allocated virtual address space, with Windows simply swapping data between the hard drive and physical memory if the amount of physical memory needed is in excess of what's available - this is virtual memory, not to be confused with virtual address space. The only meaningful relation between virtual address space and physical memory is that the amount of physical memory an application can use can never be greater than its virtual address space. The user space must take up a larger portion of the virtual address space if an application is to use more than 2GB of physical memory.
As it turns out, it's possible and actually quite easy to move the 2GB barrier by increasing the size of the user space, but at the cost of reducing the size of the kernel space. Under Windows XP, this is the fabled "/3gb" switch for boot.ini, and for Windows Vista it's the "IncreaseUserVa" option in BCDedit. By using these options applications can use more than 2GB of virtual address space (generally up to 3GB), and ideally this would be the end of the article.
Unfortunately this is not the case as there are problems on both the application and kernel side of things. On the application side, a common poor programming practice has been to always assume that an application will only be dealing with 2GB of user space; code that makes this assumption will likely error if more than 2GB of user space is actually available. This is avoidable by following proper programming practices, but as a safety precaution even with additional virtual address space allocated to user space Windows still defaults to limiting an application to 2GB. Only finally, if an application indicates to Windows that it is capable of handling more than 2GB, via the "/LARGEADDRESSAWARE" flag, may it have access to any space above 2GB.
Just at the start of the game, our virtual size was already in excess of 1.6GB, dangerously close to the 2GB barrier. 16 minutes in to the game, we have already hit a virtual size of 2.2GB, meaning had we not broken the 2GB barrier the game would have already crashed. At this point our total memory usage (private bytes) is only at 1.7GB, with 1.4GB of that in physical memory, nearly maximizing the RAM usage of our 2GB system. Our spread between memory usage and virtual size is .5GB, showcasing how deceptive memory usage is in identifying 2GB barrier issues.
Now that we've seen what can happen when we reach the 2GB barrier and how easy it can be to pass it, let's talk about what it took to remove it in the first place for Supreme Command. Supreme Commander is unfortunately not compiled as being large address aware and must be modified so that Windows thinks that it is. Microsoft supplies a tool as part of the Visual Studio suite, Editbin, that can do just this by rewriting the file header to report to Windows that it is in fact large address aware.
To the best of our knowledge Supreme Commander was programmed using proper programming practices and can handle the larger address space, and this is merely an issue of turning it on. However on a more pragmatic note this can break future patches, and disturbingly it doesn't set off any sort of multiplayer cheat detection in the game in spite of the fact that we have modified the executable in a very visible way. Out of the changes we need to make to deal with the 2GB barrier though, this is the safer of the two.
Update: Gas Powered Games contacted us and let us know that the modified executable not setting off any cheat detection is intentional. The game code is all in a DLL, and the executable is just a launcher; it's left unchecked because of the various Digital Rights Management systems used change the exectuable.
Changing Windows on the other hand to allocate more of the virtual address space to applications is in practice just as dangerous as we theorized earlier. We initially set our copy of Windows Vista to adjust the split to 1GB kernel mode, 3GB user mode, only for Vista to encounter a BSOD while booting. We had to settle for a 1.4GB/2.6GB split before Vista would boot, and even then Vista still periodically encounters a BSOD upon booting at that allocation or any other allocation other than 2GB/2GB. While what problems may occur and with what values is highly variable from system to system, this is why trying to move the barrier at all can be dangerous.
Linky for article this was taken from. I did paraphrase it so to speak by not including a few sections here and there. A good read, there are three articles in the series, very good read for those with Vista.
http://www.anandtech.com/gadgets/showdoc.aspx?i=3034&p=1
-
ZZEZ
- Retired PR Developer
- Posts: 4268
- Joined: 2007-07-26 10:10
Long Bow, I was going to link that article 
I'm not sure where I got that 8000gig of ram, must have read it somewhere, Oh there it is
I'm not sure where I got that 8000gig of ram, must have read it somewhere, Oh there it is
http://www.anandtech.com/systems/showdo ... i=3060&p=3The long-term solution to this virtual address space problem is 64-bit hardware, which has significantly more address space. Windows Vista X64 provides 8 TB (8,096 GB) of user-mode virtual address space to native 64-bit applications. This is large enough to allow growth on both video memory configurations and application memory usage for many years.
-
Long Bow
- Posts: 1100
- Joined: 2007-03-21 14:41
ZZEZ wrote:Long Bow, I was going to link that article
I'm not sure where I got that 8000gig of ram, must have read it somewhere, Oh there it is
http://www.anandtech.com/systems/showdo ... i=3060&p=3
It's a realy good set of articles to read through. I was hoping no one else would have read it and hence make me look realy smart like
I would suggest reading part three of it if anyone here is running Vista, talks about a hotfix for the excessive Vista memory usage problems


