Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!ut-sally!rice!titan!phil From: phil@titan.rice.edu (William LeFebvre) Newsgroups: comp.sys.amiga Subject: Re: The Next Generation Message-ID: <461@ra.rice.edu> Date: Mon, 16-Nov-87 15:58:34 EST Article-I.D.: ra.461 Posted: Mon Nov 16 15:58:34 1987 Date-Received: Wed, 18-Nov-87 06:15:02 EST References: <2785@megaron.arizona.edu> Sender: usenet@rice.edu Reply-To: phil@Rice.edu (William LeFebvre) Organization: Rice University, Houston Lines: 70 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 >As an extreme example, look at Sun workstations -- it takes tens of >seconds to open a window, because you have to make several trips down >through Unix and back up into the application code to get the job >done. Tripos != Unix. Also: sizeof(Tripos) < sizeof(Unix) A mathematician would write: |Tripos| << |Unix| ("<<" means significantly less than) >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. No, this is almost completely the fault of SunView and Sunwindows. They are huge monolithic monsters that make unreasonable demands of the system's resources. Every SunView process must carry at least 300K of library routines with it in order to run in the environment. After the so-called kernel takes its 400K chunk and each SunView process takes its share, there is very little memory left for the virtual memory system to play with. No virtual memory system is going to be successful when there is less than half a meg of real memory left. Ever seen X run on a Sun? Ignore the bugs, just look at how fast it can move the windows around. That should help demonstrate that the fault is primarily with SunView and NOT just with Unix. >The latest work in distributed operating systems is tending towards a >lightweight process model -- just what we have in the Amiga. Absolutely. And this is exactly what you do NOT have with Unix! I think that comparing Unix+VM to AmigaOS+VM is like comparing apples with stems to pears with stems. >You want more security? Well, I might accept memory *protection* >hardware, as long as the additional cost in task-switching was >recoverable from elsewhere. I think the Amiga really *needs* this. Unpriviledged processes already run with the supervisor bit off. That's the first step. I get tired of non-robust programs walking all over memory because they forgot to check if their last memory alloc returned success. I really think memory *protection* is one of the features that separates a true workstation from a mere home computer/toy. >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. 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! William LeFebvre Department of Computer Science Rice University