Re: Benchmarks - 1.3.11

cloister bell (cloister@hhhh.org)
Mon, 24 Jul 1995 08:33:26 -0700 (PDT)


> Date: Sun, 23 Jul 1995 12:47:53 -0400 (EDT)
> From: dholland@husc.harvard.edu
> To: linux-kernel@vger.rutgers.edu
> Subject: Re: Benchmarks - 1.3.11
>
> > > Each test is run 20 times (10 for the most time-consuming). If I find the
> > > time, I will add the calculation of the standard deviation.
> >
> > I would be interested in seeing that. Its all fine and well to say
> > that task switching times or something has increased + or - 0.82% over
> > the previous version, however when there haven't been any changes that
> > could make a difference in such a thing, then you have to figre that
> > you are actually detecting something else.
>
> Any change can make a small difference in just about anything. Suppose
> somebody added three lines of code to the SCSI driver, and this (by
> being slightly larger) caused the task-switch code to lie across a
> page boundary. Presto! A few more cycles every task-switch, probably,
> and perhaps a 1% drop in switching performance.
>
> Don't underestimate the effects of things like that.

this is a good point. it reminds me of a story i heard (actually, it was
an internal memo that got leaked to the outside world) about the o/s
developers at sgi. if memory serves, the sgi marketers were shouting
"features! features!" at them, and wouldn't let them do any performance
work. every little feature cost a couple of percent performance hit
until the o/s (i forget which one; this was a couple of years ago at
least) was just about unusable on the low end target platforms. the
developer who wrote the memo was complaining about how this was really
stupid and that sgi was shooting itself in the foot by letting this happen.