你有關(guān)鍵代碼需要優(yōu)化，但是不知道怎么做？例如你的項目中有一段非常慢的瓶頸代碼，可以在下面這個倉庫里開一個 Issue 讓專業(yè)的小彭老師幫你優(yōu)化，并在對話中學(xué)習(xí)優(yōu)化知識。同時，所有的對話和代碼對后來者可見，方便具有相似問題的同學(xué)直接找到答案。

https://github.com/parallel101/simdtutor/issues

我們的口號是：優(yōu)化知識，永遠(yuǎn)不應(yīng)該束之高閣，永遠(yuǎn)不應(yīng)該無法檢索，永遠(yuǎn)不應(yīng)該成為少數(shù)人的專利。

常見痛點

你試圖用小彭老師公開課上教的知識自己用 SIMD 或者 OpenMP 優(yōu)化，但是發(fā)現(xiàn)效果不明顯，可能是使用的姿勢不對。小彭老師課程只介紹了最基本的情況，并不能覆蓋所有領(lǐng)域的多元化需求。

你看了一兩節(jié)課，或是自己看 Intel 官方的指令參考手冊，或是調(diào)用 xsimd 等語法糖包裝庫能夠做出的優(yōu)化，都是你的代碼較為簡單的情況，這時編譯器大多也能自動做出，用不著手動優(yōu)化。

而較為復(fù)雜的情況，你自己也優(yōu)化不來，編譯器也優(yōu)化不來。為了最大化性能，需要結(jié)合具體情況具體分析，手動優(yōu)化。這時你需要的是小彭老師這樣的優(yōu)化專家，結(jié)合他多年的優(yōu)化經(jīng)驗，不失時機地進行一些靈感迸發(fā)，才能優(yōu)化到逼近 CPU 的理論 Flops 上限。

不僅 SIMD 優(yōu)化是如此，并行優(yōu)化往往也會遇到這種情況：你加上了 `#pragma omp parallel for` 但收效甚微。

小彭老師意識到：對于性能優(yōu)化這一特定領(lǐng)域，僅僅提供通用的課程是遠(yuǎn)遠(yuǎn)不夠的。為了能夠了解各位同學(xué)在工作中遇到的實際情況，小彭老師決定推出義務(wù)優(yōu)化服務(wù)，你可以貼出自己的代碼讓專業(yè)的小彭老師幫你分析。畢竟問題是無限的，一節(jié)優(yōu)化課不可能覆蓋所有的問題，不如讓教學(xué)跟著具體的問題走。

優(yōu)秀提問范例

提問的方式有沒有什么參考模板？可以參考這位同學(xué)：https://github.com/parallel101/simdtutor/issues/1，他用 numpy 做圖像的蒙版操作，覺得非常慢。于是他通過 Cython 調(diào)用 C++ 手寫了蒙版操作的代碼，發(fā)現(xiàn)居然比 NumPy 還慢了，非常困惑。最后他試圖用 SIMD 指令優(yōu)化，但他的圖像是 RGB 格式（而不是 RGBA），不知道怎么把 3 通道的顏色數(shù)據(jù)適配到大小固定為 32 字節(jié)的 AVX 寄存器里去。于是請教小彭老師幫他優(yōu)化，最后比原版 NumPy 快 66 倍。

提供關(guān)鍵部位的源碼

光用語言是很難描述問題的，請給出有待優(yōu)化的代碼，這樣小彭老師才能分析為什么慢。
如果你的項目還比較小，可以把項目上傳到 GitHub 上，并創(chuàng)建 Issue 附上項目倉庫鏈接，然后指出哪個文件的哪一段代碼是你急需優(yōu)化的。

如果是比較龐大的項目，直接給小彭老師看全部代碼會讓他找不到要優(yōu)化的點?？梢詥为殑?chuàng)建一個倉庫，放入要優(yōu)化的瓶頸代碼。

具有很多依賴項的項目，會讓小彭老師感到不熟悉，使小彭老師難以上手，所以十分建議先抽出關(guān)鍵代碼，單獨創(chuàng)建一個倉庫方便小彭老師復(fù)現(xiàn)，同時也方便歸檔供后來的同學(xué)查閱。

參考 #1 同學(xué)的做法，他是一個基于 opencv-python 的項目，除了要優(yōu)化的 mask 操作還有很多其他的操作，但是他專門創(chuàng)建了一個倉庫，里面只有要優(yōu)化的代碼和相關(guān)測試框架，沒有多余的依賴項，讓小彭老師能夠直接上手復(fù)現(xiàn)結(jié)果。

性能必須是可復(fù)現(xiàn)的

