home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / acorn / 8374 < prev    next >
Encoding:
Text File  |  1992-08-26  |  3.4 KB  |  67 lines
  1. Newsgroups: comp.sys.acorn
  2. Path: sparky!uunet!mcsun!ieunet!tcdcs!maths.tcd.ie!chughes
  3. From: chughes@maths.tcd.ie (Conrad Hughes)
  4. Subject: Re: OS differences and improvements (Was Re: new PC's, what's happening acorn?)
  5. Message-ID: <1992Aug27.090413.3631@maths.tcd.ie>
  6. Organization: Dept. of Maths, Trinity College, Dublin, Ireland.
  7. References: <9208250652.AA04072@ucbvax.Berkeley.EDU> <1992Aug25.134924.9601@merlin.dev.cdx.mot.com>
  8. Date: Thu, 27 Aug 1992 09:04:13 GMT
  9. Lines: 56
  10.  
  11. lezz@merlin.dev.cdx.mot.com (Lezz Giles) writes:
  12.  
  13. >Anybody who thinks that VM doesn't and cannot work should (a) try using
  14. >a decent computer, and (b) take a decent computer science course.
  15. MIPS Magnums & SPARCStations (~30 users on a busyish day) might satisfy
  16. you; I'm a mathematician, not a computer scientist though.
  17.  
  18. >For
  19. >many years I worked on an Amdahl mainframe supporting around 200 users
  20. You mean the machines with 64 megabytes of SRAM cache?  These
  21. "illusions" of speed you suffered from may not have been
  22. hallucinations :-)
  23.  
  24. >I'm currently
  25. >on a DECstation - a single user workstation with X windows.  I don't
  26. >notice the VM at all.  I've also seen HP, Sun, etc. etc workstations with
  27. >VM and with the same illusion of no VM.
  28. How many processes were in VM?  The Magnums here spend a lot of time
  29. with ~10Mb of virtual RAM, but this tends to be dead login shells
  30. and things lost in the mists of time.  I have several times tried
  31. running an nth-order arithmetic coder on the machines (suffice to
  32. say at high orders it can easily chew its way through tens of
  33. megabytes of RAM) - when there were no other active users on the
  34. machines (maybe two idle for a couple of days), the load was
  35. 0.0something and all the memory was real.  When it pushed past 30Mb
  36. of virtual memory (with the coder eating 40-50Mb) things were really
  37. thrashing quite badly.  VM is very useful in that it enables me to
  38. run incredibly inefficient, memory-hungry programs with 80%
  39. redundant data structures on machines that wouldn't otherwise cope,
  40. _but_ I am under no illusion that it won't kill the machine while
  41. I'm doing it.  BTW, the VM on these machines seems to dislike the
  42. concept of a process larger than physical RAM :-(
  43.  
  44. >Virtual memory is a fact of life, and virtual memory works extremely well.
  45. At low levels of usage when all that's virtual is suspended or
  46. dead processes, fine.  If it's virtual cos you're running one big
  47. yucky process it shows it up for what it is: memory with a 4ms
  48. access time and transfer rates of a mere few Mb per second..
  49.  
  50. >Before anybody flames me back, make sure that you have satisfied both
  51. >conditions (a) and (b) above.
  52. This wasn't a flame and while I'm sure my "qualifications" will be
  53. totally unstatisfactory for your high standards (maybe it is a flame
  54. ;-}), I have tried making real _use_ of the VM on these systems with
  55. some quite horrible results.  (I ran a MOO on the 16Mb SPARCStation 1
  56. for a while; (MOO is a variety of MUD) database dumps, during which
  57. the MOO ate up ~24Mb (two 12Mb processes) also seriously impacted
  58. on the machine, which was also multiuser - the MOO only existed
  59. outside office hours :-)
  60.  
  61. Conrad
  62. -- 
  63. ,--------------------. Suicide City, Paranoid State. Geddout! trip to, heave'n'
  64. |chughes@maths.tcd.ie| ho, up, down, to'n'fro you have no word please leave us
  65. +-=>Conrad  Hughes<=-+ here close our eyes to the octopus ride isn't it good to
  66. `-------<SICK>-------' be lost in the wood isn't it bad so quiet there . . .
  67.