Article View: comp.sys.next.misc
Article #2456Re: Ramdisk coming for NeXT
From: Scott Hess
Date: Mon, 17 Aug 1992 14:24
Date: Mon, 17 Aug 1992 14:24
54 lines
3157 bytes
3157 bytes
[Sorry if this article is a repeat - but it never seemed to show up on our newsfeed, and nobody's replied anyhow. Perhaps we've got NNTP problems? I don't know.] In article <1992Aug13.151354.11149@Informatik.TU-Muenchen.DE> MeyerGru@Informatik.TU-Muenchen.DE (Uwe Meyer-Gruhl) writes: >Oh. I forgot something. For those of you who _really_ want to >optimize their access speeds: It is possible to tell MACH how many >buffers you want at bootstrap time without actually patching /sdmach. >Just use 'b sd() sdmach nbuf=128' or any number you like instead >of 128. Mileages may vary according to individual application >profiles. And, in article <1992Aug14.091704.15202@leland.Stanford.EDU> marcu@leland.Stanford.EDU (Marc Albert Ullman) writes: >I had a quick question for you concerning this patch. I have been >using a similar modification consisting of only the word at 604776 >and I do see a noticeable difference in performance. Do have any >evidence to confirm that it is necessary to NOP out the other >instructions that you refer to? <...> >P.P.S I have been using 0x40 = 0100 = 64 = 512KB of buffers on a > 40MB cube. Did you do any testing with differing values > and if so what did you find? It would be nice if NeXT had > some sort of adaptive algorithm based on the amount of total > system RAM. Could anyone elaborate on any and all performance improvements noted? My sneaking suspicion is that this is like memory upgrades from 16M to 32M - 8M to 16M is obvious, but it took me around a month to really realize that the 32M was quite a bit better than the 16M. I've tried upping my buffers. I've got 32M on a standalone monochrome system, and it's mainly used for Edit, Stuart, and InterfaceBuilder (sometimes), so figuring I could afford the memory, I started testing values and seeing what they did to make/compiles. There appears to be an upper limit in that the startup message might _say_ that it's got 1024 buffers, but it only allocates 3.19M (408*8192). In any case, I noted _no_ difference in compilation speed. The CPU utilization appeared to be slightly better with more buffers, but it's not really enough that I'd be confident in recommending pumping the values up too high. 64 would probably be great, but higher values didn't seem to help very much at all. Of course, this might all be a result of something else entirely - but I'm tired of rebooting my computer, so we won't find that out from me ... Later, -- scott hess <shess@ssesco.com> <Who achieved programmer nirvana on Aug 11th> 12901 Upton Avenue South, #326 Burnsville, MN 55337 (612) 895-1208 Anytime! <Text: One Class to bring them all and in the darkness bind them ...>
Technical Details
Message-ID:
<SCOTT.92Aug17092422@nic.gac.edu>Path:
arc1-ca.pugleaf.net!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!scottShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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 From: scott@nic.gac.edu (Scott Hess) Newsgroups: comp.sys.next.misc Subject: Re: Ramdisk coming for NeXT Message-ID: <SCOTT.92Aug17092422@nic.gac.edu> Date: 17 Aug 92 14:24:22 GMT Organization: Gustavus Adolphus College Lines: 54