一加Ace2 Pro真機(jī)揭曉 鈦空灰配色質(zhì)感拉滿
終于，在經(jīng)過了幾波預(yù)熱之后，一加Ace2 Pro的外觀真機(jī)圖在網(wǎng)上出現(xiàn)了。還是博主數(shù)碼閑聊站曝光的，這次的外觀設(shè)計(jì)還是延續(xù)了一加11的方案，只是細(xì)節(jié)上有了調(diào)整，例如新加入了鈦空灰
一般來說，我們不應(yīng)該對(duì)性能進(jìn)行猜測(cè)。在編寫優(yōu)化時(shí)，會(huì)有許多因素可能起作用，即使我們對(duì)結(jié)果有很強(qiáng)的看法，測(cè)試它們很少是一個(gè)壞主意。然而，編寫基準(zhǔn)測(cè)試并不簡(jiǎn)單。很容易編寫不準(zhǔn)確的基準(zhǔn)測(cè)試，并且基于這些測(cè)試得出錯(cuò)誤的假設(shè)。這篇文章的目標(biāo)是探討導(dǎo)致不準(zhǔn)確的四個(gè)常見和具體陷阱：
在討論這些陷阱之前，讓我們簡(jiǎn)要回顧一下 Go 語言中基準(zhǔn)測(cè)試的工作原理。基準(zhǔn)測(cè)試的框架大致如下：
func BenchmarkFoo(b *testing.B) { for i := 0; i < b.N; i++ { foo() }}函數(shù)名以Benchmark前綴開頭。被測(cè)試的函數(shù)（foo）在for循環(huán)內(nèi)被調(diào)用。b.N代表著可變數(shù)量的迭代次數(shù)。在運(yùn)行基準(zhǔn)測(cè)試時(shí)，Go 會(huì)嘗試使其匹配所請(qǐng)求的基準(zhǔn)測(cè)試時(shí)間。基準(zhǔn)測(cè)試時(shí)間默認(rèn)設(shè)置為1秒，可以使用-benchtime標(biāo)志進(jìn)行更改。b.N從1開始；如果基準(zhǔn)測(cè)試在1秒內(nèi)完成，b.N會(huì)增加，然后再次運(yùn)行基準(zhǔn)測(cè)試，直到b.N大致匹配benchtime為止。
$ go test -bench=.cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkFoo-4 73 16511228 ns/op在這里，基準(zhǔn)測(cè)試大約花費(fèi)了1秒鐘，foo被執(zhí)行了73次，平均執(zhí)行時(shí)間為16,511,228納秒。我們可以使用-benchtime來更改基準(zhǔn)測(cè)試時(shí)間：
$ go test -bench=. -benchtime=2sBenchmarkFoo-4 150 15832169 ns/opfoo 的執(zhí)行次數(shù)大約是上一個(gè)基準(zhǔn)測(cè)試的兩倍。
接下來，讓我們看一些常見的陷阱。
在某些情況下，我們需要在基準(zhǔn)測(cè)試循環(huán)之前執(zhí)行一些操作。這些操作可能需要相當(dāng)長(zhǎng)的時(shí)間（例如，生成一個(gè)大型數(shù)據(jù)切片），可能會(huì)對(duì)基準(zhǔn)測(cè)試結(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ì)將自測(cè)試開始以來的經(jīng)過時(shí)間和內(nèi)存分配計(jì)數(shù)器歸零。這樣，一個(gè)昂貴的設(shè)置步驟可以從測(cè)試結(jié)果中排除。
如果我們不僅需要在測(cè)試中執(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)測(cè)試計(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)測(cè)試計(jì)時(shí)器來執(zhí)行昂貴的設(shè)置步驟，然后恢復(fù)計(jì)時(shí)器。
注意： 關(guān)于這種方法有一個(gè)需要記住的地方：如果被測(cè)試的函數(shù)執(zhí)行速度遠(yuǎn)遠(yuǎn)比設(shè)置函數(shù)要快，那么基準(zhǔn)測(cè)試可能會(huì)花費(fèi)太長(zhǎng)時(shí)間才能完成。原因是它需要比 benchtime 更長(zhǎng)的時(shí)間才能完成。基準(zhǔn)測(cè)試時(shí)間的計(jì)算完全基于 functionUnderTest 的執(zhí)行時(shí)間。所以，如果在每個(gè)循環(huán)迭代中等待了相當(dāng)長(zhǎng)的時(shí)間，基準(zhǔn)測(cè)試就會(huì)比1秒要慢得多。如果我們想保持基準(zhǔn)測(cè)試，一種可能的緩解方法是減少 benchtime 。
我們必須確保使用計(jì)時(shí)器方法來保持基準(zhǔn)測(cè)試的準(zhǔn)確性。
微基準(zhǔn)測(cè)試測(cè)量的是微小的計(jì)算單元，很容易對(duì)它做出錯(cuò)誤的假設(shè)。比如說，我們不確定是應(yīng)該使用atomic.StoreInt32還是atomic.StoreInt64（假設(shè)處理的值始終適合32位）。我們想編寫一個(gè)基準(zhǔn)測(cè)試來比較這兩個(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)測(cè)試，以下是一些示例輸出：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkAtomicStoreInt32BenchmarkAtomicStoreInt32-4 197107742 5.682 ns/opBenchmarkAtomicStoreInt64BenchmarkAtomicStoreInt64-4 213917528 5.134 ns/op我們很容易認(rèn)為這個(gè)基準(zhǔn)測(cè)試并且決定使用atomic.StoreInt64，因?yàn)樗雌饋砀臁，F(xiàn)在，為了進(jìn)行一次公平的基準(zhǔn)測(cè)試，我們改變順序，先測(cè)試atomic.StoreInt64，然后測(cè)試atomic.StoreInt32。以下是一些示例輸出：
BenchmarkAtomicStoreInt64BenchmarkAtomicStoreInt64-4 224900722 5.434 ns/opBenchmarkAtomicStoreInt32BenchmarkAtomicStoreInt32-4 230253900 5.159 ns/op這次，atomic.StoreInt32有更好的結(jié)果。發(fā)生了什么事？
在微基準(zhǔn)測(cè)試中，許多因素都會(huì)影響結(jié)果，比如在運(yùn)行基準(zhǔn)測(cè)試時(shí)的機(jī)器活動(dòng)、電源管理、熱管理和一系列指令的更好的緩存對(duì)齊。我們必須記住，許多因素，甚至超出我們 Go 項(xiàng)目范圍的因素，都可能會(huì)影響結(jié)果。
注意： 我們應(yīng)該確保運(yùn)行基準(zhǔn)測(cè)試的機(jī)器處于空閑狀態(tài)。但是，外部進(jìn)程可能在后臺(tái)運(yùn)行，這可能會(huì)影響基準(zhǔn)測(cè)試結(jié)果。因此，像 perflock 這樣的工具可以限制基準(zhǔn)測(cè)試可以消耗的CPU。例如，我們可以使用總可用CPU的70%來運(yùn)行基準(zhǔn)測(cè)試，將30%分配給操作系統(tǒng)和其他進(jìn)程，減少機(jī)器活動(dòng)因素對(duì)結(jié)果的影響。
一個(gè)選擇是使用-benchtime選項(xiàng)增加基準(zhǔn)測(cè)試時(shí)間。類似于概率論中的大數(shù)定律，如果我們運(yùn)行大量次數(shù)的基準(zhǔn)測(cè)試，它應(yīng)該趨向于接近其期望值（假設(shè)我們忽略了指令緩存等機(jī)制的好處）。
另一個(gè)選擇是在經(jīng)典基準(zhǔn)測(cè)試工具之上使用外部工具。例如，benchstat工具是golang.org/x代碼庫的一部分，它允許我們計(jì)算和比較有關(guān)基準(zhǔn)測(cè)試執(zhí)行的統(tǒng)計(jì)數(shù)據(jù)。
讓我們使用-count選項(xiàng)運(yùn)行基準(zhǔn)測(cè)試10次，并將輸出重定向到一個(gè)特定的文件：
$ go test -bench=. -count=10 | tee stats.txtcpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkAtomicStoreInt32-4 234935682 5.124 ns/opBenchmarkAtomicStoreInt32-4 235307204 5.112 ns/op// ...BenchmarkAtomicStoreInt64-4 235548591 5.107 ns/opBenchmarkAtomicStoreInt64-4 235210292 5.090 ns/op// ...然后我們可以在這個(gè)文件上運(yùn)行benchstat：
$ benchstat stats.txtname time/opAtomicStoreInt32-4 5.10ns ± 1%AtomicStoreInt64-4 5.10ns ± 1%結(jié)果是一樣的：兩個(gè)函數(shù)的平均完成時(shí)間都是5.10納秒。我們還可以看到給定基準(zhǔn)測(cè)試執(zhí)行間的百分比變化：±1%。這個(gè)指標(biāo)告訴我們，兩個(gè)基準(zhǔn)測(cè)試都是穩(wěn)定的，這讓我們對(duì)計(jì)算出的平均結(jié)果更有信心。因此，我們不能得出atomic.StoreInt32比atomic.StoreInt64快或慢的結(jié)論，而是可以得出對(duì)于我們測(cè)試的用途（在特定的Go版本和特定的機(jī)器上），它們的執(zhí)行時(shí)間是相似的。
總的來說，我們?cè)谶M(jìn)行微基準(zhǔn)測(cè)試時(shí)應(yīng)該保持謹(jǐn)慎。許多因素都可以對(duì)結(jié)果產(chǎn)生重大影響，并潛在地導(dǎo)致錯(cuò)誤的假設(shè)。增加基準(zhǔn)測(cè)試時(shí)間或重復(fù)基準(zhǔn)測(cè)試的執(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)測(cè)試的結(jié)果。生產(chǎn)系統(tǒng)的行為可能與我們運(yùn)行微基準(zhǔn)測(cè)試的系統(tǒng)大不相同。
與編寫基準(zhǔn)測(cè)試相關(guān)的另一個(gè)常見錯(cuò)誤是被編譯器優(yōu)化所欺騙，這也可能導(dǎo)致錯(cuò)誤的基準(zhǔn)測(cè)試假設(shè)。在這一節(jié)中，我們將看看Go語言的14813號(hào)問題（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 = 0x5555555555555555const m2 = 0x3333333333333333const m4 = 0x0f0f0f0f0f0f0f0fconst h01 = 0x0101010101010101func 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。為了對(duì)這個(gè)函數(shù)進(jìn)行基準(zhǔn)測(cè)試，我們可以編寫以下內(nèi)容：
func BenchmarkPopcnt1(b *testing.B) { for i := 0; i < b.N; i++ { popcnt(uint64(i)) }}然而，如果我們執(zhí)行這個(gè)基準(zhǔn)測(cè)試，結(jié)果會(huì)非常低得令人驚訝：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkPopcnt1-4 1000000000 0.2858 ns/op一個(gè)持續(xù)時(shí)間為0.28納秒大約是一個(gè)時(shí)鐘周期，所以這個(gè)數(shù)字是非常不合理地低。問題在于開發(fā)者對(duì)編譯器優(yōu)化不夠謹(jǐn)慎。在這種情況下，被測(cè)試的函數(shù)非常簡(jiǎn)單，可以成為內(nèi)聯(lián)的候選對(duì)象：一種優(yōu)化，用被調(diào)用函數(shù)的主體替換函數(shù)調(diào)用，讓我們避免函數(shù)調(diào)用，這具有很小的開銷。一旦函數(shù)被內(nèi)聯(lián)，編譯器注意到調(diào)用沒有副作用，并用以下基準(zhǔn)測(cè)試替換了它：
func BenchmarkPopcnt1(b *testing.B) { for i := 0; i < b.N; i++ { // Empty }}現(xiàn)在基準(zhǔn)測(cè)試是空的，這就是我們得到接近一個(gè)時(shí)鐘周期結(jié)果的原因。為了防止這種情況發(fā)生，最佳實(shí)踐是遵循以下模式：
在我們的情況下，我們編寫以下基準(zhǔn)測(cè)試：
var global uint64 // Define a global variablefunc 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)測(cè)試函數(shù)內(nèi)部。在每個(gè)循環(huán)迭代中，我們將 popcnt 的結(jié)果賦值給局部變量 v。然后將最新的結(jié)果賦值給全局變量 global。
如果我們運(yùn)行這兩個(gè)基準(zhǔn)測(cè)試，現(xiàn)在結(jié)果之間會(huì)有顯著的差異：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkPopcnt1-4 1000000000 0.2858 ns/opBenchmarkPopcnt2-4 606402058 1.993 ns/opBenchmarkPopcnt2 是基準(zhǔn)測(cè)試的準(zhǔn)確版本。它確保我們避免了內(nèi)聯(lián)優(yōu)化，這種優(yōu)化可能會(huì)人為降低執(zhí)行時(shí)間，甚至去除對(duì)被測(cè)試函數(shù)的調(diào)用。依賴BenchmarkPopcnt1的結(jié)果可能會(huì)導(dǎo)致錯(cuò)誤的假設(shè)。
讓我們記住避免編譯器優(yōu)化誤導(dǎo)基準(zhǔn)測(cè)試結(jié)果的模式：將被測(cè)試函數(shù)的結(jié)果賦值給一個(gè)局部變量，然后將最新的結(jié)果賦值給一個(gè)全局變量。這種最佳實(shí)踐還可以防止我們做出不正確的假設(shè)。
在物理學(xué)中，觀察者效應(yīng)是通過觀察行為干擾觀察系統(tǒng)的現(xiàn)象。這種效應(yīng)也可以在基準(zhǔn)測(cè)試中看到，并可能導(dǎo)致對(duì)結(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)保持不變。
我們想對(duì)這些函數(shù)進(jìn)行基準(zhǔn)測(cè)試，以決定在固定行數(shù)的情況下哪一個(gè)性能最好：
const rows = 1000var res int64func 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)建一次矩陣，以限制對(duì)結(jié)果的影響。因此，我們?cè)谘h(huán)外調(diào)用createMatrix512和createMatrix513。我們可能期望結(jié)果會(huì)類似，因?yàn)槲覀冎幌氡闅v前八列，但事實(shí)并非如此（在我的機(jī)器上）：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkCalculateSum512-4 81854 15073 ns/opBenchmarkCalculateSum513-4 161479 7358 ns/op第二個(gè)擁有513列的基準(zhǔn)測(cè)試要快大約50%。再次強(qiáng)調(diào)，因?yàn)槲覀冎槐闅v了前八列，這個(gè)結(jié)果相當(dāng)令人驚訝。
要理解這種差異，我們需要了解CPU緩存的基礎(chǔ)知識(shí)。簡(jiǎn)而言之，CPU由不同的緩存組成（通常是L1、L2和L3）。這些緩存降低了從主存儲(chǔ)器訪問數(shù)據(jù)的平均成本。在某些條件下，CPU可以從主存儲(chǔ)器獲取數(shù)據(jù)并將其復(fù)制到L1。在這種情況下，CPU試圖將calculateSum感興趣的矩陣子集（每行的前八列）放入L1。然而，一個(gè)情況下矩陣可以完全放入內(nèi)存（513列），而另一個(gè)情況下不能（512列）。
回到基準(zhǔn)測(cè)試，主要問題在于我們?cè)趦煞N情況下都重復(fù)使用相同的矩陣。因?yàn)樵摵瘮?shù)重復(fù)執(zhí)行數(shù)千次，我們并未測(cè)量接收純新矩陣的函數(shù)執(zhí)行情況。相反，我們測(cè)量的是一個(gè)已經(jīng)包含在緩存中的矩陣的子集的函數(shù)。因此，由于calculateSum513導(dǎo)致的緩存未命中更少，它具有更好的執(zhí)行時(shí)間。
這是觀察效應(yīng)的一個(gè)例子。因?yàn)槲覀円恢痹谟^察重復(fù)調(diào)用的CPU密集型函數(shù)，CPU緩存可能會(huì)起作用，并且會(huì)對(duì)結(jié)果產(chǎn)生顯著影響。在這個(gè)例子中，為了防止這種效應(yīng)，我們應(yīng)該在每次測(cè)試中創(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è)新的矩陣。如果我們?cè)俅芜\(yùn)行基準(zhǔn)測(cè)試（并調(diào)整benchtime——否則執(zhí)行時(shí)間太長(zhǎng)），結(jié)果會(huì)更接近：
cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHzBenchmarkCalculateSum512-4 1116 33547 ns/opBenchmarkCalculateSum513-4 998 35507 ns/op不是做出calculateSum513更快的錯(cuò)誤假設(shè)，我們看到當(dāng)接收新矩陣時(shí)，兩個(gè)基準(zhǔn)測(cè)試的結(jié)果更接近。
正如我們?cè)诒疚闹锌吹降哪菢樱驗(yàn)槲覀冎貜?fù)使用了同一個(gè)矩陣，CPU緩存對(duì)結(jié)果產(chǎn)生了顯著影響。為了防止這種情況發(fā)生，我們必須在每個(gè)循環(huán)迭代期間創(chuàng)建一個(gè)新的矩陣。總的來說，我們應(yīng)該記住，在觀察一個(gè)被測(cè)試函數(shù)的情況下，可能會(huì)在結(jié)果中產(chǎn)生顯著差異，特別是在涉及低級(jí)優(yōu)化的CPU密集型函數(shù)的微基準(zhǔn)測(cè)試中。強(qiáng)制基準(zhǔn)測(cè)試在每次迭代期間重新創(chuàng)建數(shù)據(jù)可能是防止這種影響的一種好方法。
本文鏈接：http://www.tebozhan.com/showinfo-26-34662-0.html如何在 GO 中寫出準(zhǔn)確的基準(zhǔn)測(cè)試
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)