Longwinded intro to question may be skipped, if you wish, by scrolling to the next line in red
Take a brief journey with me, if you will, to an era before virtual memory was quite so ubiquitous. I’ll refer you to the Macintosh platform, since my knowledge of PCs back then was even more dismal than what I know of them now.
People then got confused about the difference between “memory” and “storage space” just as they tend to be nowadays, but there was in fact a clear-cut difference. Storage space was a floppy disk or hard disk and it came in kilobytes or megabytes and they were cheap and slow. Memory — usually meaning random access memory, or RAM — was something held on some little electronic chips that snapped into slots, and while it also came in kilobytes or megabytes, hence confusing some folks, it was expensive and fast. If your local power company’s generators went out or your household circuit breaker popped on you, the contents of memory went POOF! and if you had unsaved work, well, sorry, remember to save more often from now on; but your storage space was right there and still had your (saved) files on it when the power came back on.
We did have RAM disks back then, if we wanted them. You could take a portion of your expensive, rare memory (RAM) and tell it to pretend to be storage space. That may seem like an odd thing to do, but remember: RAM is fast. If you had a disk-intensive process to perform and you had enough RAM to be able to afford to do so, you could copy the document to RAM disk and fly though it so much faster than if you had to keep reading new chunks of it from your hard disk or, worse, your floppy disk. (All disks are a lot slower to read from than RAM but floppies were like molasses in January).
In the early days of the Mac platform, there was a model called the Mac Plus that had no hard drive but could accept up to 4 MB of RAM. A floppy disk was 800K and dedicating 800K worth of your RAM to acting as a RAM disk was wonderful: you could even set up a control panel to automatically copy your OPERATING SYSTEM to the RAM disk and REBOOT FROM IT, spitting out the floppy and freeing up the drive so you could insert other floppies with your various documents on them.
Virtual memory came later. At first it was a bit of a gimmick on the Mac platform, something that wasn’t implemented well enough to be worth it, but the idea was to do the opposite of a RAM disk: to tell some of your cheap, slow storage space to pretend that it was RAM. Because it was, in fact, so slow, your computer would read the bits of it it needed to work with into real RAM, and to make room for it in real RAM it would write out some pieces you weren’t actively using at the moment to hard disk and then use that part of RAM for the new bits. Usually it would do this when you switched between two different open, running applications. Using virtual memory allowed you to have a lot more things open at one time. (On the Mac, it also made your system dog-slow, it just didn’t work very well. We heard that it was far better implemented on the Windows platform but PC users had problems with performance too)
OK, let’s leave the past behind and switch focus to the modern operating system, and modern specs. It is my understanding that all of the modern operating systems, MacOS X, Windows, and various flavors of Unix, do virtual memory quite well and rely on it so intrinsically that there’s no way you could turn it off, or would generally ever find a reason to want to. They’re just a lot smarter about “paging” inactive bits of RAM out to a “swap file” on the hard disk and reading in the bits you’re going to need, and doing so in such a way that you don’t generally experience it as a slowdown. It’s not an afterthought but instead is designed in from a very low fundamental level of how the operating system works.
So now, finally, the relevant bits. I work with someone who is under the impression that on his Windows server, a 3rd-party program that he runs to create a RAM disk results in a true RAM disk in the old-fashioned sense, a disk whose RAM is not at any time, under any circumstances, paged out to the hard disk. We were experimenting with this to see if a disk-intensive database process on a 6+ gig array of databases would run faster. It should have (the CPU cores were not saturated, indicating that none of the threads we started were feeding them as fast as they could crunch the data). It did not. My theory is that the modern operating system simply isn’t disposed to set aside a chunk of RAM and cease to address it with the virtual memory management scheme, because it’s doing that at such a low level that no 3rd party app can instruct it not to. (If it were a Microsoft product that had been designed from the ground up to do so, then yeah, I’d believe it, especially if it required a reboot after designating the RAM disk). Anyway, I’m guessing that the virtual memory scheme manages ALL of the RAM, including the bits occupied by the components of the operating system itself, and that it does so for the contents of the RAM disk along with everything else; that 6 gigs and change is too large a chunk of RAM to not be expecting virtual memory to read out and write back bits and pieces of it to the swap file as it goes, given that it is indeed a 3rd party program setting it up and that Microsoft Windows, on some fundamental level, is going to treat it like any other program and on a low level treat the RAM like any other RAM even while, at a higher level, it treats it as a disk drive, an F:\ drive or whatever.
Do you think I’m most likely right about this?
