DotNet并行計(jì)算的使用誤區(qū)一
并行計(jì)算或稱(chēng)平行計(jì)算是相對(duì)于串行計(jì)算來(lái)說(shuō)的。所謂并行計(jì)算可分為時(shí)間上的并行和空間上的并行。 時(shí)間上的并行就是指流水線(xiàn)技術(shù)，而空間上的并行則是指用多個(gè)處理器并發(fā)的執(zhí)行計(jì)算。
并行計(jì)算無(wú)疑是.Net Framework平臺(tái)的一大亮點(diǎn)，它自動(dòng)的將一個(gè)任務(wù)分解，并以并發(fā)的形式執(zhí)行，程序員不用操心各任務(wù)之間的協(xié)作和同步問(wèn)題，這使得可以更加專(zhuān)注于業(yè)務(wù)的實(shí)現(xiàn)。
.NET 中的 TPL(Task Parallel Library)，中文意思是任務(wù)并行庫(kù)，它的設(shè)計(jì)是為了能更簡(jiǎn)單地編寫(xiě)可自動(dòng)使用多處理器的托管代碼。使用該庫(kù)，用戶(hù)可以非常方便地用現(xiàn)有序列代碼表達(dá)潛在并行性，這樣序列代碼中公開(kāi)的并行任務(wù)將會(huì)在所有可用的處理器上同時(shí)運(yùn)行，通常這會(huì)大大提高速度。
但是，從網(wǎng)上很多已經(jīng)發(fā)布的并行計(jì)算的例子來(lái)講，有很多存在一定的誤區(qū)甚至是誤導(dǎo)，這導(dǎo)致了一線(xiàn)編程人員產(chǎn)生一些錯(cuò)誤的思路，它們多是通過(guò)示例講述并行計(jì)算的性能優(yōu)越性，似乎程序人員可以不費(fèi)吹灰之力就能將程序性能提升N倍，如果這些想法沒(méi)有經(jīng)過(guò)比較就應(yīng)用于實(shí)際，那么就會(huì)造成一定的損失。這篇文章就來(lái)聊聊關(guān)于合理使用并行計(jì)算的問(wèn)題，供大家參考，這些誤區(qū)主要包括：
1. 只要使用并行就會(huì)提高程序性能
2. 并行循環(huán)嵌套越多程序性能越高
3. 并行計(jì)算是運(yùn)行時(shí)的事
下面讓我們來(lái)一個(gè)個(gè)的講解這些誤會(huì)。
誤區(qū)一 .只要使用并行就會(huì)提高程序性能
實(shí)時(shí)并不是這樣，實(shí)際上并行計(jì)算的使用對(duì)前提要求非常嚴(yán)格，一般情況大量使用并行計(jì)算不但不會(huì)提升性能，反而會(huì)適得其反，下面有兩個(gè)Case給大家說(shuō)明。
Case 1. 使用Thread.Sleep()比較并行與單行程序的性能并不客觀。
在許多并行計(jì)算與單行方式程序性能比較的例子中，很多都包含類(lèi)似Thread.Sleep()的語(yǔ)句，運(yùn)行這樣的Demo我們確實(shí)看到，并行的時(shí)間結(jié)果竟然提升如此許多，但是你有沒(méi)有仔細(xì)研究一下時(shí)間降低的原因呢？
有如下兩段代碼：
- Code Part A：
- for (int i = 0; i < 10; i++) { a = i.ToString(); Thread.Sleep(200); }
- Code Part B：
- Parallel.For(0, 10, (i) => { a = i.ToString(); Thread.Sleep(200); });
在我的雙核本機(jī)上，測(cè)試結(jié)果是令人興奮的：Code Part A跑了2秒多，而Code Part B只跑了800多毫秒，時(shí)間大幅降低，然而這樣你就決定將你的代碼遷移到并行方式嗎？
我建議你還是等等再說(shuō)吧，Code Part B比A具有更高性能的原因不是因?yàn)橹鞔a并行而帶來(lái)的性能提升，而是由于Sleep()，在并行環(huán)境中，任務(wù)實(shí)際上只是休息了1/N（N為并行數(shù)量），而不是單行程序中的全部，這是因?yàn)門(mén)PL將循環(huán)工作分解的緣故，在雙核本機(jī)上，Code Part B相當(dāng)于2個(gè)5次的循環(huán)同時(shí)進(jìn)行，Sleep()又很少有共享資源的消耗，不需要與其他進(jìn)程同步，所以運(yùn)行時(shí)間比1次10次的循環(huán)降低了，假如我們?nèi)サ鬋ode Part A、B中的Sleep語(yǔ)句，那么結(jié)果又是如何呢？答案是兩者十分趨近。實(shí)際上在主代碼短短小的情況下，并行計(jì)算會(huì)表現(xiàn)出一定的性能不穩(wěn)定性，這里留一點(diǎn)，感興趣的朋友自己測(cè)試一下吧。
選擇并行計(jì)算處理問(wèn)題，首先要保證你的樣本或需求適合并行處理，比如寫(xiě)排序算法時(shí)就不能使用并行計(jì)算。
Case 2: 并行程序?qū)τ谧址c數(shù)字的處理效率是不同的。
@ 字符串累加：
單行：
- for (int i = 0; i < 100000; i++) { a += i.ToString(); }
并行：
- Parallel.For(0, 100000, (i) => { a += i.ToString(); });
@ 字符串比較：
單行：
- for (int i = 0; i < 100000; i++) { f = a.Equals(i.ToString()); }
并行：
- Parallel.For(0, 100000, (i) => { f = a.Equals(i.ToString()); });
@ 數(shù)字比較：
單行：
- for (int i = 0; i < 100000000; i++) { f = i == j; }
并行：
- Parallel.For(0, 100000000, (i) => { f = i == j; });
運(yùn)行以上三段測(cè)試代碼可知，TPL對(duì)于字符串處理還是很令人滿(mǎn)意的。所以不是所有情況都適合使用TPL庫(kù)處理程序，這一點(diǎn)對(duì)于程序中的遍歷情景很重要，在使用PLINQ時(shí)，建議先分析樣本空間的類(lèi)型與具體操作，再?zèng)Q定使用哪種計(jì)算。
誤區(qū)二.并行循環(huán)嵌套越多程序性能越高
對(duì)于兩層以上循環(huán)的代碼段，在你決定使用并行前，先要做的是發(fā)現(xiàn)這段代碼的主要耗損在哪，是在外層還是在內(nèi)層，只有評(píng)估當(dāng)并行對(duì)性能帶來(lái)的提升大于損耗時(shí)，再重構(gòu)為并行也不遲，因?yàn)門(mén)PL在很多情形都提供了并行支持，很多程序員在能用到并行的地方都用并行，而沒(méi)有經(jīng)過(guò)測(cè)試比較，實(shí)際上有很多時(shí)候，在所有的地方加上并行特性，程序的性能反而會(huì)受到損失，這里就不在給出案例了。
從下圖可以看出，TPL雖然自動(dòng)管理了循環(huán)中的對(duì)象，但是這些“自動(dòng)”是有一些性能損失的，如果我們的代碼中不斷地要求TPL進(jìn)行對(duì)象的拆分、合并、同步，而忽視了業(yè)務(wù)本身的優(yōu)化，那無(wú)疑是對(duì)性能不利的。
在這里Aicken給出一個(gè)建議，就是在并行前，先要評(píng)估這段代碼的任務(wù)量有多大，有沒(méi)有必要并行？這段代碼有沒(méi)有對(duì)磁盤(pán)等“寫(xiě)”要求的競(jìng)爭(zhēng)？代碼是處理什么任務(wù)的，以及代碼的運(yùn)行環(huán)境是否支持并行；再者就是代碼重構(gòu)后進(jìn)行性能測(cè)試，這樣才能保證并行計(jì)算有意義。
其實(shí)，用對(duì)并行計(jì)算除了對(duì)性能的提升外，還有一點(diǎn)可貴的地方，就是對(duì)代碼的重構(gòu)，簡(jiǎn)潔而富有結(jié)構(gòu)性的代碼，更加符合編碼進(jìn)步的要求，不是嗎？
【編輯推薦】
1.3 網(wǎng)格計(jì)算：分布式并行計(jì)算
