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

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

戎騰網絡: 隨着多核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的優點來。

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

一、靜態負載平衡

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

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

雖然NP徹底性問題在數學上是難題，可是這並非標題中所說的難題，由於NP徹底性問題通常均可以找到頗有效的近似算法來解決。

二、動態負載平衡

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

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

網絡分流器

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

負載平衡的難題並不在於負載平衡的程度要達到多少，由於即便在各個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核上，負載也許又變得不均衡了。軟件升級也同樣，當軟件增長功能後，負載平衡又會遭到破壞，又須要從新劃分負載使其達到平衡，這樣一來軟件設計的難度和麻煩大大增長了。

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

四、負載平衡的應對策略

對於運算量較小的軟件，即便放到單核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