要求可以測出時間，一般來說會用 chrono 或者 clock 等函數(shù)測時間，如果用了 Google Benchmark 等專業(yè)的測試框架是最好的，例如 #1 同學(xué)采用了 Python 中的 tqdm 框架，這些性能測試框架都會多次循環(huán)以求得更準(zhǔn)確的時間值，避免偶然誤差和預(yù)熱緩存所需的時間。

總之，一定要確保小彭老師能夠復(fù)現(xiàn)你的結(jié)果，以測時間的形式直觀衡量代碼的快慢。并且案例盡可能最小化，讓小彭老師容易把握關(guān)鍵問題。

如果使用了外部文件數(shù)據(jù)（例如 obj 網(wǎng)格模型等），請在 GitHub 倉庫中提供數(shù)據(jù)，如果數(shù)據(jù)文件太大不適合上傳 GitHub，也可以上傳到百度網(wǎng)盤并在 Issue 正文中貼出鏈接。

優(yōu)化服務(wù)僅限 CPU

小彭老師的知識范圍主要限于 CPU 高性能并行優(yōu)化（TBB、OpenMP 等），對于 CUDA 的了解相對較少（僅做了兩節(jié) CUDA 專題課），自用的顯卡型號也較為落后（RTX2080）。并且 CUDA 項目安裝和復(fù)現(xiàn)困難（經(jīng)常卡編譯器版本和顯卡型號），因此原則上不會接受 CUDA 方面的優(yōu)化提問，特別是和 AI 有關(guān)的動不動要配一堆 anaconda 虛擬環(huán)境的所謂“算子優(yōu)化”提問（AI 什么的最討厭了），但是 OpenGL 的 shader 優(yōu)化等問題都可以提。此外，由于小彭老師不具有多臺超算資源，對于多節(jié)點的并行（例如 MPI）也無能為力復(fù)現(xiàn)。

對于實在沒法抽出關(guān)鍵代碼單獨運行的項目，也可提供向日葵（sunlogin）等遠(yuǎn)程控制軟件的途徑，讓小彭老師直接訪問你配置好的環(huán)境里的項目，但這樣會讓其他同學(xué)無法看到問題解決的過程（既然享有小彭老師免費性能優(yōu)化的權(quán)利，也要提供方便其他后來同學(xué)檢索的義務(wù)）。

檢索歷史歸檔

所有優(yōu)化成功的案例都會放入 customers 文件夾留檔，供后來的同學(xué)學(xué)習(xí)參考。小彭老師和同學(xué)的所有討論全部在 Issue 頁面公開，以供檢索，任何有相似情形的后來者都可以直接在 Issue 中找到答案。如果現(xiàn)有的 Issue 都沒有和你類似的情況，請積極提問，填補空白，這樣后來的同學(xué)也能受益（既享有小彭老師免費性能優(yōu)化的權(quán)利，也享有提出“好問題”方便后來同學(xué)檢索的義務(wù)）。

拒絕對非瓶頸代碼的盲目優(yōu)化

例如你有一個創(chuàng)建窗體的函數(shù) createWindow(string title)，你說這里要不要改成 createWindow(string const &title)，更高效？可以是可以，但是這種函數(shù)往往不是瓶頸所在，除非你的程序每秒創(chuàng)建 1000000 個窗口，并且除了創(chuàng)建窗口外什么計算任務(wù)也不做。

更好的例子是，你這個窗體顯示的是物理仿真的結(jié)果，而物理仿真是真正耗時的任務(wù)，因此你應(yīng)該考慮對物理仿真的算法進行優(yōu)化（并行、SIMD 化等），用 CUDA 的話說，就是要抓住 kernel（笑）。

至理名言：如果馬桶堵了，那么你給自己的屁屁再怎么涂甘油潤滑，都是沒用的。屁屁優(yōu)化得再快，照樣卡在馬桶這兒下不去，這時急需優(yōu)化的是馬桶而不是屁屁。如果法線首先應(yīng)該通過 profiler 工具，或者手動 chrono 檢測每一段代碼的運行時間，確定最耗時的那一部分（稱之為熱代碼），進行優(yōu)化。而不是對壓根不是瓶頸的冷代碼優(yōu)化半天，反而優(yōu)化出 BUG 來。

總之，如果你連代碼運行總時間都沒測試過，還是不要心理作用優(yōu)化了，用 C++11 的 chrono 測一下所費時間是最起碼的：

你連這個時間都不知道，怎么知道優(yōu)化前后是提升了還是倒退了？全靠“想當(dāng)然”優(yōu)化？

如果是 C 語言，也可以用 `clock()` 函數(shù)測。當(dāng)然有條件的最好還是用一下 Google Benchmark 等基準(zhǔn)測試框架。

緩存優(yōu)化教程：BV1gu41117bW

自動SIMD化教程：BV12S4y1K721

手動SIMD化教程：BV1cu411a71b

TBB并行教程：BV1gu411m7kN

量化與稀疏教程：BV1P34y117Lp