假設您正在嘗試優化功能并使用一些基準測驗框架（如 Google Benchmark）進行測量。您在原始函式上運行基準測驗 3 次，看到平均掛鐘時間/CPU 時間為 100 毫秒、110 毫秒、90 毫秒。然后在“優化”函式上運行基準測驗 3 次，結果分別為 80 毫秒、95 毫秒、105 毫秒。（我編了這些數字）。您是否認為您的優化是成功的？
我經常遇到的另一個問題是，我會在當天晚些時候去做其他事情并運行基準測驗，并獲得比當天早些時候原始和優化之間的增量更遠的數字（例如，80 毫秒、85 毫秒，原始函式為 75 ms）。
我知道有一些統計方法可以確定改進是否“顯著”。軟體工程師真的在實踐中使用這些形式計算嗎？
我正在尋找優化代碼時要遵循的某種程序。
uj5u.com熱心網友回復：
經驗法則
- 每個系列的最小值（！）=> 90ms vs 80ms
- 估計噪聲 => ~ 10ms
- 悲觀主義 =>它可能沒有變慢。
還不開心？
進行更多測量。（每個約 13 次）
交錯運行。（不要先測量 13x A，然后再測量 13x B。）
理想情況下，您總是隨機化下一步是運行 A 還是 B（科學：隨機試驗），但這可能有點矯枉過正。任何錯誤來源都應該以相同的概率影響每個變體。（比如 CPU 會隨著時間的推移產生熱量，或者在運行 11 之后啟動后臺任務。）
回到步驟 1。
還是不開心？是時候承認你被書呆子狙擊了。如果存在差異，那么差異是如此之小，以至于您甚至無法測量它。選擇更具可讀性的變體并繼續前進。（或者，鎖定你的 CPU 頻率，隔離一個核心只是為了測驗，讓你的系統安靜下來......）
解釋
最小值：許多人（甚至工具）取平均值，但最小值在統計上更穩定。基準測驗在給定硬體上運行的速度有一個下限，但沒有上限，它可以被其他程式減慢。此外，取最小值將自動放棄最初的“熱身”運行。
噪音：應用常識，只需瀏覽數字即可。如果您查看標準偏差，請使其看起來非常懷疑！一個例外值會對它產生如此大的影響，以至于它幾乎變得毫無用處。（通常，這不是正態分布。）
悲觀：你真的很聰明地找到了這個優化，你真的希望優化后的版本更快！如果它看起來更好只是偶然，你會相信它。（你知道的！）所以如果你關心正確，你必須抵制這種趨勢。
免責宣告
這些只是基本準則。最壞情況下的延遲在某些應用程式（流暢的影片或電機控制）中是相關的，但它更難測量。在實踐中優化一些無關緊要的東西很容易（而且很有趣！）。與其想知道你的 1% 的收益是否具有統計意義，不如試試別的方法。測量包括作業系統開銷在內的完整程式。注釋掉代碼，或者運行兩次，只是為了檢查優化它是否值得。
uj5u.com熱心網友回復：
您是否認為您的優化是成功的？
第3 次運行是不夠的，特別是由于巨大的變化以及兩個組的某些時間在合并和排序后混合的事實。
對于像這樣的小時間，應該洗掉第一次運行，至少應該執行幾十次運行。我個人會使用至少數百次運行。
軟體工程師真的在實踐中使用這些形式計算嗎？
只有極少數開發人員進行高級統計分析。當目標優化之前/之后的閑聊很大并且組內的變化很小時，通常不需要做一些非常正式的事情。
例如，如果你的程式比以前快兩倍，最小-最大變化 <5%，那么你可以很肯定地說優化是成功的。話雖如此，有時由于意外的外部因素并非如此（盡管差距如此之大是非常罕見的）。
如果結果不明顯，那么您需要做一些統計基礎知識。您需要計算標準差、均值和中值時間，洗掉第一次運行，交錯運行并使用多次運行（至少幾十次）。由于中心極限定理，時間分布幾乎總是服從正態分布。由于閾值效應（例如快取），它有時是混合分布。如果您在時間上看到一些例外值，您可以繪制該值以輕松查看。
如果存在閾值效應，那么您需要應用高級統計分析，但這很復雜，而且通常不是預期的行為。I 通常表示基準測驗存在偏差，無論如何在結果分析期間都必須考慮錯誤或復雜影響。因此，我強烈建議您在分析這種情況下的結果之前修復/緩解問題。
假設時間服從正態分布，您只需檢查中位數是否接近均值，以及與均值之間的差距相比，標準差是否較小。
一種更正式的方法是計算學生 t 檢驗及其相關的 p 值并檢查 p 值的顯著性（例如 <5%）。如果有更多組，可以使用An Anova 。如果您不確定分布，您可以應用非引數統計檢驗，如 Wilcoxon 和 Kruskal-Wallis 檢驗（請注意，這些檢驗的統計功效不一樣）。在實踐中，進行這樣的正式分析非常耗時，并且與簡單的基本檢查（使用均值和標準差）相比，它通常不是那么有用，除非您的修改影響了很多用戶或者您打算撰寫研究論文。
請記住，使用良好的統計分析并不能防止有偏差的基準。您需要盡量減少可能導致結果有偏差的外部因素。一個常見的偏差是頻率縮放：第一個基準測驗可能比第二個更快，因為渦輪增壓或者它可能更慢，因為處理器可能需要一些時間才能達到高頻率。快取在基準偏差中也起著重要作用。在實踐中還有許多其他因素可能導致偏差，例如編譯器/運行時版本、環境變數、組態檔、作業系統/驅動程式更新、記憶體對齊、作業系統分頁（尤其是在 NUMA 系統上）、硬體（例如熱節流）、軟體錯誤（通過分析奇怪的性能行為來發現錯誤并不少見）等。
因此，使基準測驗盡可能可重現至關重要（通過修復版本和報告環境引數（如果您偏執并且不會對時間產生太大影響，還可以在沙箱中運行基準測驗）。像 Nix/Spack 這樣的軟體有助于打包，像 LXD、Docker 這樣的容器可以幫助創建一個更可重復的環境。
許多大型軟體團隊使用自動基準測驗來檢查性能回歸的存在。工具可以定期為您正確運行和統計分析。一個很好的例子是 Numpy 團隊，他們使用了一個名為 Airspeed Velocity 的包（見結果）。PyPy 團隊還設計了自己的基準測驗工具。Linux 內核也有用于檢查回歸的基準測驗套件（例如 PTS），許多專注于性能的公司都有這樣的自動化基準測驗工具（通常是自制的）。有許多現有的工具可以做到這一點。
有關此主題的更多資訊，請查看 Emery Berger 的出色性能問題演示文稿。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/480050.html
上一篇：具有唯一矩陣轉置問題的2D阻塞