Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

["Devon H. O'Dell" <devon.odell@gmail.com>]

2011/2/18 Rob Pike <robpike@gmail.com>:
> The more you optimize, the better the odds you slow your program down.
>  Optimization adds instructions and often data, in one of the
> paradoxes of engineering.  In time, then, what you gain by
> "optimizing" increases cache pressure and slows the whole thing down.
>
> C++ inlines a lot because microbenchmarks improve, but inline every
> modest function in a big program and you make the binary much bigger
> and blow the i-cache.

I think what I've been trying to say in this thread doesn't clash with
anything that you, Erik, or others have said. Understanding the
system, the complexity you are introducing, and carefully measuring
the net effect are all important parts of the optimization process.
You can't just switch from one data structure to another. Skip lists
are a really great example: they have really amazing properties, but
you trash your cache when you use them, and gathering entropy to
determine where a node is placed is *not* cheap. In the end, an
optimization that slows things down is not an optimization at all. You
can't do it if you don't understand what you're doing, and you don't
understand the overall effect.

I don't think that Linux's gettimeofday(2) optimization falls into
this category, though I do think that some of the similar
optimizations they've done using the same approach do. In this
specific case, it is an easy optimization that is cheap and works
quite well. It provides measurable performance improvements in the
general case, as well as in special cases. As mentioned before, people
who need more accurate times can still use rdtsc.

> -rob

--dho