Amdahl's law(阿姆达尔定律)

今天在翻看以前的系统级编程作业时，不经意间看到了Amdahl's law 和 The 80/20 Rule，想起了当时的一些感谢，今天写出来：
　　记得当时刚看完了之后，颇有感触 ，于是找出了Adahl's law 的数学证明：

Speedup(due to EnhanceMent E) = ExcuteTime(without E)/ExcuteTime(With E) = Performance(With E)/Performanc(Without E)

Suppose the enhancement E accelerates a fraction P of one task by a factor S and the remainder of the task unaffected then:

ExcuteTime(With E) = {(1-P) + P/S} * ExcuteTime(Without E);

Speedup(E) = 1/{(1-P)+P/S};

以上就是Amdahl's law证明。

Amdahl's law主要的用途是指出了在计算机体系结构设计过程中，某个部件的优化对整个结构的优化帮助是有上限的，这个极限就是当S->∞时，speedup(E) = 1/(1-P);也从另外一个方面说明了在体系结构的优化设计过程中，应该挑选对整体有重大影响的部件来进行优化，以得到更好的结果。

　　但是过后又仔细想想，感觉不大对头，因为Amdahl他老人家费尽心血搞出来的这个定律同时从另一个方面说明：很多时候做事情只要做到好这样的程度就可以了，不必要事事追求完美，也就是说这是个悲观的定律。
附图片：


下面给出Amdahl's law的完整定义：
基本描述
加速比 并行计算中的加速比是用并行前的执行速度和并行后的执行速度之比来表示的，它表示了在并行化之后的效率提升情况。

Amdahl定理 是固定负载（计算总量不变时）是的量化标准。可用公式：<math>/frac{W_s + W_p}{W_s + /frac{W_p}{p}}</math>来表示。式中<math>W_s, W_p</math>分别表示问题规模的串行分量（问题中不能并行化的那一部分）和并行分量，p表示处理器数量。

讨论
只要注意到<math>p/to /infty</math>时，上式的极限是<math>/frac{W_s}{W}</math>，这意味着无论我们如何增大处理器数目，加速比是无法高于这个数的。

以下是英文课件：

The 80/20 Rule
In the profiling example, we see that most of the CPU time is spent in a fraction of the total program. This is sometimes called the 80/20 rule—that is, 80% of the CPU time is spent in 20% of the program. These places where the computer spends most of its time are also called hot spots, inner loops, and kernels. This is the code you want to optimize.

http://blog.csdn.net/lengmianfo/article/details/848325

Amdahl's Law
The fact that nearly all programs have hot spots is good news. This usually means that a little effort can have large payoffs. The bad news is that once you speed up the hot spots, you will face rapidly diminishing returns on your effort. Amdahl published a famous paper on the limits of parallel processing. He showed that if only part of a program can be sped up with parallel processing, then the sequential part of the program would determine and limit the possible speed up.

Suppose the program really spends 80% of its time in one spot, and suppose you can rewrite this spot to take a negligible amount of time. The program will now execute in 20% of its original time, meaning that it now runs 5 times as fast. So an infinite improvement in the hot spot only gives a 5-fold improvement overall. Getting additional speedup will then require many optimizations throughout the program, each improvement yielding only a small change in overall run time, and it is probable that these improvements won't be worth the effort.

Knowing how to optimize is an important skill. Knowing when to stop optimizing is also important. You can use profiling results to predict the best possible improvement you can get from any particular optimization. For example, if your program spends 20% of its time in one loop, optimizing that loop can speed up the program at most by 1/(1–0.2) = 1.25—that is, by 25%.