在这个数组访问微基准测试中（相对于 GCC），Go 的性能损失了 4 倍，是什么原因造成的？

在这个数组访问微基准测试中（相对于GCC），Go的性能损失了4倍，是什么原因造成的？这个问题涉及到Go语言的运行时机制和编译器优化等多个方面。首先，Go语言在数组访问时使用了边界检查机制，即在每次访问数组元素时都会进行边界检查，这会带来一定的性能损失。其次，Go语言的编译器在优化方面相对较弱，无法对数组访问进行很好的优化。此外，Go语言的垃圾回收机制也会对性能造成一定的影响。综上所述，这些因素共同导致了Go语言在数组访问微基准测试中性能损失了4倍的情况。,我编写这个微基准测试是为了更好地了解 go 的性能特征，以便我能够在何时使用它方面做出明智的选择。,从性能开销的角度来看，我认为这将是 go 的理想场景：,循环内没有分配/释放
数组访问显然在边界内（可以删除边界检查）,尽管如此，我发现相对于 amd64 上的 gcc -o3 速度有 4 倍的差异。这是为什么？,（使用shell计时。每次需要几秒钟，因此启动可以忽略不计）,c 版本：,更新：,按照建议使用 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 编译器是否本质上无法进行自动向量化，或者是否只是这个特定的程序由于某种原因导致它出错，但这似乎是根本原因.,