Amdahl's Law
Statistics: That’s Math, Right
Computer systems researchers have a somewhat tortured relationship with statistics and math.
-
On a good day:
-
For extra-special bonus points:
First, Predict
Before performing an experiment and collecting data it is helpful to make predictions.
-
One way to do this is to draw sketches of the graphs you expect to produce.
-
After collecting real results you can compare them against your predictions as a way of developing intuition about your system.
-
(Predictions about simple cases are also good ways to validate models and simulators.)
Love Your Outliers
-
They may just be weird remnants of your measurement harness.
-
They may have a lot more to tell you.
-
Understand them either way.
Deciding What to Improve
Improve the slowest part, right?
-
(Even if it were this simple, getting programmers to work on any one specific thing can be hard. Frequently they decide to optimize something simply because "they want to".)
-
foo
which takes 5 minutes to execute. -
bar
which takes 5 seconds to execute.
Why Not foo
?
What two elements have we missed in our overly-simplistic decision?
-
Significance: how much does
foo
matter? -
Difficulty: how hard is it going to be to improve
foo
?
-
Significance, so let’s start there.
Amdahl’s Law
The impact of any effort to improve system performance is constrained by the performance of the parts of the system not targeted by the improvement.
-
Reducing the execution time of
foo
from + 5 minutes → 1 minute. -
Reducing the execution time of
bar
from + 5 seconds → 4 seconds.
foo
is better:-
absolutely (4 minutes v. 1 second) and
-
proportionally (80% v. 20%).
Not So Fast (Pun Intended)
-
Reducing the execution time of
foo
from + 5 minutes → 1 minute. -
Reducing the execution time of
bar
from + 5 seconds → 4 seconds.
But what if our program spends 95% of its time running bar
but
only 0.1% running foo
?
-
foo
speedup: 0.001 * 240 seconds = 0.24 seconds. -
bar
speedup: 0.95 * 1 = 0.95 seconds.
Amdahl’s Law
Even more colloquially:
Ignore the thing that looks the worst and fix the thing that is doing the most damage.
Systems Are More Complicated Than Algorithms
(Don’t tell Atri.)
-
"The external interface (that is, the requirement) is less precisely defined, more complex, and more subject to change."
-
"The system has much more internal structure, and hence many internal interfaces."
-
"The measure of success is much less clear."
I have designed and built a number of computer systems, some that worked and some that didn’t. I have also used and studied many other systems, both successful and unsuccessful. From this experience come some general hints for designing successful systems. I claim no originality for them; most are part of the folk wisdom of experienced designers. Nonetheless, even the expert often forgets, and after the second system [6] comes the fourth one.