Traditionally it always has been real memory - system RAM or VRAM - that's been most important to the flying equation. But recently virtual memory has been a scarce resource. What happened?
To understand this situation, consider X-Plane 6 vs 8. Back in the X-Plane 6 days, a typical system might have 256 MB of system RAM, 16 MB of VRAM, and 2 GB of virtual memory* for X-Plane. That's a ratio of 8:1 virtual to real RAM and 128:1 virtual to VRAM.
These ratios are actually pretty useful. At any given time only part of the loaded scenery is visible, so only part of it needs to be in real RAM/VRAM. So having that extra virtual memory lets us load a big chunk of scenery at a time, rather than having a lot of complex details to load tiny bits of scenery.
Today's computers are a bit different. 2 GB of RAM is not uncommon...that'd be a ratio of 1:1! And most gamers cards have 256 MB of VRAM now for an 8:1 ratio with VRAM. 512 MB cards are coming out and nVidia's monstrous 8800GTX comes with (gasp) 768 MB of VRAM! Insanity!
The problem is: RAM and VRAM are getting larger, but virtual memory is not! This means the ability to have the part of the scenery you don't see in virtual memory is getting more and more difficult.
Why can't we get more virtual memory? Well, the problem is to get more virtual memory we need 64-bit CPUs, 64-bit operating systems, 64-bit drivers, and 64-bit applications. That's a lot of parts that all need to be 64 bit and means a full computer upgrade and motherboard upgrade. Of the 5 machines Apple sells right now, only one is 64-bit, so even some of today's fastest machines aren't 64 bit. That's slow adoption.
So in the meantime we're adjusting X-Plane's strategy to deal with increasingly limited virtual memory. Back in X-Plane 6 it was acceptable to leave all objects their textures cached in virtual memory for later use (which sped up reloading of scenery).
X-Plane 860 (coming soon to a beta near you) will change this - unused textures and objects will be fully purged, which will hopefully address the problem of running out of virtual memory during long flights over lots of different custom scenery.
* 2 GB? Well, technically an application can have 4 GB of virtual memory, but the OS keeps some for itself. Some OSes take 2 and leave 2, some take 1 and leave 3, but even if we had all 4 GB of virtual memory for application use (and we don't - the graphics driver steals some too) we'll have 4 GB machines soon, so virtual memory is disappearing.
6 comments:
Interesting post; anyway I have to correct you on currently sold Apple Machines: out of the 5 Mac lines they are selling now, 4 are 64 bit capable (all the core 2 duo) and one not (the Mac Mini).
Hi, I have a windows xp machine with 2GB. I've disabled the virtual memory entirely (set the size to 0) and this doesn't really cause me any problems with x-plane. I run extremely large scenery such as for example the paris scenery. Worst case scenario for me is that I get a out of memory error which I consider to be way more friendly than the heavy disk churning long before I technically should be running out of memory. I rarely get these errors and when I do get them the problem is that I'm running processes that are coming really close to their 2GB theoretical limit (e.g. photoshop + x-plane is a bad idea).
In my experience processes using 1.5 GB or more can become a problem. If the latter ever becomes a problem, all I need to do is put in some extra memory and then I will be able to have processes allocate their full 2GB.
The problem with virtual memory is that windows manages it poorly. It continuously makes really bad decisions with respect to what to swap to memory leading to very annoying delays when you use e.g. alt tab. Also it affects in game performance because it will be active when the system is stressed to the max. Even with only a quarter of memory in use, my applications get swapped to disk!
So, good decision to rely less on this. You might consider doing some sort of application level virtual memory like for example photoshop does. This would also allow you to work around OS limits and use more than 2GB of disk storage.
The Core 2 Duo chip is 64-bit, so I think that makes 3 out of 5 Apple machines 64-bit (with the MacBook and Mac mini being the exceptions). Still, I guess it's a moot point since most (or all?) the OS APIs are 32-bit so you can't compile 64-bit apps anyways.
Ah yes - I didn't realize that the revised chipset support EMT64.
But what I am still unclear about is: did the _original_ MacBook Pros support EMT64? I thought they shipped with "Yonah" chips, but given Intel's decision to name every chip they have as som combination of the word "Core", "Duo" and optionally the number 2 in random order, I've had a little trouble connecting the dots about what parts go where. Give me a 7600GTX any day! :-)
Application-based virtualization of resources is sort of where we're ending up these days. Try looking at far away (100 nm) airports in the textured mode in the local map. You'll see no runways! This is because almost everything but the base mesh gets built up and torn down "on the fly" as your plane moves around, saving memory.
Still, I hate to bet against virtual memory - it can work very well and makes applications less buggy and faster to develop.
The Core Duo and Core Solo CPUs are only 32 bit, the Core 2 Duo CPUs are 64 bit. The original MacBook, MacBook Pro, and Intel iMac have Core Duo CPUs, so they are 32 bit machines. Starting this past August, the MacBook, MacBook Pro, and iMac have been updated with Core 2 Duo CPUs, so all the new ones are 64 bit machines along with the Mac Pro. The only remaining Mac that has the original Core Duo/Solo CPUs is the Mac Mini.
Mac OS X Leopard will have 64 bit support from top to bottom, so sometime next year true 64 bit support will be a reality on the Mac platform.
Post a Comment