Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 5 Dec 1996 15:26:56 +0900 (JST)
From:      Michael Hancock <michaelh@cet.co.jp>
To:        Mark Mayo <mark@quickweb.com>
Cc:        hackers@freebsd.org
Subject:   Re: New benchmarks to design
Message-ID:  <Pine.SV4.3.95.961205150648.24718A-100000@parkplace.cet.co.jp>
In-Reply-To: <Pine.BSF.3.94.961204202201.5327A-100000@vinyl.quickweb.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Dec 1996, Mark Mayo wrote:

> On Thu, 5 Dec 1996, Michael Hancock wrote:
> 
> > I'd be interested in the following:
> 
> [SNIP]
> > 
> > worldStone: cd /usr/src; make world.  This is important to people who
> > build world a lot.  In observing, results posted on this list there's a
> > big difference when going from 486's to P5's and then to P6's.  However,
> > it does have to move memory around and read and write temp files, object
> > files, and binaries, etc.  I think Staelin paper said that performance
> > will be limited by (1+c/i) where c is compute seconds and i is io seconds.
> > If i is significant then improvements to c will have little effect.  I
> > think we're approaching this.
> > 
> 
> This certainly seems to be the case for me these days.. I did a make world
> last night, and watched it a little more closely than I usually do =) I
> noticed that my CPU didn't really get less than 20% idle for the entire
> build. THe load average on the system hovered around .50
> 
> This would leave me to believe that I'm waiting on I/O more than waiting
> on the CPU. 1+c/i seems like a reasonable function...
> 
> It takes about 3 hours and 15 minutes to do a complete make world

If you have a P5 a P6 will probably get you under 1 hour 30 minutes. 
However, I'm guessing that unless break throughs in disk performance
occur, the gains of the P7 and other faster processors will be less
dramatic. 

One thing is for sure, our buffer cache works well.  We are highly
leveraged towards reads because reads are more frequent. Physical disk
read i/o is actually less frequent than physical disk write i/o because of
the buffer cache.  This is why Seltzer and Oustermann have been looking at
improving write performance. 

The write algorithms in ufs are conservative and use a lot of synchronous
operations.  It also takes pains to improve read performance by careful
placement of data blocks.  The algorithms group writes into cylinder
groups and the algorithm also reduces fragmentation.  Though modern disks
are quite different having zones of cylinders with a different number of
sectors it is believed that the cylinder group optimization is still good
for reads.  The rotational delay stuff is definitely no longer useful, but
we turn it off anyway.

The question is whether all these optimizations at the expense of writes
is really all that useful for general applications since the buffer
cache works so well.

There are a lot of writes in worldStone.

Regards,


Mike Hancock




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.961205150648.24718A-100000>