自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

多核編程的幾個難題及其應對策略

開發(fā) 前端
隨著多核CPU的出世,多核編程方面的問題將擺上了程序員的日程,有許多老的程序員以為早就有多CPU的機器,業(yè)界在多CPU機器上的編程已經(jīng)積累了很多經(jīng)驗,多核CPU上的編程應該差不多,只要借鑒以前的多任務編程、并行編程和并行算法方面的經(jīng)驗就足夠了。

隨著多核CPU的出世,多核編程方面的問題將擺上了程序員的日程,有許多老的程序員以為早就有多CPU的機器,業(yè)界在多CPU機器上的編程已經(jīng)積累了很多經(jīng)驗,多核CPU上的編程應該差不多,只要借鑒以前的多任務編程、并行編程和并行算法方面的經(jīng)驗就足夠了。

我 想說的是,多核機器和以前的多CPU機器有很大的不同,以前的多CPU機器都是用在特定領域,比如服務器,或者一些可以進行大型并行計算的領域,這些領域 很容易發(fā)揮出多CPU的優(yōu)勢,而現(xiàn)在多核機器則是應用到普通用戶的各個層面,特別是客戶端機器要使用多核CPU,而很多客戶端軟件要想發(fā)揮出多核的并行優(yōu) 勢恐怕沒有服務器和可以進行大型并行計算的特定領域簡單。

這 次參加CSDN大會時和孟巖先生聊起多核編程時,孟巖先生對多核編程的前途感覺到很悲觀,和去年見到他時對多核編程的前景看法完全發(fā)生了改變。想來孟巖先 生對多核編程方面有了很深刻的理解,由于時間問題,沒能和孟巖先生在這方面深入聊下去。在回來的路上,我重新思考了一下關于多核編程方面的困難之處,今天 回到家趕緊把它寫了下來,貼出來分享給大家。

難題一:串行化方面的難題

1)加速系數(shù)

衡量多處理器系統(tǒng)的性能時,通常要用到的一個指標叫做加速系數(shù),定義如下:

S(p) = 使用單處理器執(zhí)行時間(最好的順序算法)/ 使用具有p個處理器所需執(zhí)行時間

2)阿姆爾達定律

并行處理時有一個阿姆爾達定律,用方程式表示如下:

S(p) = p / (1 + (p-1)*f)

其中 S(p)表示加速系數(shù)

p表示處理器的個數(shù)

f表示串行部分所占整個程序執(zhí)行時間的比例

當f = 5%, p = 20時, S(p) = 10.256左右

當f = 5%, p = 100時, S(p) = 16.8左右

也就是說只要有5%的串行部分,當處理器個數(shù)從20個增加到100個時,加速系數(shù)只能從10.256增加到16.8左右,處理器個數(shù)增加了5倍,速度只增加了60%多一點。即使處理器個數(shù)增加到無窮多個,加速系數(shù)的極限值也只有20。

如果按照阿姆爾達定律的話,可以說多核方面幾乎沒有任何發(fā)展前景,即使軟件中只有1%的不可并行化部分,那么最大加速系統(tǒng)也只能到達100,再多的CPU也無法提升速度性能。按照這個定律,可以說多核CPU的發(fā)展讓摩爾定律延續(xù)不了多少年就會到達極限。

3)Gustafson定律

Gustafson 提出了和阿姆爾達定律不同的假設來證明加速系數(shù)是可以超越阿姆爾達定律的限制的,Gustafson認為軟件中的串行部分是固定的,不會隨規(guī)模的增大而增 大,并假設并行處理部分的執(zhí)行時間是固定的(服務器軟件可能就是這樣)。Gustafson定律用公式描述如下:

S(p) = p + (1-p)*fts

其中fts表示串行執(zhí)行所占的比例

如果串行比例為5%,處理器個數(shù)為20個,那么加速系數(shù)為20+(1-20)*5%=19.05

如果串行比例為5%,處理器個數(shù)為100個,那么加速系數(shù)為100+(1-100)*5%=95.05

Gustafson定律中的加速系數(shù)幾乎跟處理器個數(shù)成正比,如果現(xiàn)實情況符合Gustafson定律的假設前提的話,那么軟件的性能將可以隨著處理個數(shù)的增加而增加。

4)實際情況中的串行化分析

阿姆爾達定律和Gustafson定律的計算結果差距如此之大,那么現(xiàn)實情況到底是符合那一個定律呢?我個人認為現(xiàn)實情況中既不會象阿姆爾達定律那么悲觀,但也不會象Gustafson定律那么樂觀。為什么這樣說呢?還是進行一下簡單的分析吧。

首先需要確定軟件中到底有那么內(nèi)容不能并行化,才能估計出串行部分所占的比例,20世紀60年代時,Bernstein就給出了不能進行并行計算的三個條件:

條件1:C1寫某一存儲單元后,C2讀該單元的數(shù)據(jù)。稱為“寫后讀”競爭

條件2:C1讀某一存儲單元數(shù)據(jù)后,C2寫該單元。稱為“讀后寫”競爭

條件1:C1寫某一存儲單元后,C2寫該單元。稱為“寫后寫”競爭

滿足以上三個條件中的任何一個都不能進行并行執(zhí)行。不幸的是在實際的軟件中大量存在滿足上述情況的現(xiàn)象,也就是我們常說的共享數(shù)據(jù)要加鎖保護的問題。

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

5)可能的解決措施

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

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

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

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

原文鏈接:http://blog.csdn.net/drzhouweiming/article/details/1559698

責任編輯:陳四芳 來源: blog.csdn.net
相關推薦

2024-01-29 10:34:37

Java編程

2024-08-01 19:43:47

2010-09-27 13:33:26

JVM異常

2017-04-27 20:45:48

爬蟲反爬蟲

2010-11-29 10:11:05

Sybase數(shù)據(jù)庫死鎖

2013-12-16 15:09:15

多核負載

2021-12-31 16:10:46

穩(wěn)定幣數(shù)字貨幣貨幣

2013-12-16 15:04:51

多核編程

2012-10-09 15:50:19

IPv6

2021-02-26 10:51:18

云安全云計算網(wǎng)絡安全

2024-07-29 00:01:00

RabbitMQ消息堆積

2011-05-25 19:53:45

SEO

2011-11-29 13:45:36

思科三網(wǎng)融合

2014-01-16 09:56:26

IPv6商用部署策略

2011-05-24 17:47:40

2024-12-16 12:42:29

2011-05-24 10:02:47

2014-06-04 17:35:12

2024-05-22 08:00:00

2024-11-11 14:23:11

點贊
收藏

51CTO技術棧公眾號