A Second Opinion

To answer the question of the source, we took two other games that have been known to encounter problems with the 2GB barrier: S.T.A.L.K.E.R: Shadow of Chernobyl and Company of Heroes. Both of these games as we found out in part 1 are currently shipping as large address aware, making them ideal candidates for examining address space usage under heavy load.

For STALKER, we are measuring address space usage around the particularly hectic and graphics-heavy starting camp. Usage was measured right after STALKER finished loading a saved game at that location.

Once again we are seeing two patterns as with Supreme Commander: under XP it's consuming far less address space than under Vista, and the amount of space consumed under Vista is dependent on the amount of video memory. On our bulky 8800GTX the difference between XP and Vista is 600MB, now 30% of our total 2GB of default address space. While STALKER manages to stay under 2GB, we could easily see the game cracking that. As for the relationship between video memory and address space used, it's less pronounced here, switching out for the 7800GTX only shaves off about 100MB.

Switching back once again to real-time strategy games we have Company of Heroes. Here we're checking address space usage at the start of the single-player Cherbourg mission, which as one of the visually richest levels in the game has the greatest capacity for hitting the 2GB barrier and reportedly has been causing problems doing so.

If we were handing out prizes for the biggest difference in address space usage, Company of Heroes would take the cake. At 2.16GB with our 8800GTX on Vista versus 1.30GB on XP, the increase in address space usage is now over 40% of the default and had we not modified our memory allocations Company of Heroes would have crashed. We also see our clearest pattern here of a difference in address space usage based on video memory, under Vista the address space usage with our 7800GTX is some 430MB less.

Index Final Thoughts
POST A COMMENT

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
    Reply
  • 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. Reply
  • 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...) Reply
  • 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 xp

    usually its something like:
    1gb ram (2gb if using vista)


    as a gamer this kind of thing put me off and i stuck with xp
    Reply
  • leexgx - Thursday, July 19, 2007 - link

    quote:

    i've noticed on a lot of game boxes that the minimum system requirements are different for vista and xp
    usually its something like:
    1gb ram (2gb if using vista)
    as a gamer this kind of thing put me off and i stuck with xp


    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

    Reply
  • 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).
    Reply
  • JCheng - Thursday, July 19, 2007 - link

    quote:

    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?


    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??
    Reply
  • ChristopherO - Thursday, July 19, 2007 - link

    quote:

    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??

    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.
    Reply
  • 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*
    Reply
  • 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. Reply

Log in

Don't have an account? Sign up now