簡介《并行算法的設計與分析》課件圍繞異步并行模型下的排序與選擇問題展開適合計算機專業(yè)學生、研究者以及需要掌握并行計算基礎知識的開發(fā)者學習。課件對應經(jīng)典教材“Parallel Algorithms”第5章重點講解MIMD-CREW模型上的異步枚舉排序算法、MIMD-TC模型上的異步快速排序算法和分布式k-選擇算法涵蓋異步算法基本框架、排序二叉樹的構造思路、算法偽代碼、示例演示與時間分析并對進程同步、數(shù)據(jù)依賴、通信開銷等關鍵設計點做了說明。其中異步枚舉排序通過為每個元素創(chuàng)建獨立進程實現(xiàn)無通信并行異步快速排序則將串行快排遷移到共享內(nèi)存并行環(huán)境分布式k-選擇算法面向數(shù)據(jù)分散場景查找第k小元素。壓縮包為單個pptx演示文稿約236KB按章節(jié)組織便于課堂演示或自學復習。目前已有45人學習瀏覽對希望理解異步并行算法設計思路與經(jīng)典模型應用的讀者具有一定參考價值。1. 并行算法的設計與分析這份.pptx講稿背后的工程鏈路“并行算法的設計與分析”這六個字搭配 .pptx 后綴乍看是一門課的題目實際上對應著一條貫穿多核 CPU、GPU 和集群開發(fā)的工程鏈路。碰到并行優(yōu)化任務沒受過訓練的做法是直接開線程、開進程跑慢了兩眼一黑而按這套方法論走的人會先從任務分解和粒度選擇入手再決定數(shù)據(jù)怎么映射最后用加速比、效率和擴展性三個指標閉環(huán)。這套鏈路能解決三類典型訴求讓單機多核計算真正提速、把算法改造成能在集群上運行的結構、把串行程序整理成可流式處理的流水線。適合兩類讀者正寫著并行程序卻說不清瓶頸在哪的從業(yè)者以及準備把并行計算做成內(nèi)部培訓課、需要大量可復現(xiàn)案例支撐的講師。接下來我按能直接照做的順序拆開講先講任務怎么拆再講性能怎么算然后給三個實用設計模板最后排雷和立驗收習慣。2. 并行算法設計的第一公里任務分解的三種姿勢與粒度邊界很多人寫并行程序失敗不是因為不會用并行庫而是任務分解這一步就沒做對。這一章把“怎么拆任務”講透后面所有性能分析才有意義。2.1 粒度先于并行度拆太細與拆太粗的兩個極端粒度指的是一次派給單個線程或進程的獨立工作量。常犯的錯誤是只關注“開了多少個線程”卻忽略每個線程實際干了多少活。一個典型反例處理一張 4096 乘 4096 的灰度圖有人按像素生成一千多萬個任務每個任務只算幾個像素結果任務創(chuàng)建和調度的開銷比計算本身還貴整體比單線程慢一大截。這就是粒度拆得太細。拆得太粗則是另一個極端。把整個數(shù)據(jù)集切成四塊四個核各拿一塊聽起來很合理但一旦各塊計算量差異明顯比如圖像分割里有的區(qū)域邊緣復雜、有的區(qū)域幾乎是空白快的核十幾秒干完就開始空轉慢的核拖到最后一刻才交活。整體耗時等于最慢那塊的時間加速比很難看。我一般會用一條經(jīng)驗線做初判單個任務的最小執(zhí)行時間至少應該是任務派發(fā)成本的 50 到 100 倍。任務派發(fā)成本包括創(chuàng)建、入隊、同步這些開銷在主流線程庫下通常幾微秒。換句話說如果你預估每次任務的計算量只有幾微秒先把任務合并讓單次計算量提到幾百微秒甚至毫秒級。粗估時可以先按“核數(shù)乘以 4 到 8 倍任務數(shù)”來切跑完看負載均衡情況再調。負載看什么看每個線程的實際耗時分布而不是看 CPU 占用率。2.2 域分解、功能分解與流水線三種拆法的適用邊界任務分解大體有三條路域分解、功能分解、流水線。域分解是最常用的一種把數(shù)據(jù)切成塊每個處理單元負責一塊塊與塊之間只在邊界處交換必要的數(shù)據(jù)。網(wǎng)格迭代、圖像濾波、矩陣乘法都適合這種拆法因為數(shù)據(jù)局部性好通信模式固定分析起來也容易。功能分解則是按“處理階段”來切而不是按數(shù)據(jù)來切。典型場景是音視頻處理里的采集、變換、編碼、寫入四個階段每個階段由不同處理單元負責數(shù)據(jù)從上一個階段流向下一個階段。它的優(yōu)點是各階段可以獨立開發(fā)和優(yōu)化缺點是階段之間有依賴整體吞吐受最慢階段限制。流水線可以看作是功能分解的時序化形態(tài)把各階段重疊起來執(zhí)行就像工廠生產(chǎn)線。流水線的好處是天然支持流式數(shù)據(jù)壞處是每條流水線的吞吐上限由最慢環(huán)節(jié)決定而且階段數(shù)越多調度和緩沖的復雜度越高。怎么選先問數(shù)據(jù)能不能切。能切優(yōu)先域分解這是最簡單、最容易分析性能的路徑。數(shù)據(jù)切不了再看處理過程能不能按階段分開。階段之間有明確的單向數(shù)據(jù)流就考慮功能分解或流水線。下表是三者的對照分解策略切分對象通信特點典型場景域分解數(shù)據(jù)塊塊邊界少量鄰居通信網(wǎng)格迭代、圖像處理、矩陣運算功能分解處理階段階段間單向全量傳遞音視頻處理、ETL 流程流水線階段 時序順流傳遞可重疊執(zhí)行流式計算、并行編譯2.3 數(shù)據(jù)映射共享內(nèi)存和分布式內(nèi)存的分配策略差異任務拆完之后數(shù)據(jù)放在哪、由誰訪問這一步?jīng)Q定通信開銷。共享內(nèi)存模型下所有線程看到同一份地址空間數(shù)據(jù)映射的核心不是“能不能訪問”而是“訪存是否局部”。常見問題是 NUMA 架構下線程訪問了遠端內(nèi)存延遲比本地內(nèi)存高一個數(shù)量級。常見做法是讓每個線程優(yōu)先處理自己內(nèi)存附近的數(shù)據(jù)也就是綁核之后再做數(shù)據(jù)分區(qū)而不是讓線程隨機訪問整個大數(shù)組。分布式內(nèi)存模型下數(shù)據(jù)映射的核心變成“數(shù)據(jù)在哪一側就要付出多少通信代價”。映射策略主要三種復制、分區(qū)、按需拉取。復制適合只讀數(shù)據(jù)每個節(jié)點一份完全消除讀通信分區(qū)適合可寫數(shù)據(jù)每份數(shù)據(jù)只有一個歸屬節(jié)點按需拉取適合訪問模式稀疏的場景但要控制拉取頻率否則容易把網(wǎng)絡打滿。我在動手前通常會做四個小判斷這份數(shù)據(jù)誰在寫、誰在讀、寫讀比例大概多少、跨節(jié)點訪問頻率高不高。寫多讀少的數(shù)據(jù)必須分區(qū)讀多寫少的數(shù)據(jù)優(yōu)先復制讀寫都頻繁的數(shù)據(jù)就要重新考慮任務劃分是否合理。一句話建立心智模型共享內(nèi)存下地址決定熱區(qū)分布式下通信決定邊界。數(shù)據(jù)映射方案在寫代碼之前定下來比寫完再改省力得多。3. 性能分析不能只算加速比把指標吃透才能定位瓶頸設計做完下一步是回答“它到底快了多少、值不值得”。只看單次耗時是遠遠不夠的加速比、效率、擴展性三個指標配合起來才能定位瓶頸在哪一層。3.1 加速比與效率固定問題規(guī)模才算得準加速比的定義是 S(p)T(1)/T(p)其中 T(1) 是單處理單元的最優(yōu)串行耗時T(p) 是 p 個處理單元并行后的耗時。效率是 ES(p)/p它衡量的是每個處理單元的利用率。四核跑出三倍加速比效率是 75%十六核跑出十二倍效率是 75%不對是 75% 的加速比算一下十二除以十六等于百分之七十五效率仍然不錯但十六核只跑出十二倍說明每增加一個核帶來的收益在遞減。這里有個非常關鍵的細節(jié)T(1) 必須用可比較的最優(yōu)串行實現(xiàn)而不是隨便寫一版循環(huán)就當基線。有些人為了顯得并行效果好故意用一個沒開編譯優(yōu)化的串行版本當對照這屬于自欺欺人。我一般會先把串行版本用編譯器高優(yōu)化等級跑一遍確認沒有明顯可優(yōu)化的垃圾代碼再把它作為 T(1)。實際測量時還會遇到一個常見現(xiàn)象加速比并不是隨著核數(shù)單調上升而是先升后降。這是因為核數(shù)增加后通信和同步開銷的增長超過了計算收益。以固定問題規(guī)模為例常見趨勢是2 核接近 1.9 倍4 核約 3.7 倍8 核約 6.3 倍16 核可能只有 7.5 倍左右。后面的效率跌得很快說明瓶頸已經(jīng)從“算不過來”變成“溝通不過來”。3.2 Amdahl 與 Gustafson兩套公式各管一個場景性能分析繞不開 Amdahl 定律和 Gustafson 定律但很多人把兩套公式用錯了場景。Amdahl 定律說的是如果程序里有 s 比例的部分無法并行那么無論加多少核加速比上限是 1/s。公式是 S1/(s(1-s)/p)。舉個例子串行部分占 5%16 核理論的加速比上限約 9.1 倍64 核也到不了 14 倍。這個公式的適用前提是問題規(guī)模固定不變所以我們想要的是“同樣的問題跑得更快”。Gustafson 定律則適用于另一個場景時間預算固定問題規(guī)模可以隨核數(shù)擴大。它的表達式是 S≈sp(1-s)在這個假設下串行占比 5% 時16 核可以得到約 15.25 倍的加速比看起來比 Amdahl 樂觀得多。這不是矛盾而是前提不同一個是固定工作量一個是固定時間、允許“加核的同時加規(guī)模”。判斷你的場景該用哪套就問一個問題業(yè)務允許結果規(guī)模變化嗎如果算法輸出必須是指定尺寸、指定精度的結果按 Amdahl 定律做預算先集中精力壓縮串行段如果業(yè)務是“單位時間內(nèi)產(chǎn)出越多越好”比如數(shù)值模擬里網(wǎng)格分辨率可以提高、搜索場景里候選集可以擴大那就參照 Gustafson 定律來設計擴展路徑。定律適用前提核心變量加速比上限Amdahl問題規(guī)模固定串行占比 s極限 1/sGustafson時間固定、規(guī)模隨核數(shù)擴展并行占比接近線性增長3.3 強擴展與弱擴展用四條曲線判斷性能上限擴展性分析可以看作是把上述兩套定律落到實測里。強擴展測試固定問題規(guī)模只增加處理單元數(shù)觀察加速比是否接近線性弱擴展測試固定每個處理單元的工作量總規(guī)模隨處理單元數(shù)增大觀察效率是否維持穩(wěn)定。這兩條曲線是判斷算法設計是否健康的核心依據(jù)。具體操作分三步。第一步選定一個中等規(guī)模數(shù)據(jù)集能把單線程跑完但時間不要太短比如 20 到 60 秒太短了測量噪聲影響太大。第二步分別用 1、2、4、8、16 個處理單元跑同一份數(shù)據(jù)每個配置至少跑 5 次取中位數(shù)避免偶爾的系統(tǒng)抖動污染結果。第三步換弱擴展1 個核處理一定量數(shù)據(jù)2 個核就處理兩倍4 個核處理四倍同樣記錄耗時和效率。for p in 1 2 4 8 16; do ./bench --threads $p --size 4096 --repeats 5 done上面的腳本只是一個最小示例。size 固定時得到的是強擴展數(shù)據(jù)如果想讓 size 隨線程數(shù)線性增長就把 size 改成 p 的倍數(shù)比如--size $((p * 1024))這就是弱擴展數(shù)據(jù)。repeats 取中位數(shù)而不是平均值是因為并行程序對系統(tǒng)噪聲很敏感偶爾一次調度抖動會把平均值拉高中位數(shù)更能代表典型表現(xiàn)。讀曲線也有經(jīng)驗可循。強擴展的加速比曲線從接近線性開始逐漸掉頭掉頭最明顯的位置往往就是通信或同步開銷開始壓過計算收益的臨界點這個臨界點對應的核數(shù)就是你當前實現(xiàn)的實際適用范圍。弱擴展的效率曲線如果保持平穩(wěn)說明數(shù)據(jù)劃分方式經(jīng)得住規(guī)模增長如果效率隨核數(shù)明顯下滑優(yōu)先懷疑跨節(jié)點通信或者共享數(shù)據(jù)的爭用。4. 三個高頻可復現(xiàn)的設計模板分治、規(guī)約、前綴和設計方法不能只停留在概念上需要落到具體模板。這一章給出三個高頻使用的并行模式前兩個在工程里幾乎天天遇到第三個是檢驗“設計與分析”基本功的最佳案例。4.1 分治模板遞歸劃分的可用與濫用邊界分治模板適合“子問題相互獨立”的任務數(shù)組求和、快速排序、分塊矩陣乘都是典型場景。核心思路是把大問題遞歸拆成小問題各處理單元并行解決小問題再合并結果。它有一個很明確的適用邊界子問題不能有強依賴。如果后一階段必須等前一階段全部完成才能開始就不要硬套分治改走規(guī)約或流水線。下面是一個簡化的分治求和偽碼展示了設計思路def parallel_sum(data, cutoff): if len(data) cutoff: return sum(data) # 小段走串行減少調度開銷 mid len(data) // 2 left task_pool.submit(parallel_sum, data[:mid], cutoff) right task_pool.submit(parallel_sum, data[mid:], cutoff) return left.get() right.get()cutoff 是串行截止值默認可以取 512 到 4096 個元素。取值太小任務數(shù)量會膨脹調度與同步開銷覆蓋掉并行收益取值太大并行度不足多核閑著。一般先從 4096 開始逐步減半對比耗時找到性能拐點。任務總數(shù)控制在核數(shù)的 4 到 8 倍通常比較合適任務太多調度器反而成了瓶頸。另一個要注意的點是如果各子任務的計算量差異很大靜態(tài)劃分會嚴重負載不均這時要改用動態(tài)調度比如工作竊取策略。實現(xiàn)上可以用線程池配合帶有竊取能力的任務隊列而不是自己寫遞歸線程。4.2 樹形規(guī)約把串行瓶頸換成 log 深度規(guī)約問題是指把一組數(shù)據(jù)通過某個滿足結合律的運算合并成一個結果比如求和、求最大值、內(nèi)積。串行實現(xiàn)很直接循環(huán)累加即可但并行化之后你會發(fā)現(xiàn)最后一輪的合并結果只有一個處理單元能拿到其他單元都在空等。樹形規(guī)約就是為了解決這個“扇形收斂”的問題。以分布式內(nèi)存為例每個進程先算本地部分和然后按步長成對合并每輪通信之后活躍進程數(shù)減半。偽碼如下value local_partial_sum stride 1 while stride size: if rank % (2 * stride) 0: received recv(rank stride) value received elif rank % (2 * stride) stride: send(rank - stride, value) break # 發(fā)送完即退出本輪 stride * 2這里的 stride 是合并步長每輪翻倍所以通信輪次是 log2(p) 而不是 p。參數(shù)要注意兩點前半段進程在接收后半段進程在發(fā)送后直接退出活躍進程數(shù)逐輪減半這本身是一種負載不均衡只是它換來的是通信次數(shù)的大幅減少如果做的是全局規(guī)約也就是所有進程都要拿到最終結果那么還需要一輪廣播或者改用蝶形算法。實際工程里能用現(xiàn)成庫的 Allreduce 就用現(xiàn)成的大多數(shù)成熟實現(xiàn)會按消息大小自動選擇樹形還是蝶形比自己手寫的版本更穩(wěn)。樹形規(guī)約的意義在于讓你理解為什么通信次數(shù)可以從線性降到對數(shù)級。4.3 并行前綴和檢驗設計與分析是否上手的試金石前綴和也叫掃描要求對輸入數(shù)組的每個位置輸出它之前所有元素的和?？雌饋硖烊淮幸驗榈?i 個輸出依賴前 i-1 個輸出但并行算法可以用兩階段思路繞過這個依賴鏈。常見做法是塊內(nèi)掃描加全局偏移修正# 階段 1每個處理單元對本地塊做排他前綴和 local_prefix exclusive_scan(local_chunk) # 階段 2計算每個塊的總和對塊和再做一次排他前綴和 block_sum sum(local_chunk) block_offset exclusive_scan(all_block_sum) # 階段 3本地前綴和加上全局偏移得到正確答案 result local_prefix block_offset這個過程能跑通依賴的是前綴和運算的結合律。第一階段是純并行每塊獨立計算第二階段把塊和匯總數(shù)據(jù)量已經(jīng)縮小到塊數(shù)級別第三階段再次純并行把偏移量廣播回各塊并相加?？倳r間大約是 O(n/p log p)n 是數(shù)據(jù)總量p 是處理單元數(shù)。前半部分是本地計算開銷后半部分是全局通信開銷。為什么說這是試金石因為它同時訓練了“設計”和“分析”兩件事設計體現(xiàn)在三個階段的劃分和映射上分析體現(xiàn)在你能否準確地說出時間都花在哪一段。如果你能給同事講明白這個案例說明你對并行算法的任務劃分、通信模式和復雜度分析都有感覺了。從做講稿的角度看這也是最容易讓聽眾建立信心的案例因為它從“不可能并行”到“三段式解決”的轉折足夠清晰。5. 并行算法踩坑排查五個高頻問題的現(xiàn)象、原因與對策并行程序跑不出預期性能一般不是算法思想錯了而是落在幾個固定坑里。這一章我把高頻問題按“現(xiàn)象到對策”整理出來可以直接當排查手冊用。5.1 負載不均衡核全在忙總時間卻紋絲不動現(xiàn)象任務管理器里所有核心的占用率都不低甚至接近 100%但加速比就是上不去有時 8 核跑出來只有 1.5 倍。原因任務被靜態(tài)等量劃分但各任務的實際計算量差異很大整體耗時被最慢的那個任務拖死。比如網(wǎng)格計算里某塊區(qū)域的迭代次數(shù)遠高于其他區(qū)域或者圖像處理中不同分塊的邊緣復雜程度差別很大。解決把靜態(tài)劃分改成動態(tài)調度。共享內(nèi)存場景下用帶任務竊取的線程池誰先干完誰去拿新任務分布式場景下可以把任務切得更小讓工作節(jié)點按需領取而不是一次性把大塊分完。另外日志里為每個任務記錄開始和結束時間做完一輪后看各任務耗時的分布如果最大和最小差了 3 倍以上負載不均衡基本可以坐實。5.2 緩存?zhèn)喂蚕斫Y果正確速度卻比單線程還慢現(xiàn)象多線程版本的輸出完全正確但耗時比單線程還長而且性能工具顯示緩存一致性相關的等待很高。原因多個線程頻繁寫入不同的變量但這些變量恰好落在同一條緩存行上比如 64 字節(jié)的緩存行里有兩個相鄰數(shù)組元素分別被兩個線程更新。每次寫入都會讓整條緩存行在其他核心失效于是兩個線程互相拖累。解決把不相干的數(shù)據(jù)用填充的方式隔開讓它們落在不同的緩存行上。也可以讓每個線程先寫自己的私有緩沖區(qū)全部算完之后再一次性合并到共享數(shù)組。這個坑最容易出現(xiàn)在“按索引并行處理數(shù)組”的場景里排查時優(yōu)先檢查同一數(shù)組相鄰下標是否被不同線程并發(fā)更新。5.3 鎖爭用與死鎖共享數(shù)據(jù)結構讓你“部分快、整體崩”現(xiàn)象加鎖之后并行效率斷崖式下跌系統(tǒng)態(tài) CPU 占用明顯升高更嚴重的情況是程序掛起幾秒后無響應。原因前者通常是全局鎖把關鍵路徑串行化了比如所有線程都要更新同一個計數(shù)器后者是死鎖兩個線程互相持有對方需要的鎖誰都不肯釋放。解決先分析共享數(shù)據(jù)能否分區(qū)。計數(shù)器可以改成每個線程一個本地計數(shù)最后匯總鏈表可以用細粒度鎖或者無鎖隊列。死鎖的處理我習慣按四個條件倒查互斥、持有并等待、不可搶占、循環(huán)等待。代碼里只要破壞其中任意一個條件就不會死鎖最常用的辦法是規(guī)定全局一致的加鎖順序所有線程都按相同順序獲取多個鎖。排查死鎖時先看線程棧里每個線程在等哪把鎖再畫依賴環(huán)環(huán)的起點就是問題所在。5.4 通信放大頻繁小消息比數(shù)據(jù)量大更致命現(xiàn)象計算部分很快但整個程序運行時間依然很長統(tǒng)計下來通信占了八成以上。原因消息次數(shù)太多每次消息體又很小。比如分布式場景里每個迭代向其他節(jié)點發(fā)送一個幾十字節(jié)的狀態(tài)信息一萬次迭代就是上萬次網(wǎng)絡往返延遲完全吃掉了計算收益。通信成本由兩個因素決定消息次數(shù)和消息體積而在多數(shù)網(wǎng)絡環(huán)境下次數(shù)比體積更致命。解決把頻繁的小消息合并成批量緩沖區(qū)攢夠一批再發(fā)送。另一種思路是改變計算結構讓數(shù)據(jù)盡量在本地處理只在邊界處同步。判斷通信是否健康可以在日志里統(tǒng)計兩個數(shù)每秒消息次數(shù)和平均消息字節(jié)數(shù)。如果次數(shù)在十萬級而平均字節(jié)數(shù)只有幾十優(yōu)先做合并。5.5 超線性加速比是驚喜但先別高興現(xiàn)象16 核跑出了 18 倍的加速比理論上不可能但它確實發(fā)生了。原因并行版本把大數(shù)組拆成了小塊每個核處理的小塊恰好完全放進了處理器緩存而串行版本的數(shù)據(jù)會不斷在各級緩存和內(nèi)存之間搬運相當于并行版本白賺了一筆“內(nèi)存帶寬紅利”。算法本身并沒有變得更快只是數(shù)據(jù)局部性變好了。解決先不要把這個結果寫進匯報回去做兩個驗證。第一確認串行基線版本是不是同一份代碼在相同編譯優(yōu)化等級下的最優(yōu)實現(xiàn)第二把問題規(guī)模擴大一倍再測如果超線性消失說明確實是緩存效果而非算法突破。這個坑看似是好事但它會誤導后續(xù)的優(yōu)化方向。下表匯總了這五個問題的快速對照高頻問題典型現(xiàn)象根本原因優(yōu)先檢查手段負載不均衡核占用高但加速比低任務計算量差異大統(tǒng)計各任務耗時分布緩存?zhèn)喂蚕碚_但慢單線程反而快多線程爭用同一條緩存行檢查共享數(shù)組相鄰下標訪問鎖爭用與死鎖加鎖后效率驟降或掛起全局鎖串行化、鎖依賴環(huán)查看線程棧等待關系通信放大計算快但總耗時長消息次數(shù)過多、消息體過小統(tǒng)計消息次數(shù)與平均字節(jié)數(shù)超線性加速加速比大于核數(shù)緩存與內(nèi)存帶寬紅利擴大規(guī)模復測確認6. 把分析能力變成驗收習慣三個每次迭代必做的自查到這一步設計與分析的框架已經(jīng)完整最后要解決的是“怎么保證自己每次改動都在進步”的問題。我的做法是固化三個自查動作每個迭代都過一遍。第一個自查先有串行基線再談并行加速。固定數(shù)據(jù)集、固定機器、固定編譯優(yōu)化等級把最優(yōu)串行耗時記錄成基準。并行實現(xiàn)沒跑過這個基準就是失敗不要用“理論上應該有加速”安慰自己。這里要小心的是編譯器開啟優(yōu)化后某些串行代碼會被自動向量化這時候并行版本的優(yōu)勢會被縮小但這才是真實的對比基線。第二個自查一次只改一個變量。線程數(shù)、任務分塊大小、調度方式、數(shù)據(jù)布局這些參數(shù)每次只動一個然后記錄三個數(shù)字總耗時、同步或通信耗時占比、各線程利用率。改完兩個參數(shù)再跑如果性能變了你無法判斷是哪個起了作用等于白跑。記錄下來的數(shù)據(jù)按日期和參數(shù)存好后續(xù)排查問題時能快速回溯。第三個自查強擴展和弱擴展兩條曲線都留檔。固定問題規(guī)模跑強擴展固定每核負載跑弱擴展每條曲線至少五個數(shù)據(jù)點。每次代碼改動后重跑一輪把曲線圖和原始耗時數(shù)據(jù)存成文件。不要靠記憶也不要只留最終數(shù)字否則換了測試機器、換了編譯器之后你會發(fā)現(xiàn)之前的所有判斷都沒法復現(xiàn)。我在給內(nèi)部一個圖像處理 Demo 做并行化時早期只拍了 4 核和 8 核兩組耗時加速比看著還行換到 32 核機器上直接翻車返工點恰好就在數(shù)據(jù)劃分策略上。那之后我才立了這三條自查。做并行優(yōu)化前也先算一筆投入產(chǎn)出賬優(yōu)化本身的開發(fā)時間加上反復調試的時間值不值得做。只要業(yè)務是計算密集、數(shù)據(jù)可分區(qū)、需要反復驗證的場景這套前期投入很快就能回本。希望幫到你。本文還有配套的精品資源點擊獲取