[ Sorry to jump into this so late; My e-mail address got popped off
tech-kern somehow... I've read the archives to catch up :-) ]
On Wed, 23 Oct 1996 18:06:38 -0400
"Perry E. Metzger" <perry@piermont.com> wrote:
> I frequently implement optimizations, but they tend to be better
> algorithms. These usually get you BIG improvements -- things like
> multiples in performance, not tiny increments.
I'd definitely agree with Perry, here. Concentrate on optimizations
which give you a big gain, at first. As Perry noted, often these
optimizations come in the form of different data structures and/or
algorithms.
If you're looking to shave a usec or 3 off of a system call, consider
all of the other things that might be occurring in a Real Life
system call. The value of shaving a usec or 3 off the call overhead
is like saying "My sports car is too heavy; I think I'll drill holes
in the clutch pedal." (yes, I know Mazda did this with the new RX-7s).
When you micro-optimize, you have to see really long uptimes in order
to see the benefit from this... When you've saves 3 usec off system
call overhead, how much of a measureable performance difference have
you _really_ seen in real-world applications? In any case, in my
experience, I've never seen a Linux system stay up long enough to
get a real benefit from micro-optimization :-) *duck*
[ David sez ]
> > I end with a simple question: "If Charles Schwab on system B could get
> > transactions more quickly then any other broker, much more quickly
> > than they do now with system A, do you think they would switch to B?"
I would say that Charles Schwab ought to have some real, concrete
evidence that there's a real performance benefit from switching
systems. Moving your bread-and-butter around is a risky proposition,
one which a conservative individual would likely baulk at if the
gain was (at best) negligible.
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?).
> I've said repeatedly, the kernel isn't a bottleneck for most
> applications. If you are building a tickerplant, the quality of your
> VM system and the amount of memory you have is the key. If you are
Just a minor nit, Perry... the VM system is in the kernel :-)
But, to address Perry's point, optimizing your VM system isn't about
micro-optimizations. You're typically looking for more efficient
ways to store/find information.
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939