如何在 GO 中寫出準(zhǔn)確的基準(zhǔn)測試
一般來說，我們不應(yīng)該對性能進(jìn)行猜測。在編寫優(yōu)化時(shí)，會(huì)有許多因素可能起作用，即使我們對結(jié)果有很強(qiáng)的看法，測試它們很少是一個(gè)壞主意。然而，編寫基準(zhǔn)測試并不簡單。很容易編寫不準(zhǔn)確的基準(zhǔn)測試，并且基于這些測試得出錯(cuò)誤的假設(shè)。這篇文章的目標(biāo)是探討導(dǎo)致不準(zhǔn)確的四個(gè)常見和具體陷阱：
- 不重置或暫停計(jì)時(shí)器
- 對微基準(zhǔn)測試做出錯(cuò)誤假設(shè)
- 不注意編譯器優(yōu)化
- 被觀察效應(yīng)所誤導(dǎo)
通用概念
在討論這些陷阱之前，讓我們簡要回顧一下 Go 語言中基準(zhǔn)測試的工作原理。基準(zhǔn)測試的框架大致如下：
func BenchmarkFoo(b *testing.B) {
for i := 0; i < b.N; i++ {
foo()
}
}函數(shù)名以Benchmark前綴開頭。被測試的函數(shù)（foo）在for循環(huán)內(nèi)被調(diào)用。b.N代表著可變數(shù)量的迭代次數(shù)。在運(yùn)行基準(zhǔn)測試時(shí)，Go 會(huì)嘗試使其匹配所請求的基準(zhǔn)測試時(shí)間。基準(zhǔn)測試時(shí)間默認(rèn)設(shè)置為1秒，可以使用-benchtime標(biāo)志進(jìn)行更改。b.N從1開始；如果基準(zhǔn)測試在1秒內(nèi)完成，b.N會(huì)增加，然后再次運(yùn)行基準(zhǔn)測試，直到b.N大致匹配benchtime為止。
$ go test -bench=.
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkFoo-4 73 16511228 ns/op在這里，基準(zhǔn)測試大約花費(fèi)了1秒鐘，foo被執(zhí)行了73次，平均執(zhí)行時(shí)間為16,511,228納秒。我們可以使用-benchtime來更改基準(zhǔn)測試時(shí)間：
$ go test -bench=. -benchtime=2s
BenchmarkFoo-4 150 15832169 ns/opfoo 的執(zhí)行次數(shù)大約是上一個(gè)基準(zhǔn)測試的兩倍。
接下來，讓我們看一些常見的陷阱。
不重置或暫停計(jì)時(shí)器
在某些情況下，我們需要在基準(zhǔn)測試循環(huán)之前執(zhí)行一些操作。這些操作可能需要相當(dāng)長的時(shí)間（例如，生成一個(gè)大型數(shù)據(jù)切片），可能會(huì)對基準(zhǔn)測試結(jié)果產(chǎn)生顯著影響：
func BenchmarkFoo(b *testing.B) {
expensiveSetup()
for i := 0; i < b.N; i++ {
functionUnderTest()
}
}在這種情況下，我們可以在進(jìn)入循環(huán)之前使用ResetTimer方法：
func BenchmarkFoo(b *testing.B) {
expensiveSetup()
b.ResetTimer() // Reset the benchmark timer
for i := 0; i < b.N; i++ {
functionUnderTest()
}
}調(diào)用ResetTimer會(huì)將自測試開始以來的經(jīng)過時(shí)間和內(nèi)存分配計(jì)數(shù)器歸零。這樣，一個(gè)昂貴的設(shè)置步驟可以從測試結(jié)果中排除。
如果我們不僅需要在測試中執(zhí)行一次昂貴的設(shè)置步驟，而是需要在每個(gè)循環(huán)迭代中都執(zhí)行呢？
func BenchmarkFoo(b *testing.B) {
for i := 0; i < b.N; i++ {
expensiveSetup()
functionUnderTest()
}
}我們不能重置計(jì)時(shí)器，因?yàn)槟菢訒?huì)在每次循環(huán)迭代期間執(zhí)行。但是我們可以停止和恢復(fù)基準(zhǔn)測試計(jì)時(shí)器，將調(diào)用expensiveSetup包裹起來：
func BenchmarkFoo(b *testing.B) {
for i := 0; i < b.N; i++ {
b.StopTimer() // Pause the benchmark timer
expensiveSetup()
b.StartTimer() // Resume the benchmark timer
functionUnderTest()
}
}在這里，我們暫停基準(zhǔn)測試計(jì)時(shí)器來執(zhí)行昂貴的設(shè)置步驟，然后恢復(fù)計(jì)時(shí)器。
注意： 關(guān)于這種方法有一個(gè)需要記住的地方：如果被測試的函數(shù)執(zhí)行速度遠(yuǎn)遠(yuǎn)比設(shè)置函數(shù)要快，那么基準(zhǔn)測試可能會(huì)花費(fèi)太長時(shí)間才能完成。原因是它需要比 benchtime 更長的時(shí)間才能完成。基準(zhǔn)測試時(shí)間的計(jì)算完全基于 functionUnderTest 的執(zhí)行時(shí)間。所以，如果在每個(gè)循環(huán)迭代中等待了相當(dāng)長的時(shí)間，基準(zhǔn)測試就會(huì)比1秒要慢得多。如果我們想保持基準(zhǔn)測試，一種可能的緩解方法是減少 benchtime 。
我們必須確保使用計(jì)時(shí)器方法來保持基準(zhǔn)測試的準(zhǔn)確性。
對微基準(zhǔn)測試做出錯(cuò)誤假設(shè)
微基準(zhǔn)測試測量的是微小的計(jì)算單元，很容易對它做出錯(cuò)誤的假設(shè)。比如說，我們不確定是應(yīng)該使用atomic.StoreInt32還是atomic.StoreInt64（假設(shè)處理的值始終適合32位）。我們想編寫一個(gè)基準(zhǔn)測試來比較這兩個(gè)函數(shù)：
func BenchmarkAtomicStoreInt32(b *testing.B) {
var v int32
for i := 0; i < b.N; i++ {
atomic.StoreInt32(&v, 1)
}
}
func BenchmarkAtomicStoreInt64(b *testing.B) {
var v int64
for i := 0; i < b.N; i++ {
atomic.StoreInt64(&v, 1)
}
}如果我們運(yùn)行這個(gè)基準(zhǔn)測試，以下是一些示例輸出：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkAtomicStoreInt32
BenchmarkAtomicStoreInt32-4 197107742 5.682 ns/op
BenchmarkAtomicStoreInt64
BenchmarkAtomicStoreInt64-4 213917528 5.134 ns/op我們很容易認(rèn)為這個(gè)基準(zhǔn)測試并且決定使用atomic.StoreInt64，因?yàn)樗雌饋砀臁，F(xiàn)在，為了進(jìn)行一次公平的基準(zhǔn)測試，我們改變順序，先測試atomic.StoreInt64，然后測試atomic.StoreInt32。以下是一些示例輸出：
BenchmarkAtomicStoreInt64
BenchmarkAtomicStoreInt64-4 224900722 5.434 ns/op
BenchmarkAtomicStoreInt32
BenchmarkAtomicStoreInt32-4 230253900 5.159 ns/op這次，atomic.StoreInt32有更好的結(jié)果。發(fā)生了什么事？
在微基準(zhǔn)測試中，許多因素都會(huì)影響結(jié)果，比如在運(yùn)行基準(zhǔn)測試時(shí)的機(jī)器活動(dòng)、電源管理、熱管理和一系列指令的更好的緩存對齊。我們必須記住，許多因素，甚至超出我們 Go 項(xiàng)目范圍的因素，都可能會(huì)影響結(jié)果。
注意： 我們應(yīng)該確保運(yùn)行基準(zhǔn)測試的機(jī)器處于空閑狀態(tài)。但是，外部進(jìn)程可能在后臺運(yùn)行，這可能會(huì)影響基準(zhǔn)測試結(jié)果。因此，像 perflock 這樣的工具可以限制基準(zhǔn)測試可以消耗的CPU。例如，我們可以使用總可用CPU的70%來運(yùn)行基準(zhǔn)測試，將30%分配給操作系統(tǒng)和其他進(jìn)程，減少機(jī)器活動(dòng)因素對結(jié)果的影響。
一個(gè)選擇是使用-benchtime選項(xiàng)增加基準(zhǔn)測試時(shí)間。類似于概率論中的大數(shù)定律，如果我們運(yùn)行大量次數(shù)的基準(zhǔn)測試，它應(yīng)該趨向于接近其期望值（假設(shè)我們忽略了指令緩存等機(jī)制的好處）。
另一個(gè)選擇是在經(jīng)典基準(zhǔn)測試工具之上使用外部工具。例如，benchstat工具是golang.org/x代碼庫的一部分，它允許我們計(jì)算和比較有關(guān)基準(zhǔn)測試執(zhí)行的統(tǒng)計(jì)數(shù)據(jù)。
讓我們使用-count選項(xiàng)運(yùn)行基準(zhǔn)測試10次，并將輸出重定向到一個(gè)特定的文件：
$ go test -bench=. -count=10 | tee stats.txt
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkAtomicStoreInt32-4 234935682 5.124 ns/op
BenchmarkAtomicStoreInt32-4 235307204 5.112 ns/op
// ...
BenchmarkAtomicStoreInt64-4 235548591 5.107 ns/op
BenchmarkAtomicStoreInt64-4 235210292 5.090 ns/op
// ...然后我們可以在這個(gè)文件上運(yùn)行benchstat：
$ benchstat stats.txt
name time/op
AtomicStoreInt32-4 5.10ns ± 1%
AtomicStoreInt64-4 5.10ns ± 1%結(jié)果是一樣的：兩個(gè)函數(shù)的平均完成時(shí)間都是5.10納秒。我們還可以看到給定基準(zhǔn)測試執(zhí)行間的百分比變化：±1%。這個(gè)指標(biāo)告訴我們，兩個(gè)基準(zhǔn)測試都是穩(wěn)定的，這讓我們對計(jì)算出的平均結(jié)果更有信心。因此，我們不能得出atomic.StoreInt32比atomic.StoreInt64快或慢的結(jié)論，而是可以得出對于我們測試的用途（在特定的Go版本和特定的機(jī)器上），它們的執(zhí)行時(shí)間是相似的。
總的來說，我們在進(jìn)行微基準(zhǔn)測試時(shí)應(yīng)該保持謹(jǐn)慎。許多因素都可以對結(jié)果產(chǎn)生重大影響，并潛在地導(dǎo)致錯(cuò)誤的假設(shè)。增加基準(zhǔn)測試時(shí)間或重復(fù)基準(zhǔn)測試的執(zhí)行，并使用諸如benchstat之類的工具計(jì)算統(tǒng)計(jì)數(shù)據(jù)，可以是限制外部因素并獲得更準(zhǔn)確結(jié)果的有效方法，從而得出更好的結(jié)論。
我們還應(yīng)該注意，如果另一個(gè)系統(tǒng)最終運(yùn)行該應(yīng)用程序，要小心使用在特定機(jī)器上執(zhí)行的微基準(zhǔn)測試的結(jié)果。生產(chǎn)系統(tǒng)的行為可能與我們運(yùn)行微基準(zhǔn)測試的系統(tǒng)大不相同。
不注意編譯器優(yōu)化
與編寫基準(zhǔn)測試相關(guān)的另一個(gè)常見錯(cuò)誤是被編譯器優(yōu)化所欺騙，這也可能導(dǎo)致錯(cuò)誤的基準(zhǔn)測試假設(shè)。在這一節(jié)中，我們將看看Go語言的14813號問題（https://github.com/golang/go/issues/14813，也被Go項(xiàng)目成員Dave Cheney討論過），涉及到一個(gè)人口統(tǒng)計(jì)函數(shù)（一個(gè)計(jì)算設(shè)置為1的位數(shù)的函數(shù)）：
const m1 = 0x5555555555555555
const m2 = 0x3333333333333333
const m4 = 0x0f0f0f0f0f0f0f0f
const h01 = 0x0101010101010101
func popcnt(x uint64) uint64 {
x -= (x >> 1) & m1
x = (x & m2) + ((x >> 2) & m2)
x = (x + (x >> 4)) & m4
return (x * h01) >> 56
}這個(gè)函數(shù)接受一個(gè)uint64并返回一個(gè)uint64。為了對這個(gè)函數(shù)進(jìn)行基準(zhǔn)測試，我們可以編寫以下內(nèi)容：
func BenchmarkPopcnt1(b *testing.B) {
for i := 0; i < b.N; i++ {
popcnt(uint64(i))
}
}然而，如果我們執(zhí)行這個(gè)基準(zhǔn)測試，結(jié)果會(huì)非常低得令人驚訝：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkPopcnt1-4 1000000000 0.2858 ns/op一個(gè)持續(xù)時(shí)間為0.28納秒大約是一個(gè)時(shí)鐘周期，所以這個(gè)數(shù)字是非常不合理地低。問題在于開發(fā)者對編譯器優(yōu)化不夠謹(jǐn)慎。在這種情況下，被測試的函數(shù)非常簡單，可以成為內(nèi)聯(lián)的候選對象：一種優(yōu)化，用被調(diào)用函數(shù)的主體替換函數(shù)調(diào)用，讓我們避免函數(shù)調(diào)用，這具有很小的開銷。一旦函數(shù)被內(nèi)聯(lián)，編譯器注意到調(diào)用沒有副作用，并用以下基準(zhǔn)測試替換了它：
func BenchmarkPopcnt1(b *testing.B) {
for i := 0; i < b.N; i++ {
// Empty
}
}現(xiàn)在基準(zhǔn)測試是空的，這就是我們得到接近一個(gè)時(shí)鐘周期結(jié)果的原因。為了防止這種情況發(fā)生，最佳實(shí)踐是遵循以下模式：
- 在每個(gè)循環(huán)迭代中，將結(jié)果賦值給一個(gè)局部變量（在基準(zhǔn)測試函數(shù)的上下文中為局部變量）。
- 將最新的結(jié)果賦值給一個(gè)全局變量。
在我們的情況下，我們編寫以下基準(zhǔn)測試：
var global uint64 // Define a global variable
func BenchmarkPopcnt2(b *testing.B) {
var v uint64 // Define a local variable
for i := 0; i < b.N; i++ {
v = popcnt(uint64(i)) // Assign the result to the local variable
}
global = v // Assign the result to the global variable
}global 是一個(gè)全局變量，而 v 是一個(gè)局部變量，其作用域限定在基準(zhǔn)測試函數(shù)內(nèi)部。在每個(gè)循環(huán)迭代中，我們將 popcnt 的結(jié)果賦值給局部變量 v。然后將最新的結(jié)果賦值給全局變量 global。
如果我們運(yùn)行這兩個(gè)基準(zhǔn)測試，現(xiàn)在結(jié)果之間會(huì)有顯著的差異：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkPopcnt1-4 1000000000 0.2858 ns/op
BenchmarkPopcnt2-4 606402058 1.993 ns/opBenchmarkPopcnt2 是基準(zhǔn)測試的準(zhǔn)確版本。它確保我們避免了內(nèi)聯(lián)優(yōu)化，這種優(yōu)化可能會(huì)人為降低執(zhí)行時(shí)間，甚至去除對被測試函數(shù)的調(diào)用。依賴BenchmarkPopcnt1的結(jié)果可能會(huì)導(dǎo)致錯(cuò)誤的假設(shè)。
讓我們記住避免編譯器優(yōu)化誤導(dǎo)基準(zhǔn)測試結(jié)果的模式：將被測試函數(shù)的結(jié)果賦值給一個(gè)局部變量，然后將最新的結(jié)果賦值給一個(gè)全局變量。這種最佳實(shí)踐還可以防止我們做出不正確的假設(shè)。
被觀察效應(yīng)的欺騙
在物理學(xué)中，觀察者效應(yīng)是通過觀察行為干擾觀察系統(tǒng)的現(xiàn)象。這種效應(yīng)也可以在基準(zhǔn)測試中看到，并可能導(dǎo)致對結(jié)果做出錯(cuò)誤的假設(shè)。讓我們看一個(gè)具體的例子，然后嘗試減輕這種影響。
我們想要實(shí)現(xiàn)一個(gè)接收int64元素矩陣的函數(shù)。這個(gè)矩陣有固定的512列，我們想要計(jì)算前八列的總和，如圖11.2所示。
計(jì)算前八列的總和
為了優(yōu)化的目的，我們還想確定變化列數(shù)是否會(huì)產(chǎn)生影響，所以我們也實(shí)現(xiàn)了一個(gè)有513列的第二個(gè)函數(shù)。實(shí)現(xiàn)如下：
func calculateSum512(s [][512]int64) int64 {
var sum int64
for i := 0; i < len(s); i++ { // Iterate over each row
for j := 0; j < 8; j++ { // Iterate over the first eight columns
sum += s[i][j] // Increment sum
}
}
return sum
}
func calculateSum513(s [][513]int64) int64 {
// Same implementation as calculateSum512
}我們遍歷每一行，然后遍歷前八列，并增加一個(gè)我們要返回的總和變量。在calculateSum513中的實(shí)現(xiàn)保持不變。
我們想對這些函數(shù)進(jìn)行基準(zhǔn)測試，以決定在固定行數(shù)的情況下哪一個(gè)性能最好：
const rows = 1000
var res int64
func BenchmarkCalculateSum512(b *testing.B) {
var sum int64
s := createMatrix512(rows) // Create a matrix of 512 columns
b.ResetTimer()
for i := 0; i < b.N; i++ {
sum = calculateSum512(s) // Create a matrix of 512 columns
}
res = sum
}
func BenchmarkCalculateSum513(b *testing.B) {
var sum int64
s := createMatrix513(rows) // Create a matrix of 513 columns
b.ResetTimer()
for i := 0; i < b.N; i++ {
sum = calculateSum513(s) // Calculate the sum
}
res = sum
}我們希望只創(chuàng)建一次矩陣，以限制對結(jié)果的影響。因此，我們在循環(huán)外調(diào)用createMatrix512和createMatrix513。我們可能期望結(jié)果會(huì)類似，因?yàn)槲覀冎幌氡闅v前八列，但事實(shí)并非如此（在我的機(jī)器上）：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkCalculateSum512-4 81854 15073 ns/op
BenchmarkCalculateSum513-4 161479 7358 ns/op第二個(gè)擁有513列的基準(zhǔn)測試要快大約50%。再次強(qiáng)調(diào)，因?yàn)槲覀冎槐闅v了前八列，這個(gè)結(jié)果相當(dāng)令人驚訝。
要理解這種差異，我們需要了解CPU緩存的基礎(chǔ)知識。簡而言之，CPU由不同的緩存組成（通常是L1、L2和L3）。這些緩存降低了從主存儲器訪問數(shù)據(jù)的平均成本。在某些條件下，CPU可以從主存儲器獲取數(shù)據(jù)并將其復(fù)制到L1。在這種情況下，CPU試圖將calculateSum感興趣的矩陣子集（每行的前八列）放入L1。然而，一個(gè)情況下矩陣可以完全放入內(nèi)存（513列），而另一個(gè)情況下不能（512列）。
回到基準(zhǔn)測試，主要問題在于我們在兩種情況下都重復(fù)使用相同的矩陣。因?yàn)樵摵瘮?shù)重復(fù)執(zhí)行數(shù)千次，我們并未測量接收純新矩陣的函數(shù)執(zhí)行情況。相反，我們測量的是一個(gè)已經(jīng)包含在緩存中的矩陣的子集的函數(shù)。因此，由于calculateSum513導(dǎo)致的緩存未命中更少，它具有更好的執(zhí)行時(shí)間。
這是觀察效應(yīng)的一個(gè)例子。因?yàn)槲覀円恢痹谟^察重復(fù)調(diào)用的CPU密集型函數(shù)，CPU緩存可能會(huì)起作用，并且會(huì)對結(jié)果產(chǎn)生顯著影響。在這個(gè)例子中，為了防止這種效應(yīng)，我們應(yīng)該在每次測試中創(chuàng)建一個(gè)新的矩陣，而不是重復(fù)使用一個(gè)：
func BenchmarkCalculateSum512(b *testing.B) {
var sum int64
for i := 0; i < b.N; i++ {
b.StopTimer()
s := createMatrix512(rows) // Create a new matrix during each loop iteration
b.StartTimer()
sum = calculateSum512(s)
}
res = sum
}現(xiàn)在在每次循環(huán)迭代中都創(chuàng)建了一個(gè)新的矩陣。如果我們再次運(yùn)行基準(zhǔn)測試（并調(diào)整benchtime——否則執(zhí)行時(shí)間太長），結(jié)果會(huì)更接近：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz
BenchmarkCalculateSum512-4 1116 33547 ns/op
BenchmarkCalculateSum513-4 998 35507 ns/op不是做出calculateSum513更快的錯(cuò)誤假設(shè)，我們看到當(dāng)接收新矩陣時(shí)，兩個(gè)基準(zhǔn)測試的結(jié)果更接近。
正如我們在本文中看到的那樣，因?yàn)槲覀冎貜?fù)使用了同一個(gè)矩陣，CPU緩存對結(jié)果產(chǎn)生了顯著影響。為了防止這種情況發(fā)生，我們必須在每個(gè)循環(huán)迭代期間創(chuàng)建一個(gè)新的矩陣。總的來說，我們應(yīng)該記住，在觀察一個(gè)被測試函數(shù)的情況下，可能會(huì)在結(jié)果中產(chǎn)生顯著差異，特別是在涉及低級優(yōu)化的CPU密集型函數(shù)的微基準(zhǔn)測試中。強(qiáng)制基準(zhǔn)測試在每次迭代期間重新創(chuàng)建數(shù)據(jù)可能是防止這種影響的一種好方法。
結(jié)論
- 使用時(shí)間方法來保持基準(zhǔn)測試的準(zhǔn)確性。
- 當(dāng)處理微基準(zhǔn)測試時(shí)，增加benchtime或使用benchstat等工具可能會(huì)有所幫助。
- 注意微基準(zhǔn)測試的結(jié)果，如果最終運(yùn)行應(yīng)用程序的系統(tǒng)與運(yùn)行微基準(zhǔn)測試的系統(tǒng)不同。
- 確保被測試函數(shù)產(chǎn)生了副作用，以防止編譯器優(yōu)化讓您對基準(zhǔn)測試結(jié)果產(chǎn)生誤解。
- 為了防止觀察者效應(yīng)，強(qiáng)制基準(zhǔn)測試重新創(chuàng)建CPU密集型函數(shù)使用的數(shù)據(jù)。
