In message <199610240115.SAA14567@lestat.nas.nasa.gov> Jason Thorpe writes:
: It occurs to me that David is arguing by assertion... I want to see
: numbers (other than lmbench, which is a micro-benchmark, and thus useless
: for measuring real-world performance gains, as far as I'm concerned)
: that prove that shaving 3 usec off of system call overhead really makes
: a difference to applications (which is what computers are for, right?).

A widely used benchmark over in the FreeBSD world to describe systems
in the "world stone"  That is, how long does a standard make world
take on that system.  It is a fairly good measure for me of how well
the system will perform for me and my needs.  It is also useful for
measuring progreses or regress in the vm system as well as comparing
the P6200 MHz machine to that P5-133 machine to see if an upgrade is
cost effective or not for a FreeBSD developer :-).

I've been compiling on and off for a long time a certain large C++
library (I've stopped recently due to changes in employment) on the
same hardware running Linux and FreeBSD.  I found the biggest drop in
compile time happened when FreeBSD's new vm code was stable enough for
me to try.  All other improvements in both systems up to that point
were in the noise.  BTW, Linux was faster by 2-4% before the FreeBSD
vm changes went in, which made FreeBSD faster by about 10%.  It has
been a while since I've run these benchmarks on both systems, so who
knows which would be faster today.  That 15%ish improvement, btw, was
about 10 minutes of wall time, so I was very happy with that :-)

Since my system was bound by I/O, reducing the amount of I/O the
system must do by an improved vm system helped me more than any amount
of system call tweaking would.

Other applications may benefit from this level of optimization.

Warner