Amdahl定律

来源:互联网 发布:php pdo 教程 编辑:程序博客网 时间:2024/03/28 22:37
有些问题使用越多的资源就能越快地解决——越多的工人参与收割庄稼,那么就能越快地完成收获。另一些任务根本就是串行化的——增加更多的工人根本不可能提高收割速度。如果我们使用线程的重要原因之一是为了支配多处理器的能力,我们必须保证问题被恰当地进行了并行化的分解,并且我们的程序有效地使用了这种并行的潜能。
大多数并发程序都与农耕有着很多相似之处,由一系列并行和串行化的片断组成。Amdahl定律描述了在一个系统中,基于可并行化和串行化的组件各自所占的比重,程序通过获得额外的计算资源,理论上能够加速多少。如果F是必须串行化执行的比重,那么Amdahl定律告诉我们,在一个N处理器的机器中,我们最多可以加速:
N无限增大趋近无穷时,speedup的最大值无限趋近1/F,这意味着一个程序中如果50%的处理都需要串行进行的话,speedup只能提升2倍(不考虑事实上有多少线程可用);如果程序的10%需要串行进行,speedup最多能够提高近10倍。Amdahl定律同样量化了串行化的效率开销。在拥有10个处理器的系统中,程序如果有10%是串行化的,那么最多可以加速5.3倍(53%的使用率),在拥有100个处理器的系统中,这个数字可以达到9.2(9%的使用率)。这使得无效的CPU利用永远不可能到达10倍。
图11.1展示了随着串行执行和处理器数量变化,处理器最大限度的利用率的曲线。随着处理器数量的增加,我们很明显地看到,即使串行化执行的程度发生细微的百分比变化,都会大大限制吞吐量随计算资源增加。
第6章探究了如何识别逻辑边界,从而把应用程序分解为不同的任务。但是为了在多处理器系统中预知你的程序是否存在加速的可能性,你同样需要识别你的任务中串行的部分。
图11.1  Amdahl定律中不同串行化的百分比,带来的最大的效能
清单11.1中,假设应用程序中N个线程正在执行doWork,从一个共享的工作队列中取出任务,并处理;假设这里的任务并不依赖其他任务的结果或边界效应。忽略任务进行队列操作的时间,如果我们增加处理器,应用程序会随之发生什么样的改进呢?乍看这个程序可能完全由并行任务组成,并不会相互等待,那么处理器越多,更多的任务就越可能并发处理。然而,其中也包含串行组件——从队列中获取任务。所有工作者线程都共享工作队列,因此它会需要一些同步机制,从而在并发访问中保持完整性。如果通过加锁来守卫队列状态,那么当一个线程从队列中取出任务的时候,其他线程想要取得下一个任务就必须等待——这便是任务处理中串行的部分。
单个任务的处理时间不仅包括执行任务Runnable的时间,也包括从共享队列中取出任务的时间。如果工作队列是LinkedBlockingQueue类型的,这个取出的操作被阻塞的可能性小于使用同步的LinkedList的阻塞可能,这是因为LinkedBlockingQueue使用了更具伸缩性的算法,但是访问所有共享的数据结构,本质上都会向程序引入一个串行的元素。
这个例子同样忽略了另一个的相同的串行源(source of serialization):结果处理。所有有用的计算都产生一些结果集或者边界效应——如果不是,它们可以当作死代码(dead code)被遗弃掉。因为Runnable没有提供明确的结果处理,这些任务必须具有一些边界效应,设定把它们的结果写入日志还是存入一个数据结构。日志文件和结果容器通常由多
清单11.1  串行访问任务队列
public class WorkerThread extends Thread {
     private final BlockingQueue<Runnable> queue;
     public WorkerThread(BlockingQueue<Runnable> queue) {
         this.queue = queue;
     }
     public void run() {
         while (true) {
             try {
                 Runnable task = queue.take();
                 task.run();
             } catch (InterruptedException e) {
                 break; /* 允许线程退出 */
             }
         }
     }
}
个工作者线程共享,并且因此成为了同源的串行部分。如果不是每个线程各自维护自己的结果的数据结构,而是在所有任务都执行完成后合并所有的结果,这最终的合并就成为了一个串行源。
所有的并发程序都有一些串行源;如果你认为你没有,那么去仔细检查吧。
11.2.1  示例:框架中隐藏的串行化
为了观察并行化如何被隐藏在应用程序的架构中,我们可以比较加入线程时的吞吐量,基于观察到的可伸缩性变化来推断串行源。图11.2展示了一个简单的应用程序中,多个线程重复从共享Queue中移出元素,并处理它们,与清单11.1类似。处理的步骤只需要线程本地的计算。如果有一个线程发现队列是空的,它会向队列置入一批新的元素,这样其他的线程在下一次迭代中就不会无事可做。访问共享的队列显然要承担一定程度的串行化,但是处理步骤是完全并行化的,因为它不会引用共享数据。
图11.2的曲线比较了两个均为线程安全Queue的实现:synchronizedList包装了LinkedList,另一个是ConcurrentLinkedQueue。测试跑在8-way Sparc V880,OS为
图11.2  不同队列实现之间的比较
Solaris的系统上。尽管每一次运行代表相同数量的“工作”,我们能够看到,只有改变队列的实现,才能明显影响可伸缩性。
ConcurrentLinkedQueue的吞吐量持续改进,直到它到达了处理器数量,之后会保持不变。另一方面同步LinkedList的吞吐量,在3个线程时表现了其带来的改进,但是之后会下跌,因为同步的开销增加了。图中当线程数为4或5时,竞争是非常激烈的,以至于每次防问队列都要竞争锁,并且吞吐量受控于上下文切换的次数。
吞吐量的不同源自于两个队列实现的串行化不同。同步的LinkedList用一个锁守护着整个队列的状态,在offer和remove调用时都要获取这个锁;ConcurrentLinkedQueue使用了精妙的非阻塞队列算法(参见15.4.2小节),它使用了原子引用来更新各个链接指针。这两者,其中一个是把整个的插入或删除都实现为串行化的,而另一个则是把每个指针的更新变成串行化的。
11.2.2  定性地应用Amdahl定律
如果我们能精确估算出执行中串行部分所占的比重,Amdahl定律量化了使用更多资源时加速的可能性。尽管直接衡量串行化非常困难,Amdahl定律在没有这样的衡量的情况下仍然有用。
因为我们的理想模型受我们所在环境的影响,我们中间很多人都习惯性认为多处理器系统具有2个或4个处理器,或者可能(如果我们进行大胆假设)有几打(a few dozen),因为这是近年来技术上普遍可以达到的。但是随着多核CPU成为主流,系统将具有成百上千个处理器3。看上去适合于4路系统的算法可能含有隐藏的可伸缩性瓶颈,只不过还没有遇到而已。
当我们评估一个算法的时候,考虑其在成百甚至上千个处理器的情况下受到的限制,能够帮助我们洞察伸缩性的极限的出现。例如,11.4.2和11.4.3两节中探讨了两种技术,用来减小锁的粒度:分拆锁(把一个锁分拆成两个),分离锁(把一个锁分拆成多个锁)。透过Amdahl定律来审视它们,我们发现把一个锁分拆成两个,看上去没能在利用多处理器上帮助我们很多,但是分离锁的效果却很好,因为分离出的数量可随着处理器数量的增加而增长。(当然,性能优化应该总是依据真实的性能需求;有时候,把一个锁分拆成两个足可以满足需求了。)