Article View: net.arch
Article #2812Re: Very large memories
From: Joel Upchurch
Date: Thu, 11 Sep 1986 16:36
Date: Thu, 11 Sep 1986 16:36
52 lines
2971 bytes
2971 bytes
>Jan Stubbs ....sdcsvax!ncr-sd!stubbs
>3) The real reason for virtual memory (and the one which won't
>away when memories get big) is that I can quickly load the
>working set of a large program, execute it, and go on to the next
>program, while a real memory system might be still loading its program.
>
>In fact, I can start executing when the first page gets in, on
>a properly implemented system where everything is already
>in paging format.
>
>This assumes that the working set is smaller than the program,
>and that the programmer didn't do some work to only load those
>pieces of program and data which were needed this time.
I may be missing something important, but this doesn't
sound right to me. I followed what Jan said about starting
up faster (more about that later), but it seems to me that
you'll use up that and a lot more in page faults. Since you
are reading the program piecemeal into virtual memory you
are going to be a lot slower because of the extra seek and
rotational delays. It is sort of like a guy driving on a
surface street, instead of going over and getting on the
freeway. You get started faster, but you hit all those
traffic lights. The only case that is valid is if the
overwhelming majority of the pages in the program are
never referenced.
Another consideration, is that on at least some virtual
memory systems I've worked with, the the system transfers
the program over to some sort of paging file, before it
starts, which means that you end up reading the whole
program in anyway, and writing it out to boot. Does anyone
know of a virtual memory system that doesn't work this
way?
I'm no big fan of virtual memory. It made sense back in the
days of timesharing systems with expensive core memories,
but now with cheap semiconductor memory RAM disks and big
disk caches make more sense.
I worked at one large IBM mainframe site that installed
a external RAM disk drive on their MVS system. Do you
know what they used the RAM disk for? Page datasets!
In effect they were using RAM to simulate RAM! And the
worse part was it made sense since the IBM machine could
only use 16MB of real memory.
--
Joel Upchurch @ CONCURRENT Computer Corporation (A Perkin-Elmer Company)
Southern Development Center
2486 Sand Lake Road/ Orlando, Florida 32809/ (305)850-1031
{decvax!ucf-cs, ihnp4!pesnta, vax135!petsd, akgua!codas}!peora!joel
Technical Details
Message-ID:
<2383@peora.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!cbatt!ihnp4!houxm!mtuxo!mtune!codas!peora!joelReferences:
<1164@ncr-sd.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!cbatt!ihnp4!houxm!mtuxo!mtune!codas!peora!joel From: joel@peora.UUCP (Joel Upchurch) Newsgroups: net.arch Subject: Re: Very large memories Message-ID: <2383@peora.UUCP> Date: Thu, 11-Sep-86 12:36:55 EDT Article-I.D.: peora.2383 Posted: Thu Sep 11 12:36:55 1986 Date-Received: Fri, 12-Sep-86 05:51:02 EDT References: <1164@ncr-sd.UUCP> Organization: Concurrent Computer Corporation, Orlando, Fl Lines: 52