> > On Sun, 04 Feb 1996 11:37:47 -0800 
> >  "Michael L. VanLoon -- HeadCandy.com" <michaelv@HeadCandy.com> wrote:
> > 
> >  > Have you ever tried using the -pipe flag as a default build flag?  It
> >  > should nullify any need to run mfs /tmp, at least for compiling.  I'd
> >  > be curious if it makes a difference in your case.  (Is there any
> >  > reason -pipe isn't default in sys.mk?  Does it use up *that* much more
> >  > memory while building?)
> > 
> > I could be a real lose on 4mb sun3/50 systems...
> 
> Using -pipe is a big win. On a system with not enough RAM, and not using
> -pip, the stuff gets written to intermidiate files. If this is an MFS /tmp
> then this is swap, else it is ordinary file system. On a system with less
> memory and -pipe the processes get swapped. If the swapper/pager is good
> enough then what is the difference ?

Uh, there's a big difference between trying to use, say, a working set
of 1.5x your available RAM size, and writing a few files out to /tmp
while using .75x your available RAM size.

in particular, the two 'halves' of your working set will be fighting
each other for RAM, and will cause a lot of paging throughout the
entire compile.  In comparison, writing a few files won't cost much at
all, and all the 'load' of program text is done at once for each
stage.


Batching (yes, batching) works quite well for large jobs, and on a
small-ram machine, the various stages of a compiler could be
considered 'large jobs.'


I have no doubt that on small-ram machines, using -pipe just won't
win; the _amount_ of data you would end up writing to disk if the
working set is significantly larger than RAM far overshadows the cost
of writing a few small temp files.

If the working set really is bigger, there's nothing (except reducing
paging overhead) that an 'improved' VM system can do.  Improving
pageout algorithms may help reduce number of disk I/O's a lot, but if
the working set is large, it just won't help that much.


cgd