在这个数组访问微基准测试中（相对于GCC），Go的性能损失了4倍，是什么原因造成的？这个问题涉及到Go语言的运行时机制和编译器优化等多个方面。首先，Go语言在数组访问时使用了边界检查机制，即在每次访问数组元素时都会进行边界检查，这会带来一定的性能损失。其次，Go语言的编译器在优化方面相对较弱，无法对数组访问进行很好的优化。此外，Go语言的垃圾回收机制也会对性能造成一定的影响。综上所述，这些因素共同导致了Go语言在数组访问微基准测试中性能损失了4倍的情况。

问题内容

我编写这个微基准测试是为了更好地了解 go 的性能特征，以便我能够在何时使用它方面做出明智的选择。

从性能开销的角度来看，我认为这将是 go 的理想场景：

• 循环内没有分配/释放
• 数组访问显然在边界内（可以删除边界检查）

尽管如此，我发现相对于 amd64 上的 gcc -o3 速度有 4 倍的差异。这是为什么？

（使用shell计时。每次需要几秒钟，因此启动可以忽略不计）

package main

import "fmt"

func main() {
    fmt.println("started");

    var n int32 = 1024 * 32

    a := make([]int32, n, n)
    b := make([]int32, n, n)

    var it, i, j int32

    for i = 0; i < n; i++ {
        a[i] =  i
        b[i] = -i
    }

    var r int32 = 10
    var sum int32 = 0

    for it = 0; it < r; it++ {
        for i = 0; i < n; i++ {
            for j = 0; j < n; j++ {
                sum += (a[i] + b[j]) * (it + 1)
            }
        }
    }
    fmt.printf("n = %d, r = %d, sum = %dn", n, r, sum)
}

c 版本：

#include <stdio.h>
#include <stdlib.h>


int main() {
    printf("startedn");

    int32_t n = 1024 * 32;

    int32_t* a = malloc(sizeof(int32_t) * n);
    int32_t* b = malloc(sizeof(int32_t) * n);

    for(int32_t i = 0; i < n; ++i) {
        a[i] =  i;
        b[i] = -i;
    }

    int32_t r = 10;
    int32_t sum = 0;

    for(int32_t it = 0; it < r; ++it) {
        for(int32_t i = 0; i < n; ++i) {
            for(int32_t j = 0; j < n; ++j) {
                sum += (a[i] + b[j]) * (it + 1);
            }
        }
    }
    printf("n = %d, r = %d, sum = %dn", n, r, sum);

    free(a);
    free(b);
}

更新：

• 按照建议使用 range，可以将 go 速度提高 2 倍。
• 另一方面，在我的测试中，-march=native 将 c 速度提高了 2 倍。 （并且-mno-sse给出编译错误，显然与-o3不兼容）
• gccgo 在这里看起来与 gcc 相当（并且不需要 range）

解决方法

看看 C 程序与 Go 程序的汇编程序输出，至少在我使用的 Go 和 GCC 版本（分别为 1.19.6 和 12.2.0）上，最直接和明显的区别是 GCC自动向量化 C 程序，而 Go 编译器似乎无法做到这一点。

这也很好地解释了为什么您会看到性能提高了四倍，因为 GCC 在不针对特定架构时使用 SSE 而不是 AVX，这意味着 32 位标量指令宽度是四倍运营。事实上，添加 -march=native 为我带来了两倍的性能提升，因为这使得 GCC 在我的 CPU 上输出 AVX 代码。

我对 Go 还不够熟悉，无法告诉你 Go 编译器是否本质上无法进行自动向量化，或者是否只是这个特定的程序由于某种原因导致它出错，但这似乎是根本原因.