戎騰網絡: 隨著多核CPU的出世，多核編程方面的問題將擺上了程序員的日程，有許多老的程序員以為早就有多CPU的機器，業界在多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年代時，Bernstein就給出了不能進行並行計算的三個條件：

條件1：C1寫某一存儲單元後，C2讀該單元的數據。稱為“寫後讀”競爭

條件2：C1讀某一存儲單元數據後，C2寫該單元。稱為“讀後寫”競爭

條件1：C1寫某一存儲單元後，C2寫該單元。稱為“寫後寫”競爭

滿足以上三個條件中的任何一個都不能進行並行執行。不幸的是在實際的軟件中大量存在滿足上述情況的現象，也就是我們常說的共享數據要加鎖保護的問題。

加鎖保護導致的串行化問題如果在任務數量固定的前提下，串行化所占的比例是隨軟件規模的增大而減小的，但不幸的是它會隨任務數量的增加而增加，也就是說處理器個數越多，鎖競爭導致的串行化將越嚴重，從而使得串行化所占的比例隨處理器個數的增加而急劇增加。（關於鎖競爭導致的串行化加劇情況我會在另一篇文章中講解）。所以串行化問題是多核編程面臨的一大難題。

5）可能的解決措施

對於串行化方面的難題，首先想到的解決措施就是少用鎖，甚至采用無鎖編程，不過這對普通程序員來說幾乎是難以完成的工作，因為無鎖編程方面的算法太過於復雜，而且使用不當很容易出錯，許多已經發表到專業期刊上的無鎖算法後來又被證明是錯的，可以想象得到這裏面的難度有多大。

第二個解決方案就是使用原子操作來替代鎖，使用原子操作本質上並沒有解決串行化問題，只不過是讓串行化的速度大大提升，從而使得串行化所占執行時間比例大大下降。不過目前芯片廠商提供的原子操作很有限，只能在少數地方起作用，芯片廠商在這方面可能還需要繼續努力，提供更多功能稍微強大一些的原子操作來避免更多的地方的鎖的使用。

第三個解決方案是從設計和算法層面來縮小串行化所占的比例。也許需要發現實用的並行方面的設計模式來縮減鎖的使用，目前業界在這方面已經積累了一定的經驗，如任務分解模式，數據分解模式，數據共享模式，相信隨著多核CPU的大規模使用將來會有更多的新的有效的並行設計模式和算法冒出來。

第四個解決方案是從芯片設計方面來考慮的，由於我對芯片設計方面一無所知，所以這個解決方案也許只是我的一廂情願的猜想。主要的想法是在芯片層面設計一些新的指令，這些指令不 象以前單核CPU指令那樣是由單個CPU完成的，而是由多個CPU進行並行處理完成的一些並行指令，這樣程序員調用這些並行處理指令編程就象編寫串行化程序一樣，但又充分利用上了多個CPU的優勢。

負載平衡問題!眾所周知,網絡分流器常用的功能就是負載均衡!

多核編程中的鎖競爭難題 這篇文章中講過一個多核編程中的串行化的難題，這篇文章中再來講解一下多核編程中的另外一個難題，就是負載平衡方面的難題。

多核CPU中，要很好地發揮出多個CPU的性能的話，必須保證分配到各個CPU上的任務有一個很好的負載平衡。否則一些CPU在運行，另外一些CPU處於空閑，無法發揮出多核CPU的優勢來。

要實現一個好的負載平衡通常有兩種方案，一種是靜態負載平衡，另外一種是動態負載平衡。

1、靜態負載平衡

靜態負載平衡中，需要人工將程序分割成多個可並行執行的部分，並且要保證分割成的各個部分能夠均衡地分布到各個CPU上運行，也就是說工作量要在多個任務間進行均勻的分配，使得達到高的加速系數。

靜態負載平衡問題從數學上來說是一個NP完全性問題，Richard M. Karp, Jeffrey D. Ullman, Christos H. Papadimitriou, M. Garey, D. Johnson等人相繼在1972年到1983年間證明了靜態負載問題在幾種不同約束條件下的NP完全性。

雖然NP完全性問題在數學上是難題，但是這並不是標題中所說的難題，因為NP完全性問題一般都可以找到很有效的近似算法來解決。

2、動態負載平衡

