A Messy Transition (Part 2): Windows XP, Vista, and the 2GB Barrier
by Ryan Smith on July 19, 2007 12:00 PM EST- Posted in
- Software
Shortly after publishing A Messy Transition (Part 1) we received numerous requests for similar user address space usage testing under Windows XP, as we had previously done all of our testing on our standard Windows Vista setup. Although we were not expecting a great difference - certainly Vista will use more resources than XP because it's a newer and heavier operating system - we decided to follow these requests anyhow. However what we found completely blew our expectations.
And with that said we'll immediately dive in to the results of our findings. We'll be picking up from where we left off, so please read part 1 if you haven't already.
| Software Test Bed | |
| Processor | AMD Athlon 64 4600+ (2x2.4GHz/512KB Cache, S939) |
| RAM | OCZ EL Platinum DDR-400 (4x512MB) |
| Motherboard | ASUS A8N-SLI Premium (nForce 4 SLI) |
| System Platform Drivers | NV 15.00 |
| Hard Drive | Maxtor MaXLine Pro 500GB SATA |
| Video Cards | 1 x GeForce 8800GTX |
| Video Drivers | NV ForceWare 163.11(Vista) NV ForceWare 162.18(XP) ATI Catalyst 7.6 |
| Power Supply | OCZ GameXStream 700W |
| Desktop Resolution | 1600x1200 |
| Operating System | Windows Vista Ultimate 32-Bit Windows XP Professional SP2 |
| . | |
The principles of address space allocation and usage are virtually the same between Vista and XP, so as with our Vista tests we first attempted to crash Supreme Commander against a modified 2.6GB of user address space. Because this needed to be repeatable we have switched to using replays instead of a live game, but the goal remains the same one of monitoring memory usage and looking for Supreme Commander to crash. Or surprisingly, to not crash; we were unable to make Supreme Commander crash and not for a lack of trying.
| Supreme Commander Address Space Usage (GeForce 8800GTX, 768MB) |
|||
| Game Start | Replay Start | Replay End | |
| Windows Vista | 562MB | 1.21GB | 1.95GB |
| Windows XP | 116MB | 930MB | 1.44GB |
| . | |||
The above is a chart of the user address space usage of Supreme Commander when the application was launched, at the start of the replay, and 15 minutes in to that replay. Although using a replay reduced overall address space usage (which is why not even Vista is above 2GB at 15 minutes in), there is a massive difference in usage between XP and Vista at all points. At the start of the replay there's already a 300MB difference in address space usage, and by 15 minutes in when Supreme Commander is heavily loaded down that difference has ballooned to 500MB, a full 25% of the total address space the application gets under normal circumstances.
Appropriately, the difference in address space usage was the reason that Supreme Commander would not crash under XP like it would under Vista. Address space usage peaked at 2.1GB, which while in excess of the default 2GB barrier is below the 2.6GB mark where it crashed under Vista. Even a slight reduction in address space usage here would have kept the game from hitting the 2GB barrier at all, avoiding the whole can of worms that is modifying the user address space allocations.
| Supreme Commander Address Space Usage (Radeon X1900XTX, 512MB) |
|||
| Game Start | Replay Start | Replay End | |
| Windows Vista | 230MB | 1.15GB | 1.87GB |
| Windows XP | 124MB | 939MB | 1.44GB |
| . | |||
As we originally had a suspicion that this could be related to NVIDIA's drivers, we swapped out our 8800GTX for a 512MB Radeon X1900XTX and ran the Supreme Commander tests under both Vista and XP. The results were virtually identical with Supreme Commander consuming more address space under Vista than XP. Curiously however the overall amount of address space used by Vista is down slightly (by about 120MB) compared to the 8800GTX.
| Supreme Commander Address Space Usage (GeForce 7800GTX, 256MB) |
|||
| Game Start | Replay Start | Replay End | |
| Windows Vista | 240MB | 1.10GB | 1.75GB |
| Windows XP | 119MB | 928MB | 1.43GB |
| . | |||
In trying to explain the difference in address space usage under Vista, we finally pulled out a 256MB GeForce 7800GTX. What we found was that the gap between Vista and XP remains, but it is smaller yet again as Vista's address space usage shrunk another 120MB compared to the 512MB Radeon card. With the above numbers we can definitely say there appears to be some sort of relationship between address space usage and video memory under Supreme Commander. But this also raises the question: is this difference in usage of our increasingly critical address space a function of Windows, or something specifically related to Supreme Commander?
Facebook
Twitter
RSS
57 Comments
View All Comments
totallycool - Thursday, July 19, 2007 - link
The reason could also be the way memory is allocated in vista as opposed to xp. If i am correct, then with superfetch it really tries to bring as much of the program in as possible, and this could relate to vista allocating more user space to program as opposed to xp. Simply put xp could be more conservative in allocating memory then vista is.The best way to test it out would be to check other programs memory usage, like maybe Word2007, photoshop etc on the two operating systems.
Just my 2 cents
The other solution is to enable the A20 line already ;)) <- Joke
Ryan Smith - Thursday, July 19, 2007 - link
It's not SuperFetch. Unfortunately I can't find the MS article at this specific time, but there's one I read specifically talking about SF having its own allocations.BUL - Thursday, July 19, 2007 - link
What registry setting is the equivalent of "DOS=HIGH"? And wouldn't it be the A36 line? (I'm just messing with you...)strafejumper - Thursday, July 19, 2007 - link
i've noticed on a lot of game boxes that the minimum system requirements are different for vista and xpusually its something like:
1gb ram (2gb if using vista)
as a gamer this kind of thing put me off and i stuck with xp
leexgx - Thursday, July 19, 2007 - link
as i have got vista 64 my self and XP 32 dual boot on 2x2 80gb hdds RAID (2 for xp 2 for vista) i find games are basicly Unplayable in some cases on vista with 2gb of ram due to the game stuttering
i got 4gb of ram in it now (xp picks up 3.2gb but that hardy matters as i never see ram use pass 1.8gb)games run mostly fine DX10 games are flaky
Nvidia could fix this bug maybe setting there drivers to Not used shared ram as from the way it looks its the New way vista handles shared ram now on the 7800 256 it would waste an extra 256mb in VM but the 8800gtx has 756mb so it uses up 500mb more VM then the 7800GTX
ChristopherO - Thursday, July 19, 2007 - link
Am I the only one who thinks Microsoft should release a Knowledge Base article on this issue? (Ryan, have you been in contact with them?) At least the creation of said article would be an "official" source to look for, acknowledgement, updates, or a hotfix. Until they create a KB article and admit to a fix, it is pure speculation that MS's opinion isn't, "Game developers need to learn to program correctly, not our problem."Speaking of which, they had better get this done ASAP. I see two huge problems looming in their future. 1.) Back to School. 2.) Christmas. First, the college kids getting computers are going to be awfully mad if their games don't work. I'm sure all the developers and MS will get blamed equally for this. Same thing goes for Christmas. People are going to want to test new machines with the latest and greatest games/apps.
As for me, I have Vista 64, 4GB memory, with a 512MB ATI X1950. I had to edit the headers on FSX. Also C&C3. C&C 3 is such an allocation hog that it will run out of 3GB of address space. It will always do this in about 15-25 minutes on large maps, and 30-45 on smaller ones. Sure I can turn down the detail, but why the heck would I do that when I can run at "ultra-high" quality settings and get nothing less than 30fps? Fortunately I can tell when C&C 3 is about to crash (the icons go "pink"), which gives me time to save, quit, re-load and keep playing. Unfortunately I can't play online due to this problem.
What confuses me is that memory allocation is not a difficult problem... I don't know if the issue is becoming more prominent because game developers are really barely "adequate", or if they are off-shoring the labor to poorly trained (i.e. cheap) coding teams. I have no idea what a game developer earns, so I really couldn't make an educated guess as to where the problem is being introduced (other than the fact that Windows Vista isn't helping, and XP is really papering-over bad software architecture).
JCheng - Thursday, July 19, 2007 - link
Umm... maybe so the game stops crashing? You'd rather "save, quit, re-load and keep playing" and stop playing online, rather than turn down your settings??
ChristopherO - Thursday, July 19, 2007 - link
Yes, because otherwise I wasted a large amount of cash buying the fastest video card I could get my hands on. If I realized Vista was going to be problematic I should have bought a $60 card since I can apparently only make use of $60 quality.
elpresidente2075 - Sunday, July 22, 2007 - link
Perhaps you should have done a little more research before basing a (presumably) $1000+ system on a young and mostly untested OS that is released from a company that is known for releasing its final betas under the guise of a "final product" or "golden master" on release date.Don't worry, Microsoft will have the bugs ironed out in a year... or two... or three...
They're gonna release a service pack in November! Maybe that'll make Vista not suck so much memory! *crosses fingers*
nullpointerus - Thursday, July 19, 2007 - link
Typically, system developers create elegant, well-designed API's with flexible error handling mechanisms, which application developers then completely ignore until their applications begin doing wierd things. This failure to use API's as intended was the reason why XP and Vista's 32-bit PAE kernels were crippled: driver developers could NOT be trusted to use the system API's as published at least a decade ago, so the whole MMIO remapping thing could not be enabled, which meant that PAE kernels had the same < 4 GB physical memory limitations as non-PAE kernels.