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