Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.sys.amiga Subject: Re: The Next Generation Message-ID: <2802@cbmvax.UUCP> Date: Tue, 17-Nov-87 01:50:10 EST Article-I.D.: cbmvax.2802 Posted: Tue Nov 17 01:50:10 1987 Date-Received: Thu, 19-Nov-87 05:31:36 EST References: <461@ra.rice.edu> Organization: Commodore Technology, West Chester, PA Lines: 70 in article <461@ra.rice.edu>, phil@titan.rice.edu (William LeFebvre) says: > Summary: no no no no no no > > In article <2785@megaron.arizona.edu> rogerh@arizona.edu (Roger Hayes) writes: >>There have been some folks clamoring for virtual memory.... >>extremely low latency of task switching and the extremely low >>overhead of message passing. Both of these are likely to go down the >>drain if memory protection is added. > > Memory protection != virtual memory Glad someone finally mentioned that, it's true! Both of these are things best done with a hardware MMU; both have been done to some extent in the past in software only. I think both are potentially important, though not equally so, or equally simple to implement in the Amiga OS. In any case, you'll be getting an MMU with the 68020 card for those who are interested, so now at least it makes sense to talk about these things. >>On my Sun at work (a 2-50), I can easily drag a window faster than the >>display can keep up.... This is because Sun task switching is slow -- >>thanks to Unix and virtual memory. UNIX task switching certainly can be a pig, and the slowness may be based on the virtual memory of your system. But chances are, without the VM, you wouldn't be complaining, because the window dragging wouldn't even be a possibility. This must be a general problem with workstations; I've noticed on our Apollo systems here too. They do VM; great! But they have very large tasks to swap around, and not enough real memory. My office A2000 has 5 megs of RAM; most of our Apollos have 2 megs. I never run out on either, though of course my Amiga isn't VMing right now. >>Or we could make the software do it -- write programs in a secure >>language....compilation is a one-time cost, while hardware complexity >>hurts every time you run a program. > > Ahhh, but does the "secure" programming environment encur any extra > run-time software overhead? Compilation may be a one-time cost, but (for > example) array-subscript-bound-checking also hurts every time you run a > program. Really. I could say the same about software VM. Sure I could do it, write a library to AllocVirtual(), LockVirtual(), FreeVirtual(), etc. But that's much more overhead and much less efficiency than a hardware VM system. You might get away with such a thing in the context of DB or text data, but you're certainly not going to profit from swapping in/out code chunks driven by software, unless you load when needed/dump when unused, as the Amiga OS does now, and that's hardly VM. > I'm not saying that I want virtual memory in AmigaOS. Then again, I'm not > saying I don't. I have grown to love VM, but I see that it could very > easily destroy the real-time performance of the Amiga. But if the next > generation isn't going to have virtual memory, at least give us more than > 8 meg of room in the memory map! Personally, I'd like to do both. A properly implemented VM system isn't going to have any effect on performance as long as you've got enough real memory to use. Once you run out of real memory, you're either dead (no VM), or you can page to disk and run the thing that's larger than your real memory. Now, I'd consider the ability to run something an advantage over not being able to run it at all, even if it does incur a performance hit of some kind. > William LeFebvre > Department of Computer Science > Rice University > -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat