边界检查消除
Go是一个内存安全的语言。在数组和切片的索引和子切片操作中,Go运行时将检查操作中使用的下标是否越界。 如果下标越界,一个恐慌将产生,以防止这样的操作破坏内存安全。这样的检查称为边界检查。 边界检查使得我们的代码能够安全地运行;但是另一方面,也使得我们的代码运行效率略微降低。
从Go官方工具链1.7开始,官方标准编译器使用了一个新的基于SSA(single-assignment form,静态单赋值形式)的后端。 SSA使得Go编译器可以有效利用诸如BCE(bounds check elimination,边界检查消除)和(common subexpression elimination,公共子表达式消除)等优化。 BCE可以避免很多不必要的边界检查,CSE可以避免很多重复表达式的计算,从而使得编译器编译出的程序执行效率更高。有时候这些优化的效果非常明显。
本文将展示一些例子来解释边界检查消除在官方标准编译器1.7+中的表现。
对于Go官方工具链1.7+,我们可以使用编译器选项来列出哪些代码行仍然需要边界检查。
$ go run -gcflags="-d=ssa/check_bce/debug=1" example1.go
./example1.go:5: Found IsInBounds
./example1.go:6: Found IsInBounds
./example1.go:7: Found IsInBounds
./example1.go:11: Found IsInBounds
./example1.go:17: Found IsInBounds
我们可以看到函数f2
中的第12行和第13行不再需要边界检查了,因为第11行的检查确保了第12行和第13行中使用的下标肯定不会越界。
但是,函数f1
中的三行仍然都需要边界检查,因为第5行中的边界检查不能保证第6行和第7行中的下标没有越界,第6行中的边界检查也不能保证第第7行中的下标没有越界。
编译器也正确地认为函数f4
中的唯一一行(第22行)是无需边界检查的。
例子2
// example2.go
package main
func f5(s []int) {
for i := range s {
_ = s[i]
_ = s[i:len(s)]
_ = s[:i+1]
}
}
func f6(s []int) {
for i := 0; i < len(s); i++ {
_ = s[i]
_ = s[i:len(s)]
_ = s[:i+1]
}
}
func f7(s []int) {
for i := len(s) - 1; i >= 0; i-- {
_ = s[i]
_ = s[i:len(s)]
}
func f8(s []int, index int) {
_ = s[index]
_ = s[index:len(s)]
}
}
func f9(s []int) {
if len(s) > 2 {
_, _, _ = s[0], s[1], s[2]
}
}
func main() {}
酷!官方标准编译器消除了上例程序中的所有边界检查。
注意:在Go官方工具链1.11之前,官方标准编译器没有足够聪明到认为第22行是不需要边界检查的。
// example3.go
package main
import "math/rand"
func fa() {
s := []int{0, 1, 2, 3, 4, 5, 6}
index := rand.Intn(7)
_ = s[:index] // 第9行: 需要边界检查
_ = s[index:] // 第10行: 边界检查消除了!
}
func fb(s []int, index int) {
_ = s[:index] // 第14行: 需要边界检查
_ = s[index:] // 第15行: 需要边界检查(不够智能?)
}
func fc() {
s := []int{0, 1, 2, 3, 4, 5, 6}
s = s[:4]
index := rand.Intn(7)
_ = s[:index] // 第22行: 需要边界检查
}
func main() {}
$ go run -gcflags="-d=ssa/check_bce/debug=1" example3.go
./example3.go:14: Found IsSliceInBounds
./example3.go:15: Found IsSliceInBounds
./example3.go:22: Found IsSliceInBounds
./example3.go:23: Found IsSliceInBounds
噢,仍然有这么多的边界检查!
但是等等,为什么官方标准编译器认为第10行不需要边界检查,却认为第15和第23行仍旧需要边界检查呢? 是标准编译器不够智能吗?
事实上,这里标准编译器做得对!为什么呢? 原因是一个子切片表达式中的起始下标可能会大于基础切片的长度。 让我们先看一个简单的使用了子切片的例子:
标准编译器成功地检测到在函数fa
中len(s)
和cap(s)
是相等的。干得漂亮!Go语言开发团队!
例子4
// example4.go
package main
import "math/rand"
func fb2(s []int, index int) {
_ = s[index:] // 第7行: 需要边界检查
_ = s[:index] // 第8行: 边界检查消除了!
}
func fc2() {
s := []int{0, 1, 2, 3, 4, 5, 6}
s = s[:4]
index := rand.Intn(7)
_ = s[index:] // 第15行: 需要边界检查
_ = s[:index] // 第16行: 边界检查消除了!
}
func main() {}
$ go run -gcflags="-d=ssa/check_bce/debug=1" example4.go
./example4.go:7:7: Found IsSliceInBounds
./example4.go:15:7: Found IsSliceInBounds
在此例子中,标准编译器成功推断出:
- 在函数
fb2
中,如果第7行是安全的,则第8行是无需边界检查的; - 在函数
fc2
中,如果第15行是安全的,则第16行是无需边界检查的。
注意:Go官方工具链1.9之前中的标准编译器没有出推断出第8行不需要边界检查。
当前版本的标准编译器并非足够智能到可以消除到一切应该消除的边界检查。 有时候,我们需要给标准编译器一些暗示来帮助标准编译器将这些不必要的边界检查消除掉。
$ go run -gcflags="-d=ssa/check_bce/debug=1" example5.go
./example5.go:7: Found IsInBounds
总结
本文上面列出的例子并没有涵盖标准编译器支持的所有边界检查消除的情形。本文列出的仅仅是一些常见的情形。
尽管标准编译器中的边界检查消除特性依然不是100%完美,但是对很多常见的情形,它确实很有效。 自从标准编译器支持此特性以来,在每个版本更新中,此特性都在不断地改进增强。 无需质疑,在以后的版本中,标准编译器会更加得智能,以至于上面第5个例子中提供给编译器的暗示有可能将变得不再必要。 谢谢Go语言开发团队出色的工作!