home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / next / misc / 18730 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  3.0 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!news.cs.indiana.edu!umn.edu!msus1.msus.edu!gacvx2.gac.edu!gacvax2!scott
  2. From: scott@nic.gac.edu (Scott Hess)
  3. Newsgroups: comp.sys.next.misc
  4. Subject: Re: Ramdisk coming for NeXT
  5. Message-ID: <SCOTT.92Aug17092422@nic.gac.edu>
  6. Date: 17 Aug 92 14:24:22 GMT
  7. Organization: Gustavus Adolphus College
  8. Lines: 54
  9.  
  10. [Sorry if this article is a repeat - but it never seemed to show
  11. up on our newsfeed, and nobody's replied anyhow.  Perhaps we've
  12. got NNTP problems?  I don't know.]
  13.  
  14. In article <1992Aug13.151354.11149@Informatik.TU-Muenchen.DE>
  15.     MeyerGru@Informatik.TU-Muenchen.DE (Uwe Meyer-Gruhl) writes:
  16. >Oh. I forgot something. For those of you who _really_ want to
  17. >optimize their access speeds: It is possible to tell MACH how many
  18. >buffers you want at bootstrap time without actually patching /sdmach.
  19. >Just use 'b sd() sdmach nbuf=128' or any number you like instead
  20. >of 128.  Mileages may vary according to individual application
  21. >profiles.
  22.  
  23. And, in article <1992Aug14.091704.15202@leland.Stanford.EDU>
  24.     marcu@leland.Stanford.EDU (Marc Albert Ullman) writes:
  25. >I had a quick question for you concerning this patch.  I have been
  26. >using a similar modification consisting of only the word at 604776
  27. >and I do see a noticeable difference in performance.  Do have any
  28. >evidence to confirm that it is necessary to NOP out the other
  29. >instructions that you refer to?
  30. <...>
  31. >P.P.S  I have been using 0x40 = 0100 = 64 = 512KB of buffers on a
  32. >       40MB cube.  Did you do any testing with differing values
  33. >       and if so what did you find?  It would be nice if NeXT had
  34. >       some sort of adaptive algorithm based on the amount of total
  35. >       system RAM.
  36.  
  37. Could anyone elaborate on any and all performance improvements
  38. noted?  My sneaking suspicion is that this is like memory upgrades
  39. from 16M to 32M - 8M to 16M is obvious, but it took me around a
  40. month to really realize that the 32M was quite a bit better than
  41. the 16M.
  42.  
  43. I've tried upping my buffers.  I've got 32M on a standalone monochrome
  44. system, and it's mainly used for Edit, Stuart, and InterfaceBuilder
  45. (sometimes), so figuring I could afford the memory, I started
  46. testing values and seeing what they did to make/compiles.  There
  47. appears to be an upper limit in that the startup message might
  48. _say_ that it's got 1024 buffers, but it only allocates 3.19M
  49. (408*8192).
  50.  
  51. In any case, I noted _no_ difference in compilation speed.  The
  52. CPU utilization appeared to be slightly better with more buffers,
  53. but it's not really enough that I'd be confident in recommending
  54. pumping the values up too high.  64 would probably be great, but
  55. higher values didn't seem to help very much at all.  Of course,
  56. this might all be a result of something else entirely - but I'm
  57. tired of rebooting my computer, so we won't find that out from me ...
  58.  
  59. Later,
  60. --
  61. scott hess <shess@ssesco.com>  <Who achieved programmer nirvana on Aug 11th>
  62. 12901 Upton Avenue South, #326  Burnsville, MN 55337 (612) 895-1208 Anytime!
  63.    <Text: One Class to bring them all and in the darkness bind them ...>
  64.