jlg@lanl.ARPA (12/10/85)
> Now people are claiming that 2 Gigabytes means you don't need virtual > memory. I'd like to point out that while it probably would mean that your > program can be completely in main memory, you (at least I) would still want > the wonders of segmentation (read-only, shared, bounds checks). Moreover, > it allows you to not page the entire program into memory from disk. (Which > could be expensive and needless for my 1 Gigabyte program (:-)). I know about all the advantages of bounds checks etc. But on big machines I've been without them for so long that I hardly miss them except during code development. A production code runs correctly doesn't it 8-)? However, I can't see your point about not loading your whole code. Why does a program reference any data that it's not going to use? And if it uses the data, then certainly it should be loaded. If your program is a gigabyte long then sooner or later all of that gigabyte must be active. My experience with large codes is that they use nearly all the data that they reference nearly all the time (for example, a lattice gauge theory code that steps through the entire lattice on the inner loop of the code - unless you want to page fault right and left the simplest approach is to load the whole lattice ). To be sure, there are times when paging would be convenient. But speed and convenience are not necessarily compatible. J. Giles Los Alamos
mangoe@umcp-cs.UUCP (Charley Wingate) (12/10/85)
In article <34548@lanl.ARPA> jlg@lanl.ARPA writes: >I know about all the advantages of bounds checks etc. But on big machines >I've been without them for so long that I hardly miss them except during >code development. A production code runs correctly doesn't it 8-)? This is fine in systems where there isn't malicious code. In commercial applications, one must assume there is deliberately destructive code. >However, I can't see your point about not loading your whole code. Why >does a program reference any data that it's not going to use? And if >it uses the data, then certainly it should be loaded. If your program >is a gigabyte long then sooner or later all of that gigabyte must be >active. My experience with large codes is that they use nearly all the >data that they reference nearly all the time (for example, a lattice gauge >theory code that steps through the entire lattice on the inner loop of >the code - unless you want to page fault right and left the simplest >approach is to load the whole lattice ). There are lots of programs, however, which do not consist of a huge table with a little bit of code hanging off the side. Consider an event-driven simulation program. A significant fragment of the code is going to be simply looking for the next event. A relatively small area of the data is going to be exercised disproportionately. THis even more true of data retrieval systems. These programs tend to have data swapping built into them (since they tend to allow for unlimited expansion through the use of files), so why should there be an objection to using paging? Charley Wingate
brooks@lll-crg.ARpA (Eugene D. Brooks III) (12/10/85)
In article <2511@umcp-cs.UUCP> mangoe@umcp-cs.UUCP (Charley Wingate) writes: >This is fine in systems where there isn't malicious code. In commercial >applications, one must assume there is deliberately destructive code. You can have memory protection without paging. It is done with base and limit registers for memory addresses. This is a different issue than whether you want demand paging. >retrieval systems. These programs tend to have data swapping built into >them (since they tend to allow for unlimited expansion through the use of >files), so why should there be an objection to using paging? Using paging is certainly not objectionable if it does not slow the computer down. On Vax class machines where the hardware is slow in the first place is it easy to create page mapping hardware that can keep up with the cpu memory requests. In machines with significant scalar speed, such as the Cray series, the scalar speed is so fast that you can not implement a memory cache or paging without sacrificing scalar performance. As the primary reason why CRI holds the lion's share of the supercomputer market is scalar performance it don't think they will be putting in paging very soon.
jlg@lanl.ARPA (12/11/85)
In article <2511@umcp-cs.UUCP> mangoe@umcp-cs.UUCP (Charley Wingate) writes: >>I know about all the advantages of bounds checks etc. But on big machines >>I've been without them for so long that I hardly miss them except during >>code development. A production code runs correctly doesn't it 8-)? > >This is fine in systems where there isn't malicious code. In commercial >applications, one must assume there is deliberately destructive code. All machines have SOME bounds checking (even some microprocessors these days). The purpose is mainly to prevent one process from refering to data that belongs to some other process (ie. destructive code must go into the 'privileged mode' in order to access code or data belonging to other processes). It should also be noted that most things like bounds checks, shared memory segments, and the like can exist without any paging. >There are lots of programs, however, which do not consist of a huge table >with a little bit of code hanging off the side. Consider an event-driven >simulation program. A significant fragment of the code is going to be >simply looking for the next event. A relatively small area of the data is >going to be exercised disproportionately. THis even more true of data >retrieval systems. These programs tend to have data swapping built into >them (since they tend to allow for unlimited expansion through the use of >files), so why should there be an objection to using paging? All that you are saying is quite true. I have no objection to paging schemes for the types of applications you describe. In fact, if paging didn't slow down the types of codes we run here, I would have no objection to it at all. Hardware should be selected for those features which best run the type of workload that you have. Paging is just another of those features with strengths and weaknesses like any other - but some people on this network don't seem to realize that virtual memory has weaknesses. By the way, virtual memory does not allow for 'unlimited expansion'. I know people with jobs that routinely access sets of files that hold more than the entire virtual memory space of most byte addressable machines (VAXen and the like). For them, virtual memory is just another form of offline store with a set of limitations similar to any other. J. Giles Los Alamos
callen@ada-uts.UUCP (12/11/85)
Yet another reason for having a paged memory architecture is the ease it provides in MANAGING a big REAL memory. In a purely segmented machine a segment must occupy one (potentially big) contiguous chunk of real storage. Once a segment isn't needed any more, you may have to move alot of other stuff around in memory to reclaim the "hole". With paging, you can just change the way the virtual address space maps to real storage - no movement of data or code needed. SO - give me a paged AND segmented architecture AND enough real storage so that I never have to page to disk and then see how happy I am! - Jerry Callen ...ihnp4!inmet!ada-uts!callen If I said something stupid, please hold it against ME and not my employer. Better still, just assume that I AM stupid and let it slide...
phil@amdcad.UUCP (Phil Ngai) (12/14/85)
In article <7900003@ada-uts.UUCP> callen@ada-uts.UUCP writes: >SO - give me a paged AND segmented architecture AND enough real >storage so that I never have to page to disk and then see how >happy I am! Hmm, how about Multics? Too big? Too slow? How about an 80386? It's got paged segments which can be as large as 4 Gb each. -- Even lefties have rights! Phil Ngai +1 408 749-5720 UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil ARPA: amdcad!phil@decwrl.dec.com