网络分流器-网络分流器-多核编程的几个难题及其应对策略
戎腾网络: 随着多核CPU的出世,多核编程方面的问题将摆上了程序员的日程,有许多老的程序员以为早就有多C
PU的机器,业界在多CPU机器上的编程已经积累了很多经验,多核CPU上的编程应该差不多,只要借鉴以前的多
任务编程、并行编程和并行算法方面的经验就足够了。
我想说的是,像涉及到网络分流器采集器功能的多核处理板业内统称为业务处理板,而多核机器和以前的多CPU机
器有很大的不同,以前的多CPU机器都是用在特定领域,比如服务器,或者一些可以进行大型并行计算的领域,
这些领域很容易发挥出多CPU的优势,而现在多核机器则是应用到普通用户的各个层面,特别是客户端机器要使
用多核CPU,而很多客户端软件要想发挥出多核的并行优势恐怕没有服务器和可以进行大型并行计算的特定领域
简单!
网络分流器
串行化方面的难题
1)加速系数
衡量多处理器系统的性能时,通常要用到的一个指标叫做加速系数,定义如下:
S(p) = 使用单处理器执行时间(最好的顺序算法)/ 使用具有p个处理器所需执行时间
2)阿姆尔达定律
并行处理时有一个阿姆尔达定律,用方程式表示如下:
S(p) = p / (1 + (p-1)*f)
其中 S(p)表示加速系数
p表示处理器的个数
f表示串行部分所占整个程序执行时间的比例
当f = 5%, p = 20时, S(p) = 10.256左右
当f = 5%, p = 100时, S(p) = 16.8左右
也就是说只要有5%的串行部分,当处理器个数从20个增加到100个时,加速系数只能从10.256增加到16.8左
右,处理器个数增加了5倍,速度只增加了60%多一点。即使处理器个数增加到无穷多个,加速系数的极限值也
只有20。
如果按照阿姆尔达定律的话,可以说多核方面几乎没有任何发展前景,即使软件中只有1%的不可并行化部分,那
么最大加速系统也只能到达100,再多的CPU也无法提升速度性能。按照这个定律,可以说多核CPU的发展让摩
尔定律延续不了多少年就会到达极限。
3)Gustafson定律
Gustafson提出了和阿姆尔达定律不同的假设来证明加速系数是可以超越阿姆尔达定律的限制的,Gustafson认
为软件中的串行部分是固定的,不会随规模的增大而增大,并假设并行处理部分的执行时间是固定的(服务器软
件可能就是这样)。Gustafson定律用公式描述如下:
S(p) = p + (1-p)*fts
其中fts表示串行执行所占的比例
如果串行比例为5%,处理器个数为20个,那么加速系数为20+(1-20)*5%=19.05
如果串行比例为5%,处理器个数为100个,那么加速系数为100+(1-100)*5%=95.05
Gustafson定律中的加速系数几乎跟处理器个数成正比,如果现实情况符合Gustafson定律的假设前提的话,那
么软件的性能将可以随着处理个数的增加而增加。
4)实际情况中的串行化分析
阿姆尔达定律和Gustafson定律的计算结果差距如此之大,那么现实情况到底是符合那一个定律呢?我个人认为
现实情况中既不会象阿姆尔达定律那么悲观,但也不会象Gustafson定律那么乐观。为什么这样说呢?还是进行
一下简单的分析吧。
首先需要确定软件中到底有那么内容不能并行化,才能估计出串行部分所占的比例,20世纪60年代时,Bernstei
n就给出了不能进行并行计算的三个条件:
条件1:C1写某一存储单元后,C2读该单元的数据。称为“写后读”竞争
条件2:C1读某一存储单元数据后,C2写该单元。称为“读后写”竞争
条件1:C1写某一存储单元后,C2写该单元。称为“写后写”竞争
满足以上三个条件中的任何一个都不能进行并行执行。不幸的是在实际的软件中大量存在满足上述情况的现象,
也就是我们常说的共享数据要加锁保护的问题。
加锁保护导致的串行化问题如果在任务数量固定的前提下,串行化所占的比例是随软件规模的增大而减小的,但
不幸的是它会随任务数量的增加而增加,也就是说处理器个数越多,锁竞争导致的串行化将越严重,从而使得串
行化所占的比例随处理器个数的增加而急剧增加。(关于锁竞争导致的串行化加剧情况我会在另一篇文章中讲
解)。所以串行化问题是多核编程面临的一大难题。
5)可能的解决措施
对于串行化方面的难题,首先想到的解决措施就是少用锁,甚至采用无锁编程,不过这对普通程序员来说几乎是
难以完成的工作,因为无锁编程方面的算法太过于复杂,而且使用不当很容易出错,许多已经发表到专业期刊上
的无锁算法后来又被证明是错的,可以想象得到这里面的难度有多大。
第二个解决方案就是使用原子操作来替代锁,使用原子操作本质上并没有解决串行化问题,只不过是让串行化的
速度大大提升,从而使得串行化所占执行时间比例大大下降。不过目前芯片厂商提供的原子操作很有限,只能在
少数地方起作用,芯片厂商在这方面可能还需要继续努力,提供更多功能稍微强大一些的原子操作来避免更多的
地方的锁的使用。
第三个解决方案是从设计和算法层面来缩小串行化所占的比例。也许需要发现实用的并行方面的设计模式来缩减
锁的使用,目前业界在这方面已经积累了一定的经验,如任务分解模式,数据分解模式,数据共享模式,相信随
着多核CPU的大规模使用将来会有更多的新的有效的并行设计模式和算法冒出来。
第四个解决方案是从芯片设计方面来考虑的,由于我对芯片设计方面一无所知,所以这个解决方案也许只是我的
一厢情愿的猜想。主要的想法是在芯片层面设计一些新的指令,这些指令 不 象 以前单核CPU指令那样是由单个C
PU完成的,而是由多个CPU进行并行处理完成的一些并行指令,这样程序员调用这些并行处理指令编程就象编写
串行化程序一样,但又充分利用上了多个CPU的优势。
负载平衡问题!众所周知,网络分流器常用的功能就是负载均衡!
多核编程中的锁竞争难题 这篇文章中讲过一个多核编程中的串行化的难题,这篇文章中再来讲解一下多核编程中
的另外一个难题,就是负载平衡方面的难题。
多核CPU中,要很好地发挥出多个CPU的性能的话,必须保证分配到各个CPU上的任务有一个很好的负载平衡。
否则一些CPU在运行,另外一些CPU处于空闲,无法发挥出多核CPU的优势来。
要实现一个好的负载平衡通常有两种方案,一种是静态负载平衡,另外一种是动态负载平衡。
1、静态负载平衡
静态负载平衡中,需要人工将程序分割成多个可并行执行的部分,并且要保证分割成的各个部分能够均衡地分布
到各个CPU上运行,也就是说工作量要在多个任务间进行均匀的分配,使得达到高的加速系数。
静态负载平衡问题从数学上来说是一个NP完全性问题,Richard M. Karp, Jeffrey D. Ullman, Christos H. Papa
dimitriou, M. Garey, D. Johnson等人相继在1972年到1983年间证明了静态负载问题在几种不同约束条件下的
NP完全性。
虽然NP完全性问题在数学上是难题,但是这并不是标题中所说的难题,因为NP完全性问题一般都可以找到很有
效的近似算法来解决。
2、动态负载平衡
动态负载平衡是在程序的运行过程中来进行任务的分配达到负载平衡的目的。实际情况中存在许多不能由静态负
载平衡解决的问题,比如一个大的循环中,循环的次数是由外部输入的,事先并不知道循环的次数,此时采用静
态负载平衡划分策略就很难实现负载平衡。
动态负载平衡中对任务的调度一般是由系统来实现的,程序员通常只能选择动态平衡的调度策略,不能修改调度
策略,由于实际任务中存在很多的不确定因素,调度算法无法做得很优,因此动态负载平衡有时可能达不到既定
的负载平衡要求。
网络分流器用的业务处理板多核
戎腾网络多核NPU处理板(Ezchip NPS400),使用主频800MHz 的NPS400,4K个处理线程,内存48G,支持
正则表达式匹配、5级QoS调度策略、大容量报文输出缓冲、2M项带掩码的多元组规则、1亿精确五元组规则,
处理能力400Gbps,正则表达式匹配能力200Gbps。可使用EC-X16万兆子卡、EC-Z2X4 100G子卡,定于网络
流量分析业务、深度报文检测、负载均衡、在线流量控制等。
网络分流器盒式1U
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31546517/viewspace-2213078/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/31546517/viewspace-2213078/