go - 为什么 Go 对数组的范围循环有运行时开销？

Question

我希望对数组元素进行范围迭代不会带来任何运行时开销，但它似乎比原始数组访问慢 8 倍:

func BenchmarkSumRange(b *testing.B) {
    nums := [5]int{0, 1, 2, 3, 4}

    for n := 0; n < b.N; n++ {
        sum := 0
        for i, _ := range nums {
            sum += nums[i]
        }
    }
}

func BenchmarkSumManual(b *testing.B) {
    nums := [5]int{0, 1, 2, 3, 4}

    for n := 0; n < b.N; n++ {
        sum := 0
        sum += nums[0]
        sum += nums[1]
        sum += nums[2]
        sum += nums[3]
        sum += nums[4]
    }
}

基准输出:

BenchmarkSumRange-8     1000000000           2.18 ns/op
BenchmarkSumManual-8    2000000000           0.28 ns/op

如果它是一个长度在编译时未知的 slice 而不是一个数组，这可能是有意义的，在这种情况下，运行时代码必须涉及一个带有边界检查的循环。但对于在编译时已知大小的数组，考虑到开销很大，编译器可以将范围迭代替换为手动访问。

注意:我还尝试了更惯用的元素范围循环:

sum := 0
for _, el := range nums {
    sum += el
}

这甚至更慢(4 ns/op)。

附带问题:这种开销是否存在于其他语言(如 Rust)中？这似乎违反了零成本抽象，如果没有快速的替代方法来手动写出数组访问，那么在对性能敏感的上下文中相当烦人。

Answer 1

首先，观察 for 循环中实际发生了什么:

for i := range sums {
    // your code goes here
}

在每次迭代中，您都会递增 i，这显然是一种开销。

对于您可能会问的每次迭代，为什么编译器不将其替换为原始访问？这是完全不合理的，因为您的二进制文件大小会急剧增加。

考虑在正常范围内循环。它将值存储在另一个变量中，然后在其他地方访问它。

实际上 go 的 for 循环是许多语言中最快的，我不确定它的确切原因，但您可以在此 post 中获得更多信息。 .

我检查了 java、python 和 rust 等其他几种语言的 for 循环性能，它们都比 go 的实现慢。