12 KiB
Go 中对栈中函数进行内联
上一篇文章中我论述了叶子内联是怎样让 Go 编译器减少函数调用的开销的，以及延伸出了跨函数边界的优化的机会。本文中，我要论述内联的限制以及叶子内联与栈中内联的对比。
内联的限制
把函数内联到它的调用处消除了调用的开销，为编译器进行其他的优化提供了更好的机会，那么问题来了，既然内联这么好，内联得越多开销就越少，为什么不尽可能多地内联呢？
内联可能会以增加程序大小换来更快的执行时间。限制内联的最主要原因是，创建许多函数的内联副本会增加编译时间，并导致生成更大的二进制文件的边际效应。即使把内联带来的进一步的优化机会考虑在内，太激进的内联也可能会增加生成的二进制文件的大小和编译时间。
内联收益最大的是小函数，相对于调用它们的开销来说，这些函数做很少的工作。随着函数大小的增长，函数内部做的工作与函数调用的开销相比省下的时间越来越少。函数越大通常越复杂，因此优化其内联形式相对于原地优化的好处会减少。
内联预算
在编译过程中，每个函数的内联能力是用内联预算计算的 1。开销的计算过程可以巧妙地内化，像一元和二元等简单操作，在抽象语法数（AST）中通常是每个节点一个单位，更复杂的操作如 make 可能单位更多。考虑下面的例子：
package main
func small() string {
s := "hello, " + "world!"
return s
}
func large() string {
s := "a"
s += "b"
s += "c"
s += "d"
s += "e"
s += "f"
s += "g"
s += "h"
s += "i"
s += "j"
s += "k"
s += "l"
s += "m"
s += "n"
s += "o"
s += "p"
s += "q"
s += "r"
s += "s"
s += "t"
s += "u"
s += "v"
s += "w"
s += "x"
s += "y"
s += "z"
return s
}
func main() {
small()
large()
}
使用 -gcflags=-m=2 参数编译这个函数能让我们看到编译器分配给每个函数的开销：
% go build -gcflags=-m=2 inl.go
# command-line-arguments
./inl.go:3:6: can inline small with cost 7 as: func() string { s := "hello, world!"; return s }
./inl.go:8:6: cannot inline large: function too complex: cost 82 exceeds budget 80
./inl.go:38:6: can inline main with cost 68 as: func() { small(); large() }
./inl.go:39:7: inlining call to small func() string { s := "hello, world!"; return s }
编译器根据函数 func small() 的开销（7）决定可以对它内联，而 func large() 的开销太大，编译器决定不进行内联。func main() 被标记为适合内联的，分配了 68 的开销；其中 small 占用 7，调用 small 函数占用 57，剩余的（4）是它自己的开销。
可以用 -gcflag=-l 参数控制内联预算的等级。下面是可使用的值：
-gcflags=-l=0默认的内联等级。-gcflags=-l（或-gcflags=-l=1）取消内联。-gcflags=-l=2和-gcflags=-l=3现在已经不使用了。和-gcflags=-l=0相比没有区别。-gcflags=-l=4减少非叶子函数和通过接口调用的函数的开销。2
不确定语句的优化
一些函数虽然内联的开销很小，但由于太复杂它们仍不适合进行内联。这就是函数的不确定性，因为一些操作的语义在内联后很难去推导，如 recover、break。其他的操作，如 select 和 go 涉及运行时的协调，因此内联后引入的额外的开销不能抵消内联带来的收益。
不确定的语句也包括 for 和 range，这些语句不一定开销很大，但目前为止还没有对它们进行优化。
栈中函数优化
在过去，Go 编译器只对叶子函数进行内联 —— 只有那些不调用其他函数的函数才有资格。在上一段不确定的语句的探讨内容中，一次函数调用就会让这个函数失去内联的资格。
进入栈中进行内联，就像它的名字一样，能内联在函数调用栈中间的函数，不需要先让它下面的所有的函数都被标记为有资格内联的。栈中内联是 David Lazar 在 Go 1.9 中引入的，并在随后的版本中做了改进。[这篇文稿][5]深入探究了保留栈追踪行为和被深度内联后的代码路径里的 runtime.Callers 的难点。
在前面的例子中我们看到了栈中函数内联。内联后，func main() 包含了 func small() 的函数体和对 func large() 的一次调用，因此它被判定为非叶子函数。在过去，这会阻止它被继续内联，虽然它的联合开销小于内联预算。
栈中内联的最主要的应用案例就是减少贯穿函数调用栈的开销。考虑下面的例子：
package main
import (
"fmt"
"strconv"
)
type Rectangle struct {}
//go:noinline
func (r *Rectangle) Height() int {
h, _ := strconv.ParseInt("7", 10, 0)
return int(h)
}
func (r *Rectangle) Width() int {
return 6
}
func (r *Rectangle) Area() int { return r.Height() * r.Width() }
func main() {
var r Rectangle
fmt.Println(r.Area())
}
在这个例子中， r.Area() 是个简单的函数，调用了两个函数。r.Width() 可以被内联，r.Height() 这里用 //go:noinline 指令标注了，不能被内联。3
% go build -gcflags='-m=2' square.go
# command-line-arguments
./square.go:12:6: cannot inline (*Rectangle).Height: marked go:noinline
./square.go:17:6: can inline (*Rectangle).Width with cost 2 as: method(*Rectangle) func() int { return 6 }
./square.go:21:6: can inline (*Rectangle).Area with cost 67 as: method(*Rectangle) func() int { return r.Height() * r.Width() }
./square.go:21:61: inlining call to (*Rectangle).Width method(*Rectangle) func() int { return 6 }
./square.go:23:6: cannot inline main: function too complex: cost 150 exceeds budget 80
./square.go:25:20: inlining call to (*Rectangle).Area method(*Rectangle) func() int { return r.Height() * r.Width() }
./square.go:25:20: inlining call to (*Rectangle).Width method(*Rectangle) func() int { return 6 }
由于 r.Area() 中的乘法与调用它的开销相比并不大，因此内联它的表达式是纯收益，即使它的调用的下游 r.Height() 仍是没有内联资格的。
快速路径内联
关于栈中内联的效果最令人吃惊的例子是 2019 年 [Carlo Alberto Ferraris][7] 通过允许把 sync.Mutex.Lock() 的快速路径（非竞争的情况）内联到它的调用方来[提升它的性能][7]。在这个修改之前，sync.Mutex.Lock() 是个很大的函数，包含很多难以理解的条件，使得它没有资格被内联。即使锁可用时，调用者也要付出调用 sync.Mutex.Lock() 的代价。
Carlo 把 sync.Mutex.Lock() 分成了两个函数（他自己称为外联）。外部的 sync.Mutex.Lock() 方法现在调用 sync/atomic.CompareAndSwapInt32() 且如果 CAS（比较并交换）成功了之后立即返回给调用者。如果 CAS 失败，函数会走到 sync.Mutex.lockSlow() 慢速路径，需要对锁进行注册，暂停 goroutine。4
% go build -gcflags='-m=2 -l=0' sync 2>&1 | grep '(*Mutex).Lock'
../go/src/sync/mutex.go:72:6: can inline (*Mutex).Lock with cost 69 as: method(*Mutex) func() { if "sync/atomic".CompareAndSwapInt32(&m.state, 0, mutexLocked) { if race.Enabled { }; return }; m.lockSlow() }
通过把函数分割成一个简单的不能再被分割的外部函数，和（如果没走到外部函数就走到的）一个处理慢速路径的复杂的内部函数，Carlo 组合了栈中函数内联和[编译器对基础操作的支持][9]，减少了非竞争锁 14% 的开销。之后他在 sync.RWMutex.Unlock() 重复这个技巧，节省了另外 9% 的开销。
相关文章：
- [Go 中的内联优化][15]
- [goroutine 的栈为什么会无限增长？][16]
- [栈追踪和 errors 包][17]
- [零值是什么，为什么它很有用？][18]
via: https://dave.cheney.net/2020/05/02/mid-stack-inlining-in-go
作者：Dave Cheney 选题：lujun9972 译者：lxbwolf 校对：wxy
[4]: tmp.FyRthF1bbF#easy-footnote-bottom-2-4076 (Keep in mind that the compiler authors warn that “Additional levels of inlining (beyond -l) may be buggy and are not supported”. Caveat emptor.)
[5]: https://docs.google.com/presentation/d/1Wcblp3jpfeKwA0Y4FOmj63PW52M_qmNqlQkNaLj0P5o/edit#slide=id.p
[6]: tmp.FyRthF1bbF#easy-footnote-bottom-3-4076 (The compiler is powerful enough that it can inline complex functions like strconv.ParseInt. As a experiment, try removing the //go:noinline annotation and observe the result with -gcflags=-m=2.)
[7]: https://go-review.googlesource.com/c/go/+/148959
[8]: tmp.FyRthF1bbF#easy-footnote-bottom-4-4076 (The expression race.Enable is a constant controlled by the -race flag passed to the go tool. It is false for normal builds which allows the compiler to elide those code paths entirely.)
[9]: https://dave.cheney.net/2019/08/20/go-compiler-intrinsics
[10]: tmp.FyRthF1bbF#easy-footnote-1-4076
[11]: be08e10b3b/src/cmd/compile/internal/gc/inl.go (L11)
[12]: tmp.FyRthF1bbF#easy-footnote-2-4076
[13]: tmp.FyRthF1bbF#easy-footnote-3-4076
[14]: tmp.FyRthF1bbF#easy-footnote-4-4076
[15]: https://dave.cheney.net/2020/04/25/inlining-optimisations-in-go (Inlining optimisations in Go)
[16]: https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite (Why is a Goroutine’s stack infinite ?)
[17]: https://dave.cheney.net/2016/06/12/stack-traces-and-the-errors-package (Stack traces and the errors package)
[18]: https://dave.cheney.net/2013/01/19/what-is-the-zero-value-and-why-is-it-useful (What is the zero value, and why is it useful?)