home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / acorn / 8394 < prev    next >
Encoding:
Internet Message Format  |  1992-08-27  |  4.2 KB
  1. Path: sparky!uunet!walter!att!ucbvax!toy.usl.com!lithgow
  2. From: lithgow@toy.usl.com (Malcolm Lithgow)
  3. Newsgroups: comp.sys.acorn
  4. Subject: Virtual Memory
  5. Message-ID: <9208271106.AA10343@ucbvax.Berkeley.EDU>
  6. Date: 27 Aug 92 06:54:06 GMT
  7. Sender: usenet@ucbvax.BERKELEY.EDU
  8. Lines: 86
  9.  
  10. [Giles writes:]
  11. > (lots of garbage on why VM is terrible deleted (as it should be :-)
  12.  
  13. Now who is making up articles? (Or simply failing to read them.)
  14.  
  15. No-one on this group has claimed that VM is terrible. However, I have
  16. claimed that the standard implementation is very far from optimal.
  17.  
  18. > Anybody who thinks that VM doesn't and cannot work should (a) try using
  19. > a decent computer, and (b) take a decent computer science course.
  20.  
  21. Tch, tch. And I suppose 'decent' means, respectively, 'a computer that
  22. I've used that makes impressive use of VM' and 'a course that
  23. brainwashes you into believing that current implementations of VM are
  24. God's gift to mankind'?
  25.  
  26. >  For
  27. > many years I worked on an Amdahl mainframe supporting around 200 users
  28. > running a SVR2-1/2 (i.e. halfway between release 2 and release 3) Unix.
  29. > It worked extremely well - you could easily live with the illusion that
  30. > you were the only user on the system.  Basically, the underlying operations
  31. > required by a VM are so fast and implemented at such a low level in hardware
  32. > that the overhead is tiny and totally unnoticed. "Ah but" I hear you cry,
  33. > "That's fine for mainframes, but what about smaller systems!".
  34.  
  35. No, I don't cry that. What I do cry is that mainframes are so
  36. unresponsive that 'you could easily live with the illusion that' you
  37. were using a ZX-81! Certainly, mainframes a fast a some things (for a
  38. single user, I mean), but atrociously slow at things that users do most
  39. of the time (like getting lists of directories, editing files, etc.).
  40.  
  41. Hardly a good recommendation for traditional style VM, other than that
  42. the system actually works. I know -- our company uses an Amdahl
  43. mainframe as our main machine, and using a 386 is almost always
  44. faster.
  45.  
  46. >I'm currently
  47. > on a DECstation - a single user workstation with X windows.  I don't
  48. > notice the VM at all.  I've also seen HP, Sun, etc. etc workstations with
  49. > VM and with the same illusion of no VM.
  50.  
  51. More examples of how the standard implementation of VM slows things
  52. down.  Consider this: I am currently typing this on a 33MHz '386 with
  53. 24MB of RAM, a 256KB cache (running at 33MHz, of course), and large,
  54. fast hard disks (total of 600MB). When I use X on this system, as a
  55. single user, it is barely able to give similar response to my old
  56. 4/8MHz ARM-2 system, with no cache and 4MB of RAM (not to mention a
  57. 20MB hard disk).
  58.  
  59. This poor performance can be blamed on a whole range of things, with VM
  60. having little to blame. Now if I down-grade this '386 to an 8MB system
  61. (ie. force VM usage), what do I see? A sudden drastic decrease in
  62. performance, to about half the speed. The reason for this is that X
  63. uses so much core that it swaps like a maniac. It does this because (a)
  64. it was written with the assumption of 'I can use all the memory I like'
  65. encouraged by current VM, and (b) current VM knows nothing about X's
  66. usage patterns, and so runs blind, making a terrible mess of things.
  67.  
  68. Now, for me as a person who wants to use a graphical interface (and a
  69. command-line interface) on an affordable machine -- this is simply not
  70. on!
  71.  
  72. Compare this to an A3000 -- it can multitask, etc. and manage it at
  73. almost twice the speed! Why? Because it's software is memory-miserly
  74. because VM can't be assumed!
  75.  
  76. Sure, HP, IBM, DEC, Sun, etc. WorkStations perform well, but they need
  77. huge volumes of memory and very fast CPU's to manage the trick. And they
  78. don't have the excuse of being multi-user.
  79.  
  80. Perhaps we should consider rethinking some assumptions, so that we can
  81. get even better performance from our current and future hardware?
  82.  
  83. > Virtual memory is a fact of life, and virtual memory works extremely well.
  84.  
  85. Virtual memory *is* a fact of life -- I agree. Current implementations
  86. of VM work, and are sometimes satisfactory, but can be significantly
  87. improved. Of course, you may disagree, but then, so did the Luddites.
  88. ;-)
  89.  
  90. > Before anybody flames me back, make sure that you have satisfied both
  91. > conditions (a) and (b) above.
  92.  
  93. I do.
  94.  
  95. -Malcolm.  lithgow@usl.com  These are merely my opinions.
  96.