這篇文章主要介紹了DotNet并行計(jì)算的使用誤區(qū)有哪些，具有一定借鑒價(jià)值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

創(chuàng)新互聯(lián)建站堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都做網(wǎng)站、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時(shí)代的康巴什網(wǎng)站設(shè)計(jì)、移動(dòng)媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

并行計(jì)算或稱平行計(jì)算是相對(duì)于串行計(jì)算來(lái)說(shuō)的。所謂并行計(jì)算可分為時(shí)間上的并行和空間上的并行。 時(shí)間上的并行就是指流水線技術(shù)，而空間上的并行則是指用多個(gè)處理器并發(fā)的執(zhí)行計(jì)算。

并行計(jì)算無(wú)疑是.NetFramework平臺(tái)的一大亮點(diǎn)，它自動(dòng)的將一個(gè)任務(wù)分解，并以并發(fā)的形式執(zhí)行，程序員不用操心各任務(wù)之間的協(xié)作和同步問(wèn)題，這使得可以更加專注于業(yè)務(wù)的實(shí)現(xiàn)。

.NET 中的 TPL(Task Parallel Library)，中文意思是任務(wù)并行庫(kù)，它的設(shè)計(jì)是為了能更簡(jiǎn)單地編寫可自動(dòng)使用多處理器的托管代碼。使用該庫(kù)，用戶可以非常方便地用現(xiàn)有序列代碼表達(dá)潛在并行性，這樣序列代碼中公開的并行任務(wù)將會(huì)在所有可用的處理器上同時(shí)運(yùn)行，通常這會(huì)大大提高速度。

但是，從網(wǎng)上很多已經(jīng)發(fā)布的并行計(jì)算的例子來(lái)講，有很多存在一定的誤區(qū)甚至是誤導(dǎo)，這導(dǎo)致了一線編程人員產(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ì)算與單行方式程序性能比較的例子中，很多都包含類似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)門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)題，首先要保證你的樣本或需求適合并行處理，比如寫排序算法時(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ì)于字符串處理還是很令人滿意的。所以不是所有情況都適合使用TPL庫(kù)處理程序，這一點(diǎn)對(duì)于程序中的遍歷情景很重要，在使用PLINQ時(shí)，建議先分析樣本空間的類型與具體操作，再?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)門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ì)磁盤等“寫”要求的競(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)步的要求，不是嗎？

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“DotNet并行計(jì)算的使用誤區(qū)有哪些”這篇文章對(duì)大家有幫助，同時(shí)也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識(shí)等著你來(lái)學(xué)習(xí)!