Re: mutexes, locks and so on...

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Wed Nov 24 2010 at 13:05:33 -0500, Thor Lancelot Simon wrote:
> On Wed, Nov 24, 2010 at 07:56:33PM +0200, Antti Kantee wrote:
> > 
> > Dunno about NetBSD specifically, but this suggests great differences:
> > http://www.netbsd.org/~ad/50/img15.html
> 
> The problem is that it demonstrates that NetBSD's better *on that hardware*
> than it was.  There are confounding variables.  How would NetBSD perform
> if the disk had twice the throughput and twice the latency, and page
> faults were 10 times as expensive 1/3 of the time?  Hell if I know.
> 
> You and I may suspect that "that hardware" generalizes to "some interesting
> population of hardware" but it's not exactly easy to prove it.  It is very
> different to control this test so that it actually measures even a small
> set of variables at a time, and all too many of the variables have nothing
> to do with changes to NetBSD at all.

I am, pretty much always, interested in how fast my *applications* run,
not in how fast the OS performs.  So, while build.sh isn't an actual
application, it's at least quite close to one.

If we make the performance test suites easy enough to run, theoretically
we don't have to worry about taking every single parameter into account.
If we have some benchmarked platforms running all the time, good, we can
already get some idea out of that.  Then, people with vested interest
on seeing NetBSD perform for their particular application/hardware can
periodically run the test, feel good if things stay the same/get better,
and blow the whistle if they see anything alarming.  So it's some sort of
"order from chaos" type of approach, where the filtering is delegated
to the members of the community who choose to be interested in it.
The people on these lists are quite smart and talented, so I don't think
we need to worry about drowning in noise, either.