動態負載平衡是在程序的運行過程中來進行任務的分配達到負載平衡的目的。實際情況中存在許多不能由靜態負載平衡解決的問題，比如一個大的循環中，循環的次數是由外部輸入的，事先並不知道循環的次數，此時采用靜態負載平衡劃分策略就很難實現負載平衡。

動態負載平衡中對任務的調度一般是由系統來實現的，程序員通常只能選擇動態平衡的調度策略，不能修改調度策略，由於實際任務中存在很多的不確定因素，調度算法無法做得很優，因此動態負載平衡有時可能達不到既定的負載平衡要求。

網絡分流器

3、負載平衡的難題在 那 裏？

負載平衡的難題並不在於負載平衡的程度要達到多少，因為即使在各個CPU上分配的任務執行時間存在一些差距，但是隨著CPU核數的增多總能讓總的執行時間下降，從而使加速系數隨CPU核數的增加而增加。

負載平衡的困難之處在於程序中的可並行執行塊很多要靠程序員來劃分，當然CPU核數較少時，比如雙核或4核，這種劃分並不是很困難。但隨著核數的增加，劃分的粒度將變得越來越細，到了16核以上時，估計程序員要為如何劃分任務而抓狂。比如一段順序執行的代碼，放到128核的CPU上運行，要手工劃分成128個任務，其劃分的難度可想而知。

負載劃分的誤差會隨著CPU核數的增加而放大，比如一個需要16個時間單位的程序分到4個任務上執行，平均每個任務上的負載執行時間為4個時間單位，劃分誤差為1個時間單位的話，那麽加速系數變成 16/(4+1)=3.2，是理想情況下加速系數 4的80％。但是如果放到一個16核CPU上運行的話，如果某個任務的劃分誤差如果為0.5個時間單位的話，那麽加速系數變成16/(1+0.5) = 10.67，只有理想的加速系數16的66.7%，如果核數再增加的話，由於誤差的放大，加速系數相比於理想加速系數的比例還會下降。

負載劃分的難題還體現在CPU和軟件的升級上，比如在4核CPU上的負載劃分是均衡的，但到了8核、16核上，負載也許又變得不均衡了。軟件升級也一樣，當軟件增加功能後，負載平衡又會遭到破壞，又需要重新劃分負載使其達到平衡，這樣一來軟件設計的難度和麻煩大大增加了。

如果使用了鎖的話，一些看起來是均衡的負載也可能會由於鎖競爭變得不平衡起來，詳細情況請查查相關的資料,不是什麽大問題! 網絡分流器

4、負載平衡的應對策略

對於運算量較小的軟件，即使放到單核CPU上運行速度也很快，負載平衡做得差一些並沒有太大影響，實際中負載平衡要考慮的是大運算量和規模很大的軟件，這些軟件需要在多核上進行負載平衡才能較好地利用多核來提高性能。

對於大規模的軟件，負載平衡方面采取的應對策略是發展劃分並行塊的宏觀劃分方法，從整個軟件系統層面來進行劃分，而不是象傳統的針對某些局部的程序和算法來進行並行分解，因為局部的程序通常都很難分解成幾十個以上的任務來運行。

另外一個應對策略是在工具層面的，也就是編譯工具能夠協助人工進行並行塊的分解，並找出良好的分解方案來，這方面Intel已經作出了一些努力，但是還需要更多的努力讓工具的功能更強大一些才能應對核數較多時的情況。

多核編程中的鎖競爭問題

在前一篇講解多核編程的幾個難題及其對策（難題一）的文章中提到了鎖競爭會讓串行化隨CPU的核數增多而加劇的現象，這篇文章就來對多核編程的鎖競爭進行深入的分析。

為了簡化起見，我們先看一個簡單的情況，假設有4個對等的任務同時啟動運行，假設每個任務剛開始時有一個需要鎖保護的操作，耗時為1，每個任務其他部分的耗時為25。這幾個任務啟動運行後的運行情況如下圖所示： 此處的圖片有保留,未公布!

網絡分流器ATCA6槽位和14槽位
在上圖中，可以看出第1個任務直接執行到結束，中間沒有等待，第2個任務等待了1個時間單位，第3個任務等待了2個時間單位，第3個任務等待了3個時間單位。

