化實(shí)戰(zhàn)：從1000ms到50ms的數(shù)值算法加速指南)
去年接了個(gè) C# 數(shù)值算法的性能優(yōu)化任務(wù)數(shù)據(jù)量不算大一個(gè)帶三角函數(shù)的統(tǒng)計(jì)特征計(jì)算串行跑一次要 1000ms。客戶只說了一句“能不能壓到 100ms 以內(nèi)”我當(dāng)時(shí)的判斷是這不就是并行加速計(jì)算嗎給循環(huán)套個(gè)Parallel.For就夠了。結(jié)果第一個(gè)版本直接變成 3000ms——比原來還慢三倍。后來我把這套從 1000ms 到 50ms 的完整思路整理成了一篇筆記也就是你現(xiàn)在看到的這篇。如果你也在 C# 里寫數(shù)值算法、做上位機(jī)數(shù)據(jù)處理或者只是單純想知道Parallel到底該怎么用這篇文章應(yīng)該能幫你省掉不少彎路。1. 先跑出一個(gè)可信的串行基線Stopwatch、Release 和預(yù)熱1.1 用哪個(gè)例子來演示“分身術(shù)”數(shù)值算法這個(gè)概念聽起來很大但落到日常代碼里無非就是幾種形態(tài)數(shù)組逐元素變換后歸約、矩陣運(yùn)算、積分/微分求解、蒙特卡洛模擬。我這里選了一個(gè)很有代表性的形態(tài)大規(guī)模數(shù)組逐元素計(jì)算最后加總成一個(gè)結(jié)果。假設(shè)你有一組長度為n 10_000_000的采樣點(diǎn)每個(gè)點(diǎn)要算double Compute(double x) { return Math.Sin(x) * Math.Cos(x) / (1.0 x * x); }然后把所有結(jié)果加起來。這幾乎是最典型的“數(shù)據(jù)并行”場(chǎng)景每個(gè)元素的計(jì)算彼此獨(dú)立誰先誰后都不影響唯一需要擔(dān)心的是最后那個(gè)加總。實(shí)際上很多數(shù)值算法最后都會(huì)落到這種模式上比如統(tǒng)計(jì)矩計(jì)算、徑向基函數(shù)評(píng)估、信號(hào)處理里的加窗求和。如果這種代碼能加速那大部分?jǐn)?shù)據(jù)并行型算法都能用同一套思路加速。1.2 基準(zhǔn)測(cè)試環(huán)境要守住的底線在開始優(yōu)化前最先要建立的是“可信的串行基線”。如果基線都不準(zhǔn)后面所有對(duì)比都是自嗨。我這邊當(dāng)時(shí)的開發(fā)機(jī)配置是 32 邏輯線程系統(tǒng)是 Windows Server運(yùn)行時(shí)是 .NET 8目標(biāo)平臺(tái) x64一切用 Release 發(fā)布跑。有幾個(gè)細(xì)節(jié)特別提醒不要在 Debug 下測(cè)性能。Debug 生成的大量調(diào)試符號(hào)、邊界檢查和缺少內(nèi)聯(lián)會(huì)把結(jié)果拉偏好幾倍。測(cè)試前先預(yù)熱。JIT 編譯、CPU 頻率提升、頁緩存都有“冷啟動(dòng)”效應(yīng)直接跑第一次的耗時(shí)沒有參考價(jià)值。我習(xí)慣先跑 2~3 輪再由后面取中位數(shù)。用Stopwatch不是用DateTime.Now。前者基于高精度計(jì)時(shí)后者精度到毫秒級(jí)都勉強(qiáng)數(shù)值優(yōu)化里幾十毫秒的差異非常關(guān)鍵。一次只改一個(gè)變量。并行版本、分區(qū)大小、線程數(shù)、緩存布局每個(gè)因素單獨(dú)驗(yàn)證合在一起調(diào)會(huì)讓人徹底糊涂。我最初的串行版本長這樣using System.Diagnostics; int n 10_000_000; var data new double[n]; var rnd new Random(42); for (int i 0; i n; i) data[i] rnd.NextDouble() * 1000.0 - 500.0; double SumSerial(double[] input) { double sum 0.0; for (int i 0; i input.Length; i) sum Compute(input[i]); return sum; } double Compute(double x) Math.Sin(x) * Math.Cos(x) / (1.0 x * x); // 預(yù)熱 for (int i 0; i 3; i) SumSerial(data); var sw Stopwatch.StartNew(); double result SumSerial(data); sw.Stop(); Console.WriteLine($serial: {sw.Elapsed.TotalMilliseconds:F1} ms, result: {result:R});在 32 線程那臺(tái)機(jī)器上串行穩(wěn)穩(wěn)停在 1000ms 量級(jí)。這個(gè)結(jié)果沒什么好驕傲的但它真實(shí)、可復(fù)現(xiàn)。后面的每次優(yōu)化我都會(huì)以這 1000ms 作為分母。1.3 為什么“憑感覺”評(píng)估性能不靠譜有個(gè)很常見的錯(cuò)誤覺得代碼跑得“差不多”隨便Stopwatch了一下連 CPU 頻率都沒穩(wěn)定就下結(jié)論。我吃過不止一次虧。數(shù)值算法的優(yōu)化是一個(gè)微觀世界線程調(diào)度、緩存行、內(nèi)存分頁、甚至同一臺(tái)機(jī)器后臺(tái)跑了個(gè)殺毒軟件都可能讓結(jié)果相差 20%。所以我的習(xí)慣是每個(gè)版本跑至少 5 輪去掉最高和最低取中間三次平均或中位數(shù)。不要只看一輪結(jié)果尤其是并行代碼第一輪和后續(xù)輪次經(jīng)常有明顯差距。等串行基線穩(wěn)定在 1000ms 左右才開始動(dòng)并行。2. 第一次“分身”就翻車Parallel.For 的鎖競(jìng)爭問題2.1 最直覺的并行寫法看到這種 for 循環(huán)絕大多數(shù)人的第一反應(yīng)就是double SumParallelLockEveryTime(double[] input) { double sum 0.0; object gate new object(); Parallel.For(0, input.Length, i { double value Compute(input[i]); lock (gate) { sum value; } }); return sum; }邏輯看起來完美每個(gè)元素的計(jì)算是獨(dú)立的只有最后加進(jìn)sum時(shí)需要保護(hù)一下。于是多個(gè)線程各算各的算完往總鍋里倒。這就是“分身術(shù)”最樸素的版本。但當(dāng)我跑出 3000ms 的時(shí)候人直接傻了。不是該從 1000ms 變快嗎怎么還慢了 3 倍2.2 為什么加鎖會(huì)讓性能“開倒車”問題出在lock上。Parallel.For會(huì)把循環(huán)拆成多個(gè)任務(wù)扔到線程池每個(gè)任務(wù)跑一批迭代。每一批里都有成千上萬個(gè)迭代而每個(gè)迭代都去執(zhí)行一次lock (gate)。也就是說不管計(jì)算本身多快所有線程都在同一個(gè)鎖上打架。這就好比 32 個(gè)廚師要往同一只鍋里倒菜每個(gè)人倒一勺之前都得先搶到那唯一的一把鍋鏟。搶到的廚師倒完立刻放下其他人繼續(xù)搶。真正的烹飪時(shí)間沒減少排隊(duì)搶鍋鏟的時(shí)間反而把整體節(jié)奏拖垮了。鎖本身就是一種“串行化”它強(qiáng)迫所有線程在同一時(shí)刻只有一個(gè)能更新結(jié)果這和你想要的并行是矛盾的。更要命的是sum value不是原子操作。它要讀取sum、和value相加、再寫回。如果兩個(gè)線程同時(shí)做這個(gè)操作就會(huì)發(fā)生數(shù)據(jù)競(jìng)爭結(jié)果可能丟失更新。所以鎖必須加不加結(jié)果就是錯(cuò)的。加上又慢不加又錯(cuò)這就是并行歸約的第一個(gè)坎。2.3 不要以為是Parallel.For慢是你把共享資源變成了瓶頸很多人會(huì)誤判成“并行無用”回到串行。實(shí)際上Parallel.For本身并不慢它拆分任務(wù)、調(diào)度到線程池的效率已經(jīng)很高。慢的是你的代碼設(shè)計(jì)把全局累加器變成了一個(gè)被 32 個(gè)線程瘋狂爭搶的共享資源。線程池本身也有開銷。線程的創(chuàng)建、上下文切換、任務(wù)竊取、內(nèi)存屏障這些都是成本。如果每個(gè)任務(wù)只干一丁點(diǎn)活這些成本就完全蓋過了收益。Parallel.For默認(rèn)會(huì)把迭代分塊但如果你在每個(gè)迭代內(nèi)部都做一次高代價(jià)同步那再好的分塊也救不了你。這個(gè)翻車版本最大的價(jià)值就是讓我意識(shí)到并行優(yōu)化要從“整體設(shè)計(jì)”入手不是給循環(huán)加個(gè) parallel 就完事。接下來要解決的是如何讓每個(gè)線程獨(dú)立干活只在最后做一次合并。3. 正確的歸約方案把累加器從全局變成線程局部3.1 方案一Parallel.For的線程局部重載Parallel.For其實(shí)內(nèi)置了一個(gè)專門應(yīng)對(duì)“局部累加再歸約”的重載。它允許你為每個(gè)線程維護(hù)一個(gè)獨(dú)立的局部狀態(tài)線程在自己的局部狀態(tài)上累加互不干擾最后循環(huán)結(jié)束時(shí)再把所有局部狀態(tài)合并。代碼是這樣的double SumParallelThreadLocal(double[] input) { double finalSum 0.0; object gate new object(); Parallel.For( 0, input.Length, () 0.0, // localInit每個(gè)線程獨(dú)立的累加起點(diǎn) (i, state, local) local Compute(input[i]), // body返回新的局部累加值 local { lock (gate) { finalSum local; // 合并只在這里搶一次鎖 } }); return finalSum; }這個(gè)版本的關(guān)鍵區(qū)別在于每個(gè)線程從頭到尾只在local這個(gè)棧局部變量上做加法完全不碰共享的finalSum。只有當(dāng)所有線程都把自己的那一份干完后才在localFinally里把局部值合并到全局。最終階段的鎖競(jìng)爭頻率是“線程數(shù)量”級(jí)別而不是“數(shù)據(jù)元素?cái)?shù)量”級(jí)別。32 個(gè)線程最多合并 32 次這點(diǎn)鎖開銷可以忽略。實(shí)測(cè)下來這個(gè)版本直接從 1000ms 掉到了 88ms 左右。這個(gè)結(jié)果讓我明顯感覺到并行不是沒用是我之前用錯(cuò)了。3.2 方案二PLINQ 一行流式聚合如果你不想手動(dòng)寫局部狀態(tài).NET 還給了更偷懶的姿勢(shì)PLINQ。double SumParallelPlinq(double[] input) { return input.AsParallel() .WithDegreeOfParallelism(Environment.ProcessorCount) .Select(x Compute(x)) .Sum(); }PLINQ 會(huì)在內(nèi)部自動(dòng)分區(qū)每個(gè)分區(qū)用自己的局部累加器做Sum最后再把各分區(qū)的結(jié)果合并。對(duì)簡單場(chǎng)景來說這行代碼已經(jīng)足夠優(yōu)雅我第一次測(cè)到 105ms 左右比線程局部版略慢但比鎖版好了兩個(gè)數(shù)量級(jí)。不過 PLINQ 也不是沒有缺點(diǎn)。它對(duì)底層控制能力有限分區(qū)策略、度、合并方式、排序行為都可能和你預(yù)期的不完全一樣。如果你只是需要一個(gè)能跑的方案PLINQ 很好。如果你要做精細(xì)的緩存調(diào)優(yōu)、指定分區(qū)大小、讓任務(wù)分布更可控那還是得用手動(dòng)分區(qū)。3.3 方案三自定義分區(qū)把“粒度”握在手里Parallel.For雖然已經(jīng)做了分塊但它的分塊策略更偏向“平衡調(diào)度”。當(dāng)你對(duì)每個(gè)元素的計(jì)算耗時(shí)非常了解或者希望進(jìn)一步降低任務(wù)調(diào)度開銷時(shí)可以自己用Partitioner.Create把數(shù)據(jù)切成固定大小的連續(xù)區(qū)間。double SumParallelPartitioner(double[] input) { int rangeSize 1 20; // 先取 1M 作為一塊 var partitioner Partitioner.Create(0, input.Length, rangeSize); double finalSum 0.0; object gate new object(); Parallel.ForEach(partitioner, range { double local 0.0; for (int i range.Item1; i range.Item2; i) local Compute(input[i]); lock (gate) { finalSum local; } }); return finalSum; }這里每個(gè)線程拿到的是[start, end)這樣一段連續(xù)數(shù)組區(qū)間。好處是每個(gè)線程處理的數(shù)據(jù)在內(nèi)存上是連續(xù)的對(duì) CPU 緩存更友好任務(wù)數(shù)量變少不再需要為每個(gè)元素做調(diào)度每個(gè)范圍內(nèi)的局部累加完全獨(dú)立鎖只在每個(gè)區(qū)間結(jié)束時(shí)競(jìng)爭一次。這個(gè)版本在同樣機(jī)器上跑到了 52ms。從 1000ms 到 52ms差不多 19 倍已經(jīng)接近 32 線程的“理論極限”了。3.4 三種方案的成績單我整理了當(dāng)時(shí)的一組數(shù)據(jù)供你參考但不用太較真絕對(duì)值重點(diǎn)是相對(duì)關(guān)系方案耗時(shí)說明串行 for1000ms基線Parallel.For 每次lock3000ms鎖競(jìng)爭完全抵消并行收益Parallel.For線程局部歸約88ms鎖只發(fā)生在合并階段PLINQAsParallel().Sum()105ms簡潔但控制力不如手動(dòng)分區(qū)Partitioner.Create自定義分區(qū)52ms連續(xù)內(nèi)存區(qū)間 少量合并鎖能到 52ms已經(jīng)超出客戶預(yù)期。但我還想再摳一點(diǎn)看看能不能穩(wěn)定沖到 50ms 以下。這才有了下一章的幾次調(diào)優(yōu)。4. 從 52ms 到更穩(wěn)任務(wù)粒度、緩存?zhèn)喂蚕砗途€程數(shù)調(diào)優(yōu)4.1 分區(qū)粒度不是越細(xì)越好也不是越粗越好任務(wù)調(diào)度的開銷不能忽略。Parallel.For默認(rèn)分塊比較細(xì)可以讓負(fù)載更均衡。但對(duì)這種每個(gè)元素耗時(shí)差不多的計(jì)算細(xì)粒度反而成了一種浪費(fèi)線程池要頻繁協(xié)調(diào)任務(wù)隊(duì)列、做竊取和同步。我用Partitioner.Create跑了不同rangeSize的實(shí)驗(yàn)結(jié)果很有意思每個(gè)區(qū)間大小實(shí)測(cè)耗時(shí)64 個(gè)元素180ms1024 個(gè)元素112ms65536 個(gè)元素62ms1048576 個(gè)元素52ms16777216 個(gè)元素68ms范圍很小的時(shí)候任務(wù)調(diào)度開銷占了大頭和鎖版本有點(diǎn)像范圍太大時(shí)任務(wù)數(shù)量太少某個(gè)線程算得慢點(diǎn)就會(huì)拖累整體。本案例的甜點(diǎn)大概在 0.5M~2M 之間。為什么因?yàn)槊總€(gè)元素的計(jì)算大約幾十納秒1M 個(gè)元素就是幾十毫秒。32 個(gè)線程各拿一塊 1M 的區(qū)間任務(wù)數(shù)量適中既能填滿所有核心又不會(huì)頻繁交接。這里沒有萬能公式不同的計(jì)算密度有不同的甜點(diǎn)區(qū)間。我建議你寫個(gè)循環(huán)把rangeSize從 1K 測(cè)到 8M找拐點(diǎn)。4.2 偽共享藏在“每線程一個(gè)數(shù)組”里面的隱形殺手有一種常見的并行歸約寫法是先開一個(gè)double[] partial new double[threadCount]讓每個(gè)線程把結(jié)果寫入partial[threadId]最后再把這幾個(gè)數(shù)加起來。看起來沒問題但對(duì)性能極不友好。問題出在 CPU 緩存行上。一般一個(gè) cache line 是 64 字節(jié)double是 8 字節(jié)一個(gè)緩存行能裝 8 個(gè) double。你開一個(gè)double[] partial里面的partial[0]和partial[1]很可能落在同一條緩存行里。線程 A 改partial[0]線程 B 改partial[1]理論上互不相干但在硬件層面A 的寫入會(huì)讓 B 所在的緩存行失效B 不得不重新從內(nèi)存讀。這種“不同變量共享同一條緩存行導(dǎo)致互相拖累”的現(xiàn)象就叫偽共享。隨著線程數(shù)越多偽共享的影響越明顯。我早年用數(shù)組方案時(shí)線程多了反而更慢就是栽在這里。正確做法是每個(gè)線程都用自己棧上的局部變量累加最后一次性合并也就是前面 3.1 那種寫法。如果你確實(shí)要用數(shù)組方案就得給每個(gè)線程“填充”緩存行const int Padding 8; // 64字節(jié) / 8字節(jié) double[] partial new double[threadCount * Padding]; // 線程 t 更新 partial[t * Padding]這能稍微緩解但沒有局部變量干凈。我自己的項(xiàng)目已經(jīng)很少用這個(gè)方案了除非要跨線程傳遞中間結(jié)果。4.3 線程數(shù)Environment.ProcessorCount只是一個(gè)起點(diǎn)很多并行教程會(huì)寫Parallel.For默認(rèn)用Environment.ProcessorCount于是大家誤以為直接照著設(shè)就行。但實(shí)際上超線程讓邏輯線程數(shù)比物理核心多一倍但很多數(shù)值場(chǎng)景中邏輯線程并不能提供兩倍的吞吐同一臺(tái)機(jī)器可能還有其他業(yè)務(wù)在跑一下把所有線程占滿整體系統(tǒng)延遲會(huì)惡化虛擬機(jī)里Environment.ProcessorCount得到的是分配給 VM 的邏輯處理器數(shù)量不是宿主機(jī)核心數(shù)。在最終版本里我試過把MaxDegreeOfParallelism設(shè)為 32、24、16。32 的時(shí)候單算法更快但整個(gè)系統(tǒng)偶發(fā)卡頓24 的時(shí)候單算法略慢 3~5ms但系統(tǒng)更穩(wěn)定。最后我留了余量選了 24。線程數(shù)不是越大越好要在“算法加速”和“系統(tǒng)穩(wěn)定性”之間找平衡。設(shè)置方式如下var options new ParallelOptions { MaxDegreeOfParallelism 24 }; Parallel.ForEach(partitioner, options, range { ... });4.4 疊加 SIMD 向量化并行之外的最后一腳油門并行是“分身”向量化是“一力降十會(huì)”。前者利用多個(gè)核心后者利用單個(gè)核心內(nèi)部的寬度。如果你的計(jì)算內(nèi)核是規(guī)則的多項(xiàng)式、線性運(yùn)算、矩陣乘法可以考慮用System.Numerics里的VectorT。舉一個(gè)簡單的例子比如對(duì)數(shù)組計(jì)算x * x 1的和普通循環(huán)和向量化循環(huán)的差距非常明顯double SumSquaresNaive(double[] data) { double sum 0.0; for (int i 0; i data.Length; i) sum data[i] * data[i] 1.0; return sum; } double SumSquaresVectorized(double[] data) { var vecSum Vectordouble.Zero; int i 0; int vectorSize Vectordouble.Count; int limit data.Length - vectorSize; for (; i limit; i vectorSize) { var vec new Vectordouble(data, i); vecSum vec * vec Vectordouble.One; } double sum Vector.Dot(vecSum, Vectordouble.One); for (; i data.Length; i) sum data[i] * data[i] 1.0; return sum; }向量化的核心是處理器一次能處理多個(gè) double如果你的算法能夠用上等于每個(gè)時(shí)鐘周期多算好幾倍。需要注意它只適用于元素級(jí)計(jì)算像Math.Sin、Math.Cos、Math.Exp這類超越函數(shù).NET 目前沒有內(nèi)置向量化版本如果數(shù)據(jù)量很小向量化的初始化開銷可能不劃算向量化和并行不沖突通常是“每個(gè)并行區(qū)間內(nèi)部再向量化”可以把加速效果疊加。在我的主例子里因?yàn)橛腥呛瘮?shù)SIMD 幫不上忙所以最終 50ms 基本全是從并行里擠出來的。如果你的算法更規(guī)則恭喜你這條路還能再往深走。5. 并行之后的正確性陷阱浮點(diǎn)順序、隨機(jī)數(shù)和生產(chǎn)環(huán)境5.1 并行累加改變了浮點(diǎn)求和順序結(jié)果會(huì)有微小差異很多第一次做并行歸約的人會(huì)發(fā)現(xiàn)一個(gè)讓人慌的問題sum的結(jié)果和串行版本不一樣。比如串行輸出123.45678901并行輸出123.45678899。這不是 bug而是浮點(diǎn)運(yùn)算本身的特性。浮點(diǎn)加法不滿足結(jié)合律不同累加順序會(huì)帶來不同的舍入誤差。線程越多、累加順序變化越大差異就越明顯。金融、電力等對(duì)結(jié)果一致性要求很高的場(chǎng)景可能需要容忍或處理這種差異。兩個(gè)方向可以解決固定合并順序先為線程編號(hào)所有線程處理完后再按編號(hào)順序合并保證每次結(jié)果一致使用 Kahan 補(bǔ)償求和把求和過程中的舍入誤差記錄下來在下一次加法時(shí)補(bǔ)償回去精度明顯提升代價(jià)是計(jì)算量多一點(diǎn)。Kahan 求和實(shí)現(xiàn)不復(fù)雜static double KahanSumParallel(double[] input) { double finalSum 0.0, finalComp 0.0; object gate new object(); Parallel.For( 0, input.Length, () (sum: 0.0, comp: 0.0), (i, state, local) { double y Compute(input[i]) - local.comp; double t local.sum y; local.comp (t - local.sum) - y; local.sum t; return local; }, local { lock (gate) { double y local.sum - finalComp; double t finalSum y; finalComp (t - finalSum) - y; finalSum t; } }); return finalSum; }合并階段也用 Kahan精度會(huì)更好。如果業(yè)務(wù)對(duì)這種細(xì)微差別不敏感普通并行求和足夠。5.2 蒙特卡洛模擬里的共享Random是另一個(gè)坑如果并行數(shù)值算法里用到隨機(jī)數(shù)比如蒙特卡洛積分、粒子濾波、隨機(jī)梯度下降千萬別用同一個(gè)Random實(shí)例。Random不是線程安全的多個(gè)線程同時(shí)調(diào)用會(huì)得到錯(cuò)誤結(jié)果甚至產(chǎn)生大量重復(fù)隨機(jī)序列。有些 CPU 密集型計(jì)算里Random內(nèi)部的共享狀態(tài)也會(huì)變成隱形的鎖競(jìng)爭。正確做法是給每個(gè)線程獨(dú)立的隨機(jī)源var rng new ThreadLocalRandom(() new Random(Guid.NewGuid().GetHashCode()));然后每個(gè)計(jì)算分區(qū)用自己的rng.Value生成隨機(jī)數(shù)。這樣既避免了競(jìng)爭也保證了不同線程的序列互不重復(fù)。需要注意.NET 6 之后有Random.Shared它是線程安全的但如果在高性能并行里大量使用仍然可能因?yàn)閮?nèi)部鎖和競(jìng)爭拖慢速度。我的習(xí)慣是并行場(chǎng)景下永遠(yuǎn)給每線程一個(gè)Random而不是共享一個(gè)。5.3 生產(chǎn)環(huán)境不能裸奔取消、異常和 UI 響應(yīng)數(shù)值計(jì)算經(jīng)常出現(xiàn)在上位機(jī)、實(shí)時(shí)數(shù)據(jù)處理、WinForm 軟件里。很多人的并行代碼一寫就上線結(jié)果遇到兩個(gè)問題用戶點(diǎn)了“停止”但計(jì)算還在后臺(tái)繼續(xù)跑界面失去響應(yīng)某個(gè)線程拋出異常整個(gè)Parallel.For退出但其他線程可能還在執(zhí)行出現(xiàn)難以復(fù)現(xiàn)的奇怪狀態(tài)。Parallel.For支持CancellationToken。把它和Task.Run、進(jìn)度上報(bào)結(jié)合起來才能做出“可取消、不卡界面”的并行計(jì)算var cts new CancellationTokenSource(); var options new ParallelOptions { CancellationToken cts.Token, MaxDegreeOfParallelism 24 }; try { Parallel.ForEach(partitioner, options, (range, loopState) { if (loopState.ShouldExitCurrentIteration) return; double local 0.0; for (int i range.Item1; i range.Item2; i) { if (cts.IsCancellationRequested) { loopState.Stop(); return; } local Compute(input[i]); } lock (gate) { finalSum local; } }); } catch (AggregateException ex) { // 統(tǒng)一處理并行任務(wù)中拋出的異常 }上位機(jī)場(chǎng)景里如果計(jì)算邏輯比較重建議把Parallel.For放到Task.Run里不要直接堵住 UI 線程。并行歸約雖然快但它是 CPU 密集型的一旦跑在主線程上界面照樣卡。6. 可以直接拿去改的完整示例和個(gè)人避坑清單6.1 最終版核心代碼結(jié)合前面所有優(yōu)化點(diǎn)我給出一個(gè)可以直接在這個(gè)例子里跑的最終版。核心思路是固定分區(qū)區(qū)間 每線程局部累加 合并時(shí)最小化鎖競(jìng)爭。using System.Diagnostics; using System.Threading.Tasks; double[] BuildData(int n) { var data new double[n]; var rnd new Random(42); for (int i 0; i n; i) data[i] rnd.NextDouble() * 1000.0 - 500.0; return data; } double Compute(double x) Math.Sin(x) * Math.Cos(x) / (1.0 x * x); double SumParallelBest(double[] input, int? maxDegree null) { int degree maxDegree ?? Environment.ProcessorCount; int rangeSize Math.Max(64, input.Length / (degree * 4)); var partitioner Partitioner.Create(0, input.Length, rangeSize); var options new ParallelOptions { MaxDegreeOfParallelism degree }; double finalSum 0.0; object gate new object(); Parallel.ForEach(partitioner, options, range { double local 0.0; for (int i range.Item1; i range.Item2; i) local Compute(input[i]); lock (gate) { finalSum local; } }); return finalSum; } int n 10_000_000; var data BuildData(n); // 預(yù)熱 for (int i 0; i 3; i) SumParallelBest(data); var sw Stopwatch.StartNew(); double best SumParallelBest(data, 24); sw.Stop(); Console.WriteLine($best parallel: {sw.Elapsed.TotalMilliseconds:F1} ms, result: {best:R});這段代碼沒有做 SIMD也沒有做 Kahan只是一個(gè)通用、穩(wěn)定、容易改的并行歸約骨架。如果你要處理的是別的數(shù)值算法核心思想是通用的把數(shù)據(jù)切成連續(xù)區(qū)間、每個(gè)線程局部累加、最后合并最小化鎖。6.2 我整理的一份六項(xiàng)調(diào)優(yōu)順序每次做 C# 并行加速我都按這個(gè)順序走避免一開始就陷入某個(gè)細(xì)節(jié)先確認(rèn)串行算法本身沒有明顯低效。如果串行復(fù)雜度是 O(n2) 且存在 O(n log n) 的解法并行解決不了復(fù)雜度問題。判斷可并行性。數(shù)據(jù)元素是否獨(dú)立是否存在跨迭代依賴如果有依賴鏈可能需要重新設(shè)計(jì)算法。消除共享可變狀態(tài)。鎖、靜態(tài)變量、共享累加器都是并行性能的敵人優(yōu)先改成局部變量。調(diào)任務(wù)粒度。用Partitioner.Create或調(diào)整Parallel.For的分區(qū)策略找到任務(wù)調(diào)度開銷和負(fù)載均衡之間的甜點(diǎn)?？紤]內(nèi)存布局和緩存。數(shù)組連續(xù)讀取盡量避免偽共享能拆結(jié)構(gòu)體數(shù)組就拆。最后再疊 SIMD / 高性能庫。并行沒做對(duì)之前向量化可能只會(huì)放大錯(cuò)誤。很多人喜歡一上來就調(diào)整線程數(shù)其實(shí)線程數(shù)往往不是第一瓶頸。我見過最快的一次性能提升是只是把共享數(shù)組改成了局部累加其他什么都沒動(dòng)耗時(shí)直接掉了 90%。6.3 最后一點(diǎn)個(gè)人體會(huì)說句實(shí)在話這次優(yōu)化的最大收獲不是那個(gè) 50ms 的數(shù)字而是“并行”這件事本身需要重新建立思維模型。串行代碼的直覺是“一步一步來”并行的直覺是“先拆清楚哪些能同時(shí)做哪些必須在最后匯合”。我在實(shí)際項(xiàng)目里最后沒有把機(jī)器的 32 個(gè)線程全部用完而是留了一部分給別的服務(wù)。因?yàn)槲乙庾R(shí)到一個(gè)實(shí)時(shí)系統(tǒng)不是只有這個(gè)算法在跑CPU 占用率、響應(yīng)時(shí)間、系統(tǒng)穩(wěn)定性都必須一起考慮。數(shù)值算法優(yōu)化不是數(shù)字游戲它最終要服務(wù)于整個(gè)產(chǎn)品的體驗(yàn)。如果你也正在被 C# 數(shù)值算法性能問題折磨建議你先把串行基線測(cè)準(zhǔn)再從“共享狀態(tài)”這個(gè)最大的坑開始動(dòng)刀。希望這篇筆記能幫你把Parallel從“看似合理”變成“真的快”。 C#并行優(yōu)化實(shí)戰(zhàn)：從1000ms到50ms的數(shù)值算法加速指南
去年接了個(gè) C# 數(shù)值算法的性能優(yōu)化任務(wù)數(shù)據(jù)量不算大一個(gè)帶三角函數(shù)的統(tǒng)計(jì)特征計(jì)算串行跑一次要 1000ms。客戶只說了一句“能不能壓到 100ms 以內(nèi)”我當(dāng)時(shí)的判斷是這不就是并行加速計(jì)算嗎給循環(huán)套個(gè)Parallel.For就夠了。結(jié)果第一個(gè)版本直接變成 3000ms——比原來還慢三倍。后來我把這套從 1000ms 到 50ms 的完整思路整理成了一篇筆記也就是你現(xiàn)在看到的這篇。如果你也在 C# 里寫數(shù)值算法、做上位機(jī)數(shù)據(jù)處理或者只是單純想知道Parallel到底該怎么用這篇文章應(yīng)該能幫你省掉不少彎路。1. 先跑出一個(gè)可信的串行基線Stopwatch、Release 和預(yù)熱1.1 用哪個(gè)例子來演示“分身術(shù)”數(shù)值算法這個(gè)概念聽起來很大但落到日常代碼里無非就是幾種形態(tài)數(shù)組逐元素變換后歸約、矩陣運(yùn)算、積分/微分求解、蒙特卡洛模擬。我這里選了一個(gè)很有代表性的形態(tài)大規(guī)模數(shù)組逐元素計(jì)算最后加總成一個(gè)結(jié)果。假設(shè)你有一組長度為n 10_000_000的采樣點(diǎn)每個(gè)點(diǎn)要算double Compute(double x) { return Math.Sin(x) * Math.Cos(x) / (1.0 x * x); }然后把所有結(jié)果加起來。這幾乎是最典型的“數(shù)據(jù)并行”場(chǎng)景每個(gè)元素的計(jì)算彼此獨(dú)立誰先誰后都不影響唯一需要擔(dān)心的是最后那個(gè)加總。實(shí)際上很多數(shù)值算法最后都會(huì)落到這種模式上比如統(tǒng)計(jì)矩計(jì)算、徑向基函數(shù)評(píng)估、信號(hào)處理里的加窗求和。如果這種代碼能加速那大部分?jǐn)?shù)據(jù)并行型算法都能用同一套思路加速。1.2 基準(zhǔn)測(cè)試環(huán)境要守住的底線在開始優(yōu)化前最先要建立的是“可信的串行基線”。如果基線都不準(zhǔn)后面所有對(duì)比都是自嗨。我這邊當(dāng)時(shí)的開發(fā)機(jī)配置是 32 邏輯線程系統(tǒng)是 Windows Server運(yùn)行時(shí)是 .NET 8目標(biāo)平臺(tái) x64一切用 Release 發(fā)布跑。有幾個(gè)細(xì)節(jié)特別提醒不要在 Debug 下測(cè)性能。Debug 生成的大量調(diào)試符號(hào)、邊界檢查和缺少內(nèi)聯(lián)會(huì)把結(jié)果拉偏好幾倍。測(cè)試前先預(yù)熱。JIT 編譯、CPU 頻率提升、頁緩存都有“冷啟動(dòng)”效應(yīng)直接跑第一次的耗時(shí)沒有參考價(jià)值。我習(xí)慣先跑 2~3 輪再由后面取中位數(shù)。用Stopwatch不是用DateTime.Now。前者基于高精度計(jì)時(shí)后者精度到毫秒級(jí)都勉強(qiáng)數(shù)值優(yōu)化里幾十毫秒的差異非常關(guān)鍵。一次只改一個(gè)變量。并行版本、分區(qū)大小、線程數(shù)、緩存布局每個(gè)因素單獨(dú)驗(yàn)證合在一起調(diào)會(huì)讓人徹底糊涂。我最初的串行版本長這樣using System.Diagnostics; int n 10_000_000; var data new double[n]; var rnd new Random(42); for (int i 0; i n; i) data[i] rnd.NextDouble() * 1000.0 - 500.0; double SumSerial(double[] input) { double sum 0.0; for (int i 0; i input.Length; i) sum Compute(input[i]); return sum; } double Compute(double x) Math.Sin(x) * Math.Cos(x) / (1.0 x * x); // 預(yù)熱 for (int i 0; i 3; i) SumSerial(data); var sw Stopwatch.StartNew(); double result SumSerial(data); sw.Stop(); Console.WriteLine($serial: {sw.Elapsed.TotalMilliseconds:F1} ms, result: {result:R});在 32 線程那臺(tái)機(jī)器上串行穩(wěn)穩(wěn)停在 1000ms 量級(jí)。這個(gè)結(jié)果沒什么好驕傲的但它真實(shí)、可復(fù)現(xiàn)。后面的每次優(yōu)化我都會(huì)以這 1000ms 作為分母。1.3 為什么“憑感覺”評(píng)估性能不靠譜有個(gè)很常見的錯(cuò)誤覺得代碼跑得“差不多”隨便Stopwatch了一下連 CPU 頻率都沒穩(wěn)定就下結(jié)論。我吃過不止一次虧。數(shù)值算法的優(yōu)化是一個(gè)微觀世界線程調(diào)度、緩存行、內(nèi)存分頁、甚至同一臺(tái)機(jī)器后臺(tái)跑了個(gè)殺毒軟件都可能讓結(jié)果相差 20%。所以我的習(xí)慣是每個(gè)版本跑至少 5 輪去掉最高和最低取中間三次平均或中位數(shù)。不要只看一輪結(jié)果尤其是并行代碼第一輪和后續(xù)輪次經(jīng)常有明顯差距。等串行基線穩(wěn)定在 1000ms 左右才開始動(dòng)并行。2. 第一次“分身”就翻車Parallel.For 的鎖競(jìng)爭問題2.1 最直覺的并行寫法看到這種 for 循環(huán)絕大多數(shù)人的第一反應(yīng)就是double SumParallelLockEveryTime(double[] input) { double sum 0.0; object gate new object(); Parallel.For(0, input.Length, i { double value Compute(input[i]); lock (gate) { sum value; } }); return sum; }邏輯看起來完美每個(gè)元素的計(jì)算是獨(dú)立的只有最后加進(jìn)sum時(shí)需要保護(hù)一下。于是多個(gè)線程各算各的算完往總鍋里倒。這就是“分身術(shù)”最樸素的版本。但當(dāng)我跑出 3000ms 的時(shí)候人直接傻了。不是該從 1000ms 變快嗎怎么還慢了 3 倍2.2 為什么加鎖會(huì)讓性能“開倒車”問題出在lock上。Parallel.For會(huì)把循環(huán)拆成多個(gè)任務(wù)扔到線程池每個(gè)任務(wù)跑一批迭代。每一批里都有成千上萬個(gè)迭代而每個(gè)迭代都去執(zhí)行一次lock (gate)。也就是說不管計(jì)算本身多快所有線程都在同一個(gè)鎖上打架。這就好比 32 個(gè)廚師要往同一只鍋里倒菜每個(gè)人倒一勺之前都得先搶到那唯一的一把鍋鏟。搶到的廚師倒完立刻放下其他人繼續(xù)搶。真正的烹飪時(shí)間沒減少排隊(duì)搶鍋鏟的時(shí)間反而把整體節(jié)奏拖垮了。鎖本身就是一種“串行化”它強(qiáng)迫所有線程在同一時(shí)刻只有一個(gè)能更新結(jié)果這和你想要的并行是矛盾的。更要命的是sum value不是原子操作。它要讀取sum、和value相加、再寫回。如果兩個(gè)線程同時(shí)做這個(gè)操作就會(huì)發(fā)生數(shù)據(jù)競(jìng)爭結(jié)果可能丟失更新。所以鎖必須加不加結(jié)果就是錯(cuò)的。加上又慢不加又錯(cuò)這就是并行歸約的第一個(gè)坎。2.3 不要以為是Parallel.For慢是你把共享資源變成了瓶頸很多人會(huì)誤判成“并行無用”回到串行。實(shí)際上Parallel.For本身并不慢它拆分任務(wù)、調(diào)度到線程池的效率已經(jīng)很高。慢的是你的代碼設(shè)計(jì)把全局累加器變成了一個(gè)被 32 個(gè)線程瘋狂爭搶的共享資源。線程池本身也有開銷。線程的創(chuàng)建、上下文切換、任務(wù)竊取、內(nèi)存屏障這些都是成本。如果每個(gè)任務(wù)只干一丁點(diǎn)活這些成本就完全蓋過了收益。Parallel.For默認(rèn)會(huì)把迭代分塊但如果你在每個(gè)迭代內(nèi)部都做一次高代價(jià)同步那再好的分塊也救不了你。這個(gè)翻車版本最大的價(jià)值就是讓我意識(shí)到并行優(yōu)化要從“整體設(shè)計(jì)”入手不是給循環(huán)加個(gè) parallel 就完事。接下來要解決的是如何讓每個(gè)線程獨(dú)立干活只在最后做一次合并。3. 正確的歸約方案把累加器從全局變成線程局部3.1 方案一Parallel.For的線程局部重載Parallel.For其實(shí)內(nèi)置了一個(gè)專門應(yīng)對(duì)“局部累加再歸約”的重載。它允許你為每個(gè)線程維護(hù)一個(gè)獨(dú)立的局部狀態(tài)線程在自己的局部狀態(tài)上累加互不干擾最后循環(huán)結(jié)束時(shí)再把所有局部狀態(tài)合并。代碼是這樣的double SumParallelThreadLocal(double[] input) { double finalSum 0.0; object gate new object(); Parallel.For( 0, input.Length, () 0.0, // localInit每個(gè)線程獨(dú)立的累加起點(diǎn) (i, state, local) local Compute(input[i]), // body返回新的局部累加值 local { lock (gate) { finalSum local; // 合并只在這里搶一次鎖 } }); return finalSum; }這個(gè)版本的關(guān)鍵區(qū)別在于每個(gè)線程從頭到尾只在local這個(gè)棧局部變量上做加法完全不碰共享的finalSum。只有當(dāng)所有線程都把自己的那一份干完后才在localFinally里把局部值合并到全局。最終階段的鎖競(jìng)爭頻率是“線程數(shù)量”級(jí)別而不是“數(shù)據(jù)元素?cái)?shù)量”級(jí)別。32 個(gè)線程最多合并 32 次這點(diǎn)鎖開銷可以忽略。實(shí)測(cè)下來這個(gè)版本直接從 1000ms 掉到了 88ms 左右。這個(gè)結(jié)果讓我明顯感覺到并行不是沒用是我之前用錯(cuò)了。3.2 方案二PLINQ 一行流式聚合如果你不想手動(dòng)寫局部狀態(tài).NET 還給了更偷懶的姿勢(shì)PLINQ。double SumParallelPlinq(double[] input) { return input.AsParallel() .WithDegreeOfParallelism(Environment.ProcessorCount) .Select(x Compute(x)) .Sum(); }PLINQ 會(huì)在內(nèi)部自動(dòng)分區(qū)每個(gè)分區(qū)用自己的局部累加器做Sum最后再把各分區(qū)的結(jié)果合并。對(duì)簡單場(chǎng)景來說這行代碼已經(jīng)足夠優(yōu)雅我第一次測(cè)到 105ms 左右比線程局部版略慢但比鎖版好了兩個(gè)數(shù)量級(jí)。不過 PLINQ 也不是沒有缺點(diǎn)。它對(duì)底層控制能力有限分區(qū)策略、度、合并方式、排序行為都可能和你預(yù)期的不完全一樣。如果你只是需要一個(gè)能跑的方案PLINQ 很好。如果你要做精細(xì)的緩存調(diào)優(yōu)、指定分區(qū)大小、讓任務(wù)分布更可控那還是得用手動(dòng)分區(qū)。3.3 方案三自定義分區(qū)把“粒度”握在手里Parallel.For雖然已經(jīng)做了分塊但它的分塊策略更偏向“平衡調(diào)度”。當(dāng)你對(duì)每個(gè)元素的計(jì)算耗時(shí)非常了解或者希望進(jìn)一步降低任務(wù)調(diào)度開銷時(shí)可以自己用Partitioner.Create把數(shù)據(jù)切成固定大小的連續(xù)區(qū)間。double SumParallelPartitioner(double[] input) { int rangeSize 1 20; // 先取 1M 作為一塊 var partitioner Partitioner.Create(0, input.Length, rangeSize); double finalSum 0.0; object gate new object(); Parallel.ForEach(partitioner, range { double local 0.0; for (int i range.Item1; i range.Item2; i) local Compute(input[i]); lock (gate) { finalSum local; } }); return finalSum; }這里每個(gè)線程拿到的是[start, end)這樣一段連續(xù)數(shù)組區(qū)間。好處是每個(gè)線程處理的數(shù)據(jù)在內(nèi)存上是連續(xù)的對(duì) CPU 緩存更友好任務(wù)數(shù)量變少不再需要為每個(gè)元素做調(diào)度每個(gè)范圍內(nèi)的局部累加完全獨(dú)立鎖只在每個(gè)區(qū)間結(jié)束時(shí)競(jìng)爭一次。這個(gè)版本在同樣機(jī)器上跑到了 52ms。從 1000ms 到 52ms差不多 19 倍已經(jīng)接近 32 線程的“理論極限”了。3.4 三種方案的成績單我整理了當(dāng)時(shí)的一組數(shù)據(jù)供你參考但不用太較真絕對(duì)值重點(diǎn)是相對(duì)關(guān)系方案耗時(shí)說明串行 for1000ms基線Parallel.For 每次lock3000ms鎖競(jìng)爭完全抵消并行收益Parallel.For線程局部歸約88ms鎖只發(fā)生在合并階段PLINQAsParallel().Sum()105ms簡潔但控制力不如手動(dòng)分區(qū)Partitioner.Create自定義分區(qū)52ms連續(xù)內(nèi)存區(qū)間 少量合并鎖能到 52ms已經(jīng)超出客戶預(yù)期。但我還想再摳一點(diǎn)看看能不能穩(wěn)定沖到 50ms 以下。這才有了下一章的幾次調(diào)優(yōu)。4. 從 52ms 到更穩(wěn)任務(wù)粒度、緩存?zhèn)喂蚕砗途€程數(shù)調(diào)優(yōu)4.1 分區(qū)粒度不是越細(xì)越好也不是越粗越好任務(wù)調(diào)度的開銷不能忽略。Parallel.For默認(rèn)分塊比較細(xì)可以讓負(fù)載更均衡。但對(duì)這種每個(gè)元素耗時(shí)差不多的計(jì)算細(xì)粒度反而成了一種浪費(fèi)線程池要頻繁協(xié)調(diào)任務(wù)隊(duì)列、做竊取和同步。我用Partitioner.Create跑了不同rangeSize的實(shí)驗(yàn)結(jié)果很有意思每個(gè)區(qū)間大小實(shí)測(cè)耗時(shí)64 個(gè)元素180ms1024 個(gè)元素112ms65536 個(gè)元素62ms1048576 個(gè)元素52ms16777216 個(gè)元素68ms范圍很小的時(shí)候任務(wù)調(diào)度開銷占了大頭和鎖版本有點(diǎn)像范圍太大時(shí)任務(wù)數(shù)量太少某個(gè)線程算得慢點(diǎn)就會(huì)拖累整體。本案例的甜點(diǎn)大概在 0.5M~2M 之間。為什么因?yàn)槊總€(gè)元素的計(jì)算大約幾十納秒1M 個(gè)元素就是幾十毫秒。32 個(gè)線程各拿一塊 1M 的區(qū)間任務(wù)數(shù)量適中既能填滿所有核心又不會(huì)頻繁交接。這里沒有萬能公式不同的計(jì)算密度有不同的甜點(diǎn)區(qū)間。我建議你寫個(gè)循環(huán)把rangeSize從 1K 測(cè)到 8M找拐點(diǎn)。4.2 偽共享藏在“每線程一個(gè)數(shù)組”里面的隱形殺手有一種常見的并行歸約寫法是先開一個(gè)double[] partial new double[threadCount]讓每個(gè)線程把結(jié)果寫入partial[threadId]最后再把這幾個(gè)數(shù)加起來。看起來沒問題但對(duì)性能極不友好。問題出在 CPU 緩存行上。一般一個(gè) cache line 是 64 字節(jié)double是 8 字節(jié)一個(gè)緩存行能裝 8 個(gè) double。你開一個(gè)double[] partial里面的partial[0]和partial[1]很可能落在同一條緩存行里。線程 A 改partial[0]線程 B 改partial[1]理論上互不相干但在硬件層面A 的寫入會(huì)讓 B 所在的緩存行失效B 不得不重新從內(nèi)存讀。這種“不同變量共享同一條緩存行導(dǎo)致互相拖累”的現(xiàn)象就叫偽共享。隨著線程數(shù)越多偽共享的影響越明顯。我早年用數(shù)組方案時(shí)線程多了反而更慢就是栽在這里。正確做法是每個(gè)線程都用自己棧上的局部變量累加最后一次性合并也就是前面 3.1 那種寫法。如果你確實(shí)要用數(shù)組方案就得給每個(gè)線程“填充”緩存行const int Padding 8; // 64字節(jié) / 8字節(jié) double[] partial new double[threadCount * Padding]; // 線程 t 更新 partial[t * Padding]這能稍微緩解但沒有局部變量干凈。我自己的項(xiàng)目已經(jīng)很少用這個(gè)方案了除非要跨線程傳遞中間結(jié)果。4.3 線程數(shù)Environment.ProcessorCount只是一個(gè)起點(diǎn)很多并行教程會(huì)寫Parallel.For默認(rèn)用Environment.ProcessorCount于是大家誤以為直接照著設(shè)就行。但實(shí)際上超線程讓邏輯線程數(shù)比物理核心多一倍但很多數(shù)值場(chǎng)景中邏輯線程并不能提供兩倍的吞吐同一臺(tái)機(jī)器可能還有其他業(yè)務(wù)在跑一下把所有線程占滿整體系統(tǒng)延遲會(huì)惡化虛擬機(jī)里Environment.ProcessorCount得到的是分配給 VM 的邏輯處理器數(shù)量不是宿主機(jī)核心數(shù)。在最終版本里我試過把MaxDegreeOfParallelism設(shè)為 32、24、16。32 的時(shí)候單算法更快但整個(gè)系統(tǒng)偶發(fā)卡頓24 的時(shí)候單算法略慢 3~5ms但系統(tǒng)更穩(wěn)定。最后我留了余量選了 24。線程數(shù)不是越大越好要在“算法加速”和“系統(tǒng)穩(wěn)定性”之間找平衡。設(shè)置方式如下var options new ParallelOptions { MaxDegreeOfParallelism 24 }; Parallel.ForEach(partitioner, options, range { ... });4.4 疊加 SIMD 向量化并行之外的最后一腳油門并行是“分身”向量化是“一力降十會(huì)”。前者利用多個(gè)核心后者利用單個(gè)核心內(nèi)部的寬度。如果你的計(jì)算內(nèi)核是規(guī)則的多項(xiàng)式、線性運(yùn)算、矩陣乘法可以考慮用System.Numerics里的VectorT。舉一個(gè)簡單的例子比如對(duì)數(shù)組計(jì)算x * x 1的和普通循環(huán)和向量化循環(huán)的差距非常明顯double SumSquaresNaive(double[] data) { double sum 0.0; for (int i 0; i data.Length; i) sum data[i] * data[i] 1.0; return sum; } double SumSquaresVectorized(double[] data) { var vecSum Vectordouble.Zero; int i 0; int vectorSize Vectordouble.Count; int limit data.Length - vectorSize; for (; i limit; i vectorSize) { var vec new Vectordouble(data, i); vecSum vec * vec Vectordouble.One; } double sum Vector.Dot(vecSum, Vectordouble.One); for (; i data.Length; i) sum data[i] * data[i] 1.0; return sum; }向量化的核心是處理器一次能處理多個(gè) double如果你的算法能夠用上等于每個(gè)時(shí)鐘周期多算好幾倍。需要注意它只適用于元素級(jí)計(jì)算像Math.Sin、Math.Cos、Math.Exp這類超越函數(shù).NET 目前沒有內(nèi)置向量化版本如果數(shù)據(jù)量很小向量化的初始化開銷可能不劃算向量化和并行不沖突通常是“每個(gè)并行區(qū)間內(nèi)部再向量化”可以把加速效果疊加。在我的主例子里因?yàn)橛腥呛瘮?shù)SIMD 幫不上忙所以最終 50ms 基本全是從并行里擠出來的。如果你的算法更規(guī)則恭喜你這條路還能再往深走。5. 并行之后的正確性陷阱浮點(diǎn)順序、隨機(jī)數(shù)和生產(chǎn)環(huán)境5.1 并行累加改變了浮點(diǎn)求和順序結(jié)果會(huì)有微小差異很多第一次做并行歸約的人會(huì)發(fā)現(xiàn)一個(gè)讓人慌的問題sum的結(jié)果和串行版本不一樣。比如串行輸出123.45678901并行輸出123.45678899。這不是 bug而是浮點(diǎn)運(yùn)算本身的特性。浮點(diǎn)加法不滿足結(jié)合律不同累加順序會(huì)帶來不同的舍入誤差。線程越多、累加順序變化越大差異就越明顯。金融、電力等對(duì)結(jié)果一致性要求很高的場(chǎng)景可能需要容忍或處理這種差異。兩個(gè)方向可以解決固定合并順序先為線程編號(hào)所有線程處理完后再按編號(hào)順序合并保證每次結(jié)果一致使用 Kahan 補(bǔ)償求和把求和過程中的舍入誤差記錄下來在下一次加法時(shí)補(bǔ)償回去精度明顯提升代價(jià)是計(jì)算量多一點(diǎn)。Kahan 求和實(shí)現(xiàn)不復(fù)雜static double KahanSumParallel(double[] input) { double finalSum 0.0, finalComp 0.0; object gate new object(); Parallel.For( 0, input.Length, () (sum: 0.0, comp: 0.0), (i, state, local) { double y Compute(input[i]) - local.comp; double t local.sum y; local.comp (t - local.sum) - y; local.sum t; return local; }, local { lock (gate) { double y local.sum - finalComp; double t finalSum y; finalComp (t - finalSum) - y; finalSum t; } }); return finalSum; }合并階段也用 Kahan精度會(huì)更好。如果業(yè)務(wù)對(duì)這種細(xì)微差別不敏感普通并行求和足夠。5.2 蒙特卡洛模擬里的共享Random是另一個(gè)坑如果并行數(shù)值算法里用到隨機(jī)數(shù)比如蒙特卡洛積分、粒子濾波、隨機(jī)梯度下降千萬別用同一個(gè)Random實(shí)例。Random不是線程安全的多個(gè)線程同時(shí)調(diào)用會(huì)得到錯(cuò)誤結(jié)果甚至產(chǎn)生大量重復(fù)隨機(jī)序列。有些 CPU 密集型計(jì)算里Random內(nèi)部的共享狀態(tài)也會(huì)變成隱形的鎖競(jìng)爭。正確做法是給每個(gè)線程獨(dú)立的隨機(jī)源var rng new ThreadLocalRandom(() new Random(Guid.NewGuid().GetHashCode()));然后每個(gè)計(jì)算分區(qū)用自己的rng.Value生成隨機(jī)數(shù)。這樣既避免了競(jìng)爭也保證了不同線程的序列互不重復(fù)。需要注意.NET 6 之后有Random.Shared它是線程安全的但如果在高性能并行里大量使用仍然可能因?yàn)閮?nèi)部鎖和競(jìng)爭拖慢速度。我的習(xí)慣是并行場(chǎng)景下永遠(yuǎn)給每線程一個(gè)Random而不是共享一個(gè)。5.3 生產(chǎn)環(huán)境不能裸奔取消、異常和 UI 響應(yīng)數(shù)值計(jì)算經(jīng)常出現(xiàn)在上位機(jī)、實(shí)時(shí)數(shù)據(jù)處理、WinForm 軟件里。很多人的并行代碼一寫就上線結(jié)果遇到兩個(gè)問題用戶點(diǎn)了“停止”但計(jì)算還在后臺(tái)繼續(xù)跑界面失去響應(yīng)某個(gè)線程拋出異常整個(gè)Parallel.For退出但其他線程可能還在執(zhí)行出現(xiàn)難以復(fù)現(xiàn)的奇怪狀態(tài)。Parallel.For支持CancellationToken。把它和Task.Run、進(jìn)度上報(bào)結(jié)合起來才能做出“可取消、不卡界面”的并行計(jì)算var cts new CancellationTokenSource(); var options new ParallelOptions { CancellationToken cts.Token, MaxDegreeOfParallelism 24 }; try { Parallel.ForEach(partitioner, options, (range, loopState) { if (loopState.ShouldExitCurrentIteration) return; double local 0.0; for (int i range.Item1; i range.Item2; i) { if (cts.IsCancellationRequested) { loopState.Stop(); return; } local Compute(input[i]); } lock (gate) { finalSum local; } }); } catch (AggregateException ex) { // 統(tǒng)一處理并行任務(wù)中拋出的異常 }上位機(jī)場(chǎng)景里如果計(jì)算邏輯比較重建議把Parallel.For放到Task.Run里不要直接堵住 UI 線程。并行歸約雖然快但它是 CPU 密集型的一旦跑在主線程上界面照樣卡。6. 可以直接拿去改的完整示例和個(gè)人避坑清單6.1 最終版核心代碼結(jié)合前面所有優(yōu)化點(diǎn)我給出一個(gè)可以直接在這個(gè)例子里跑的最終版。核心思路是固定分區(qū)區(qū)間 每線程局部累加 合并時(shí)最小化鎖競(jìng)爭。using System.Diagnostics; using System.Threading.Tasks; double[] BuildData(int n) { var data new double[n]; var rnd new Random(42); for (int i 0; i n; i) data[i] rnd.NextDouble() * 1000.0 - 500.0; return data; } double Compute(double x) Math.Sin(x) * Math.Cos(x) / (1.0 x * x); double SumParallelBest(double[] input, int? maxDegree null) { int degree maxDegree ?? Environment.ProcessorCount; int rangeSize Math.Max(64, input.Length / (degree * 4)); var partitioner Partitioner.Create(0, input.Length, rangeSize); var options new ParallelOptions { MaxDegreeOfParallelism degree }; double finalSum 0.0; object gate new object(); Parallel.ForEach(partitioner, options, range { double local 0.0; for (int i range.Item1; i range.Item2; i) local Compute(input[i]); lock (gate) { finalSum local; } }); return finalSum; } int n 10_000_000; var data BuildData(n); // 預(yù)熱 for (int i 0; i 3; i) SumParallelBest(data); var sw Stopwatch.StartNew(); double best SumParallelBest(data, 24); sw.Stop(); Console.WriteLine($best parallel: {sw.Elapsed.TotalMilliseconds:F1} ms, result: {best:R});這段代碼沒有做 SIMD也沒有做 Kahan只是一個(gè)通用、穩(wěn)定、容易改的并行歸約骨架。如果你要處理的是別的數(shù)值算法核心思想是通用的把數(shù)據(jù)切成連續(xù)區(qū)間、每個(gè)線程局部累加、最后合并最小化鎖。6.2 我整理的一份六項(xiàng)調(diào)優(yōu)順序每次做 C# 并行加速我都按這個(gè)順序走避免一開始就陷入某個(gè)細(xì)節(jié)先確認(rèn)串行算法本身沒有明顯低效。如果串行復(fù)雜度是 O(n2) 且存在 O(n log n) 的解法并行解決不了復(fù)雜度問題。判斷可并行性。數(shù)據(jù)元素是否獨(dú)立是否存在跨迭代依賴如果有依賴鏈可能需要重新設(shè)計(jì)算法。消除共享可變狀態(tài)。鎖、靜態(tài)變量、共享累加器都是并行性能的敵人優(yōu)先改成局部變量。調(diào)任務(wù)粒度。用Partitioner.Create或調(diào)整Parallel.For的分區(qū)策略找到任務(wù)調(diào)度開銷和負(fù)載均衡之間的甜點(diǎn)?？紤]內(nèi)存布局和緩存。數(shù)組連續(xù)讀取盡量避免偽共享能拆結(jié)構(gòu)體數(shù)組就拆。最后再疊 SIMD / 高性能庫。并行沒做對(duì)之前向量化可能只會(huì)放大錯(cuò)誤。很多人喜歡一上來就調(diào)整線程數(shù)其實(shí)線程數(shù)往往不是第一瓶頸。我見過最快的一次性能提升是只是把共享數(shù)組改成了局部累加其他什么都沒動(dòng)耗時(shí)直接掉了 90%。6.3 最后一點(diǎn)個(gè)人體會(huì)說句實(shí)在話這次優(yōu)化的最大收獲不是那個(gè) 50ms 的數(shù)字而是“并行”這件事本身需要重新建立思維模型。串行代碼的直覺是“一步一步來”并行的直覺是“先拆清楚哪些能同時(shí)做哪些必須在最后匯合”。我在實(shí)際項(xiàng)目里最后沒有把機(jī)器的 32 個(gè)線程全部用完而是留了一部分給別的服務(wù)。因?yàn)槲乙庾R(shí)到一個(gè)實(shí)時(shí)系統(tǒng)不是只有這個(gè)算法在跑CPU 占用率、響應(yīng)時(shí)間、系統(tǒng)穩(wěn)定性都必須一起考慮。數(shù)值算法優(yōu)化不是數(shù)字游戲它最終要服務(wù)于整個(gè)產(chǎn)品的體驗(yàn)。如果你也正在被 C# 數(shù)值算法性能問題折磨建議你先把串行基線測(cè)準(zhǔn)再從“共享狀態(tài)”這個(gè)最大的坑開始動(dòng)刀。希望這篇筆記能幫你把Parallel從“看似合理”變成“真的快”。