在这个数组访问微基准测试中(相对于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 = %d\n", n, r, sum)
}
c 版本:
#include
#include
int main() {
printf("started\n");
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 = %d\n", 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 编译器是否本质上无法进行自动向量化,或者是否只是这个特定的程序由于某种原因导致它出错,但这似乎是根本原因.
以上就是在这个数组访问微基准测试中(相对于 GCC),Go 的性能损失了 4 倍,是什么原因造成的?的详细内容,更多请关注编程网其它相关文章!