pem@usage.csd.unsw.oz.au (Peter E. Middleton) (06/03/90)
I am curious to know what is the best size for the RAM cache. I realise that the amount of RAM makes a difference, but assuming adequate RAM how do things like the number of volumes, their types, the number of open files (is this applicable?) etc affect the best choice? Is there a point at which cache managment overhead exceeds any gains? Over to you! regards peter
vossron@Apple.COM (Ronald N. Voss) (06/04/90)
pem@usage.csd.unsw.oz.au (Peter E. Middleton) writes: > I am curious to know what is the best size for the RAM cache. > I realise that the amount of RAM makes a difference, but assuming >adequate RAM how do things like the number of volumes, their types, >the number of open files (is this applicable?) etc affect the >best choice? Is there a point at which cache managment overhead >exceeds any gains? IMHO, there is no best or right size. It depends. It depends on how much memory you have and what you're doing. It depends on what you want to keep in the cache. For example, if you're running uniFinder, you might want to allocate enough to keep Finder resident. If you search for files on your disk often, you might want to allocate enough to get through a complete Find File without tickling the disk. For those who don't have or can't see the disk access LED, I find InUse indispensible. As far as overhead exceeding gains, it's theoretically possible, but you have to get into seek times, rotational latency, CPU and memory speed to find out. -- Ron Voss Apple Computer I speak only for myself.
marc@Apple.COM (Mark Dawson) (06/05/90)
In article <41579@apple.Apple.COM> vossron@Apple.COM (Ronald N. Voss) writes: >pem@usage.csd.unsw.oz.au (Peter E. Middleton) writes: > >> I am curious to know what is the best size for the RAM cache. >> I realise that the amount of RAM makes a difference, but assuming >>adequate RAM how do things like the number of volumes, their types, >>the number of open files (is this applicable?) etc affect the >>best choice? Is there a point at which cache managment overhead >>exceeds any gains? > To give you an example, to compile, link, and Res (via MPW 3.1) my MacApp program (on a IIfx), it took 2 HOURS with RAM cache OFF and 20 MINUTES with a 1 or 1.5 meg RAM cache. Note that increasing the cache 512K from 1meg didn't improve the speed any (I'm still investegating what the speed cutoff is). Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
philip@Kermit.Stanford.EDU (Philip Machanick) (06/06/90)
In article <41628@apple.Apple.COM>, marc@Apple.COM (Mark Dawson) writes: > To give you an example, to compile, link, and Res (via MPW 3.1) my MacApp > program (on a IIfx), it took 2 HOURS with RAM cache OFF and 20 MINUTES with > a 1 or 1.5 meg RAM cache. Note that increasing the cache 512K from 1meg > didn't improve the speed any (I'm still investegating what the speed cutoff > is). Isn't this perhaps an indication that the traditional compile/link/run/crash cycle ought to be re-evaluated? It's hard to discuss alternatives without being accused of starting arguments about "my compiler is better than yours", but I've often felt the "integrated environment vs powerful tools" argument misses the point. RAM is relatively cheap, and designing a whole development system around the premise that it's cheaper to pipe multiple passes through the file system than to store everything in RAM as far as possible is 1970s thinking. So is there a better way? I can't believe using a large RAM cache is the only solution to a performance problem that has at its heart the overall architecture of the program being run. Philip Machanick philip@pescadero.stanford.edu
marc@Apple.COM (Mark Dawson) (06/06/90)
In article <1990Jun5.174114.7515@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >In article <41628@apple.Apple.COM>, marc@Apple.COM (Mark Dawson) writes: >> To give you an example, to compile, link, and Res (via MPW 3.1) my MacApp >> program (on a IIfx), it took 2 HOURS with RAM cache OFF and 20 MINUTES with >> a 1 or 1.5 meg RAM cache. Note that increasing the cache 512K from 1meg >> didn't improve the speed any (I'm still investegating what the speed cutoff >> is). >Isn't this perhaps an indication that the traditional compile/link/run/crash >cycle ought to be re-evaluated? It's hard to discuss alternatives without >being accused of starting arguments about "my compiler is better than yours", >but I've often felt the "integrated environment vs powerful tools" argument >misses the point. RAM is relatively cheap, and designing a whole development >system around the premise that it's cheaper to pipe multiple passes through >the file system than to store everything in RAM as far as possible is 1970s >thinking. So is there a better way? I can't believe using a large RAM cache >is the only solution to a performance problem that has at its heart the >overall architecture of the program being run. > A follow up note: I further reduced my RAM cache from 1meg to 96K and the compile/link time went down to 16 minutes. I've since been told that they way the Mac ram cache is implemented makes it counter-productive to have large caches, since it writes out the cache in 512K blocks (so a large cache will require many writes). Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
marc@Apple.COM (Mark Dawson) (06/07/90)
In article <41664@apple.Apple.COM> marc@Apple.COM (Mark Dawson) writes: >In article <1990Jun5.174114.7515@Neon.Stanford.EDU> philip@pescadero.stanford.edu writes: >>In article <41628@apple.Apple.COM>, marc@Apple.COM (Mark Dawson) writes: >>> To give you an example, to compile, link, and Res (via MPW 3.1) my MacApp >>> program (on a IIfx), it took 2 HOURS with RAM cache OFF and 20 MINUTES with >>> a 1 or 1.5 meg RAM cache. Note that increasing the cache 512K from 1meg >>> didn't improve the speed any (I'm still investegating what the speed cutoff >>> is). >>Isn't this perhaps an indication that the traditional compile/link/run/crash >>cycle ought to be re-evaluated? It's hard to discuss alternatives without >>being accused of starting arguments about "my compiler is better than yours", >>but I've often felt the "integrated environment vs powerful tools" argument >>misses the point. RAM is relatively cheap, and designing a whole development >>system around the premise that it's cheaper to pipe multiple passes through >>the file system than to store everything in RAM as far as possible is 1970s >>thinking. So is there a better way? I can't believe using a large RAM cache >>is the only solution to a performance problem that has at its heart the >>overall architecture of the program being run. >> >A follow up note: I further reduced my RAM cache from 1meg to 96K and the >compile/link time went down to 16 minutes. I've since been told that they >way the Mac ram cache is implemented makes it counter-productive to have large >caches, since it writes out the cache in 512K blocks (so a large cache will >require many writes). > >Mark > I meant 512 byte blocks + a compile (MPW) does a lot of writes. A larger RAM cache may still improve performance if you're doing more reads. Thanks to those who pointed out my typos. Mark -- --------------------------------- Mark Dawson Service Diagnostic Engineering AppleLink: Dawson.M Apple says what it says; I say what I say. We're different ---------------------------------
macman@unix.cis.pitt.edu (Dennis H Lippert) (04/15/91)
Hi, this is my first post to .system, and I have a question... In the recent discussions about memory and System 7.0, everyone (it seems) has mentioned the size of their RAM cache. Further, one metioned how much faster a 128k cache was over a 32k cache. What does the RAM cache do? What would the benefits be on a 2Mb Classic? If any. I've been scared away from caches by working in a public lab full of Pluses (1Mb) on Appleshare, which give lots of "Out of Memory" errors when running a cache. Just curious... Dennis Lippert- macman@unix.cis.pitt.edu E-mail or Post... no matta' to me!