为什么对基准测试代码的优化没有生效？

在优化 Go 中的“nth-prime”计算时，作者发现添加两个看似多余的初始 if 语句后，基准测试速度却变快了。通过分析汇编代码，作者发现这些 if 语句可以保证对输入进行断言，从而让编译器不必在每次迭代时自行验证，从而减少了 CPU 的工作量。

我最近在 exercism.io 上开始了 go 赛道，并在优化“nth-prime”计算方面获得了乐趣。事实上，我发现了一个我无法解释的有趣事实。想象一下以下代码：

// package prime provides ...
package prime

// nth function checks for the prime number on position n
func nth(n int) (int, bool) {
        if n <= 0 {
            return 0, false
        }

        if (n == 1) {
            return 2, true
        }

        currentnumber := 1
        primecounter := 1

        for n > primecounter {
            currentnumber+=2
            if isprime(currentnumber) {
                primecounter++
            }
        }
        return currentnumber, primecounter==n
}

// isprime function checks if a number 
// is a prime number
func isprime(n int) bool {
    //useless because never triggered but makes it faster??
    if n < 2 {
        println("n < 2")
        return false
    }

    //useless because never triggered but makes it faster??
    if n%2 == 0 {
        println("n%2")
        return n==2
    }

    for i := 3; i*i <= n; i+=2 {
        if n%i == 0 {
            return false
        }
    }
    return true
}

在私有函数 isprime 中，我有两个永远不会触发的初始 if 语句，因为我只给出大于 2 的奇数。基准返回如下：

running tool: /usr/bin/go test -benchmem -run=^$ -bench ^(benchmarknth)$

benchmarknth-8           100      18114825 ns/op           0 b/op          0

如果我删除从未触发的 if 语句，基准测试会变慢：

Running tool: /usr/bin/go test -benchmem -run=^$ -bench ^(BenchmarkNth)$

BenchmarkNth-8            50      21880749 ns/op           0 B/op          0

我已经多次运行基准测试，来回更改代码，总是得到或多或少相同的数字，但我想不出这两个 if 语句应该使执行速度更快的原因。是的，这是微优化，但我想知道：为什么？

这是带有测试用例的练习的完整练习：nth-​​prime

我在 manjaro i3 linux 上使用的 go 版本是 1.12.1 linux/amd64

解决方案

当添加这些 if 时，编译器可以保证对输入进行一些断言。 如果这些断言被解除，编译器必须自己添加它。它的方法是在每次迭代时验证它。我们可以看一下汇编代码来证明这一点。 （通过将 -gcflags=-s 传递给 go test 命令）

使用 if：

0x004b 00075 (func.go:16)  jmp     81
0x004d 00077 (func.go:16)  leaq    2(bx), ax
0x0051 00081 (func.go:16)  movq    ax, dx
0x0054 00084 (func.go:16)  imulq   ax, ax
0x0058 00088 (func.go:16)  cmpq    ax, cx
0x005b 00091 (func.go:16)  jgt     133
0x005d 00093 (func.go:17)  testq   dx, dx
0x0060 00096 (func.go:17)  jeq     257
0x0066 00102 (func.go:17)  movq    cx, ax
0x0069 00105 (func.go:17)  movq    dx, bx
0x006c 00108 (func.go:17)  cqo
0x006e 00110 (func.go:17)  idivq   bx
0x0071 00113 (func.go:17)  testq   dx, dx
0x0074 00116 (func.go:17)  jne     77

没有 if：

0x0016 00022 (func.go:16)  JMP     28
0x0018 00024 (func.go:16)  LEAQ    2(BX), AX
0x001c 00028 (func.go:16)  MOVQ    AX, DX
0x001f 00031 (func.go:16)  IMULQ   AX, AX
0x0023 00035 (func.go:16)  CMPQ    AX, CX
0x0026 00038 (func.go:16)  JGT     88
0x0028 00040 (func.go:17)  TESTQ   DX, DX
0x002b 00043 (func.go:17)  JEQ     102
0x002d 00045 (func.go:17)  MOVQ    CX, AX
0x0030 00048 (func.go:17)  MOVQ    DX, BX
0x0033 00051 (func.go:17)  CMPQ    BX, $-1
0x0037 00055 (func.go:17)  JEQ     64
0x0039 00057 (func.go:17)  CQO
0x003b 00059 (func.go:17)  IDIVQ   BX
0x003e 00062 (func.go:17)  JMP     69
0x0040 00064 func.go:17)  NEGQ    AX
0x0043 00067 (func.go:17)  XORL    DX, DX
0x0045 00069 (func.go:17)  TESTQ   DX, DX
0x0048 00072 (func.go:17)  JNE     24

汇编代码 0x0033 00051 (func.go:17) cmpq bx 中的第 51 行，$-1 是罪魁祸首。

第 16 行，for i := 3; i*i <= n; i+=2，在原始 go 代码中，对于这两种情况的翻译是相同的。但是，运行每次迭代的第 17 行 if n%i == 0 会编译为更多指令，从而为 cpu 带来更多工作。

encoding/base64 包中的类似内容，确保循环不会收到 nil 值。你可以在这里看看： https://go-review.googlesource.com/c/go/+/151158/3/src/encoding/base64/base64.go 此检查是有意添加的。就你而言，你无意中优化了它:)

今天关于《为什么对基准测试代码的优化没有生效？》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！