這樣有3個CPU總計等待了6個時間單位，如果這幾個任務是采用OpenMP裏的所有任務都在同一點上進行等待到全部任務執行完再向下執行時，那麽總的運行時間將和第四個任務一樣為29個時間單位，加速系數為：（1＋4×25）/ 29 ＝ 3.48即使以4個任務的平均時間27.5來進行計算，加速系數＝101/27.5 = 3.67，按照阿姆爾達定律來計算加速系數的話，上述應用中，串行時間為1，並行處理的總時間轉化為串行後為100個時間單位，如果放在4核CPU上運行的話，加速系數＝p / (1 + (p-1)f) ＝ 4/(1+(4-1)1/101) = 404/104 = 3.88。

這就產生了一個奇怪的問題，使用了鎖之後，加速系數連阿姆爾達定律計算出來的加速系數都不如，更別說用Gustafson定律計算的加速系數了。

其實可以將上面4個任務的鎖競爭情況推廣到更一般的情況，假設有鎖保護的串行化時間為1，可並行化部分在單核CPU上的運行時間為t，CPU核數為p，那麽在p個對成任務同時運行情況下，鎖競爭導致的總等待時間為：1＋2＋…＋p ＝ p*(p-1)/2

耗時最多的一個任務所用時間為： p + t/p

使用耗時最多的一個任務所用時間來當作並行運行時間的話，加速系數如下

S(p) = (t+1) / (p + t/p) = p(t+1) / (pp+t) （鎖競爭下的加速系數公式）

這個公式表明在有鎖競爭情況下，如果核數固定情況下，可並行化部分越大，那麽加速系數將越大。在並行化時間固定的情況下，如果CPU核數越多，那麽加速系數將越小。

還是計算幾個實際的例子來說明上面公式的效果：

令t=100, p=4, 加速系數＝4×(100 +1)/ (4*4+100) = 3.48

令t=100, p=16, 加速系數＝16×(100+1) / (16*16+100) = 4.54

令t=100, p=64, 加速系數＝64×(100+1) / (64*64+100) = 1.54

令t=100, p=128, 加速系數＝128×(100+1) / (128*128+100) = 0.78

從以上計算可以看出，當核數多到一定的時候，加速系數不僅不增加反而下降，核數增加到128時，加速系數只有0.78，還不如在單核CPU上運行的速度

上面的例子中，鎖保護導致的串行代碼是在任務啟動時調用的，其實對等任務中在其他地方調用的鎖保護的串行代碼也是一樣的。

對等型任務的鎖競爭現象在實際情況中是很常見的，比如服務器軟件，通常各個客戶端處理任務都是對等的，如果在裏面使用了鎖的話，那麽很容易造成上面說的加速系數隨CPU核數增多而下降的現象。

以前的服務器軟件一般運行在雙CPU或四CPU機器上，所以鎖競爭導致的加速系數下降現象不明顯，進入多核時代後，隨著CPU核數的增多，這個問題將變得很嚴重，所以多核時代對程序設計提出了新的挑戰。以前的多任務下的編程思想放到多核編程上不一定行得通。

所以簡單地認為多核編程和以前的多任務編程或並行計算等同的話是不切實際的，在講串行化難題的那篇文章中提出了一些解決方面的對策，但是那些對策還有待業界繼續努力才能做得到。
當然由於目前市面上銷售的多核CPU還是雙核和四核的，等到16核以上的CPU大規模進入市場可能還有幾年時間，相信業界在未來的幾年內能夠對於上面對等任務上的鎖競爭問題找到更好的解決方案。

網絡分流器用的業務處理板多核
戎騰網絡多核NPU處理板（Ezchip NPS400），使用主頻800MHz 的NPS400，4K個處理線程，內存48G，支持正則表達式匹配、5級QoS調度策略、大容量報文輸出緩沖、2M項帶掩碼的多元組規則、1億精確五元組規則，處理能力400Gbps，正則表達式匹配能力200Gbps。可使用EC-X16萬兆子卡、EC-Z2X4 100G子卡，定於網絡流量分析業務、深度報文檢測、負載均衡、在線流量控制等。戎騰網絡分流器
網絡分流器

網絡分流器盒式1U

網絡分流器-網絡分流器-多核編程的幾個難題及其應對策略