🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.arch
Article #2812

Re: Very large memories

#2812
From: Joel Upchurch
Date: Thu, 11 Sep 1986 16:36
52 lines
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!joel
References: <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