NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/sys/acorn/8479

Text File | 1992-09-02 | 5.9 KB | 128 lines

Newsgroups: comp.sys.acorn
Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!rpi!scott.skidmore.edu!jduncan
From: [e-mail] (john duncan)
Subject: Re: Virtual Memory
Message-ID: <[e-mail]>
Organization: Skidmore College, Saratoga Springs NY
References: <[e-mail]>
Date: Wed, 2 Sep 1992 17:34:45 GMT
Lines: 117

[e-mail] (Malcolm Lithgow) writes:
> [Giles writes:]
> > (lots of garbage on why VM is terrible deleted (as it should be :-)
>
> Now who is making up articles? (Or simply failing to read them.)
>
> No-one on this group has claimed that VM is terrible. However, I have
> claimed that the standard implementation is very far from optimal.
>
> > Anybody who thinks that VM doesn't and cannot work should (a) try using
> > a decent computer, and (b) take a decent computer science course.
>
> Tch, tch. And I suppose 'decent' means, respectively, 'a computer that
> I've used that makes impressive use of VM' and 'a course that
> brainwashes you into believing that current implementations of VM are
> God's gift to mankind'?
>
> >  For
> > many years I worked on an Amdahl mainframe supporting around 200 users
> > running a SVR2-1/2 (i.e. halfway between release 2 and release 3) Unix.
> > It worked extremely well - you could easily live with the illusion that
> > you were the only user on the system.  Basically, the underlying operations
> > required by a VM are so fast and implemented at such a low level in hardware
> > that the overhead is tiny and totally unnoticed. "Ah but" I hear you cry,
> > "That's fine for mainframes, but what about smaller systems!".
>
> No, I don't cry that. What I do cry is that mainframes are so
> unresponsive that 'you could easily live with the illusion that' you
> were using a ZX-81! Certainly, mainframes a fast a some things (for a
> single user, I mean), but atrociously slow at things that users do most
> of the time (like getting lists of directories, editing files, etc.).
>
> Hardly a good recommendation for traditional style VM, other than that
> the system actually works. I know -- our company uses an Amdahl
> mainframe as our main machine, and using a 386 is almost always
> faster.
>
> >I'm currently
> > on a DECstation - a single user workstation with X windows.  I don't
> > notice the VM at all.  I've also seen HP, Sun, etc. etc workstations with
> > VM and with the same illusion of no VM.
>
> More examples of how the standard implementation of VM slows things
> down.  Consider this: I am currently typing this on a 33MHz '386 with
> 24MB of RAM, a 256KB cache (running at 33MHz, of course), and large,
> fast hard disks (total of 600MB). When I use X on this system, as a
> single user, it is barely able to give similar response to my old
> 4/8MHz ARM-2 system, with no cache and 4MB of RAM (not to mention a
> 20MB hard disk).

If you`ll notice, X was originally designed for a network, not a
single machine. Over the net, Clients work together to give you, the
server the best possible response. (the X basis for Client-server is
opposite from most netted systems.) Therefore, the Window-client is
telling your server to put blah window on the screen, the Desktop
client is telling your server to put blah window on Blah part of your
screen, and the BLAHWorks application tells your server what to put in
the blah window at the Blah part of your desktop. On your machine,
your i386 has to do this all by itself, slowing it down like anything.
The sun, however is meant to work as a MULTI-user system, allowing
anyone within range over Telnet to talk to it, as well as many over
rlogin(in BSD at least) But since its over thenet, suns have a nice
little tendency to use memories on other computers as VM and temporary
disk space, and as a last resort will use its internal disk. The mac,
Has a cute method of dumping the least used parts of a program or file
on disk, leaving the immediate part in memory. I notice very little
change in speed off of my IIcx with a quantum 105LPS, making it
extremely useful for DTP and CAD, as well as for Photoshop and
Raytracing(which is generally slow on macs anyway).

>
> This poor performance can be blamed on a whole range of things, with VM
> having little to blame. Now if I down-grade this '386 to an 8MB system
> (ie. force VM usage), what do I see? A sudden drastic decrease in
> performance, to about half the speed. The reason for this is that X
> uses so much core that it swaps like a maniac. It does this because (a)
> it was written with the assumption of 'I can use all the memory I like'
> encouraged by current VM, and (b) current VM knows nothing about X's
> usage patterns, and so runs blind, making a terrible mess of things.
>
> Now, for me as a person who wants to use a graphical interface (and a
> command-line interface) on an affordable machine -- this is simply not
> on!
>
> Compare this to an A3000 -- it can multitask, etc. and manage it at
> almost twice the speed! Why? Because it's software is memory-miserly
> because VM can't be assumed!
>
> Sure, HP, IBM, DEC, Sun, etc. WorkStations perform well, but they need
> huge volumes of memory and very fast CPU's to manage the trick. And they
> don't have the excuse of being multi-user.
>
> Perhaps we should consider rethinking some assumptions, so that we can
> get even better performance from our current and future hardware?
>
> > Virtual memory is a fact of life, and virtual memory works extremely well.
>
> Virtual memory *is* a fact of life -- I agree. Current implementations
> of VM work, and are sometimes satisfactory, but can be significantly
> improved. Of course, you may disagree, but then, so did the Luddites.
> ;-)
>
> > Before anybody flames me back, make sure that you have satisfied both
> > conditions (a) and (b) above.
>
> I do.
>
> -Malcolm.  [e-mail]  These are merely my opinions.

-John         [e-mail]. Post me flame. I like it.