Subject: Re: But why?
To: None <perry@piermont.com>
From: David S. Miller <davem@caip.rutgers.edu>
List: tech-kern
Date: 10/23/1996 16:21:59
   Date: Wed, 23 Oct 1996 15:45:29 -0400
   From: "Perry E. Metzger" <perry@piermont.com>

   "David S. Miller" writes:
   > So true.  Especially as of late my stream of consciousness has been
   > "geese, it has been almost two days since I was able to suck a couple
   > hundred cycles out of a major critical code path, I'm slacking off
   > again."

   Is it just me, or does this sort of activity strike anyone else as
   being a phenomenal waste of time?

???  You call this a micro-optimization and a phenomenal waste of
time?

Consider an activity the kernel does say 2,500 times per second.  If
you scrape say 10 cycles out of that operation, what does that work
out to?  If you can find 10 or 20 places where you can do something
similar, what does this work out to?  And on and on...  With one day
of hacks to memcpy()/csum_partial_copy() alone I was able to gain 3 to
4 MB/s of bandwidth on a 40MHZ processor, the routine changes
themselves were "micro optimizations" but the performance gain was
phenominal.   This is my idea of "sucking cycles out of major critical
code paths."  And it pays off big time in ways that people who use
such systems dearly care about.

Most of the UNIX vendor engineers and renoun performance gurus will
sorely disagree with your statements.

Why do you think the federal government is specing lmbench numbers and
other similar benchmarks for the systems that they will purchase?

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?"

David S. Miller
davem@caip.rutgers.edu