4 ms·
Go is not nearly as slow as you're making it seem to be, I dont know what the authors implementation was doing, but this code runs at a rate of 7GiB/s/core on m
by richieartoul 6y ago
Go is not nearly as slow as you're making it seem to be, I dont know what the authors implementation was doing, but this code runs at a rate of 7GiB/s/core on my laptop
func BenchmarkFindMax(b *testing.B) {
ints := make([]int32, 13*1000*100)
for i := 0; i < len(ints); i++ {
ints[i] = rand.Int31()
}
for i := 0; i < b.N; i++ {
max := int32(math.MinInt32)
for _, x := range ints {
if x > max {
max = x
}
}
dontOptimize = max
}
b.ReportMetric(float64(b.N*len(ints)*4/1000/1000/1000),
"GiB/s")
}
goos: darwin
goarch: amd64
BenchmarkFindMax-8 1530 678975 ns/op 7.00 GiB/s
EDIT: Actually my original code was reporting the metric wrong, it should have been:
b.ReportMetric(float64(b.N)float64(len(ints))4/1000/1000/1000, "GiB/s")
which leads to 9-10GiB/s on my laptop
- Jtsummers 6y agoThe author was running on a 2013 laptop, which had smaller cache and slower RAM than what you're probably using. Benchmark comparisons are useless without running on equivalent hardware.
- richieartoul 6y agoHe was probably scanning elements that were larger than int32s, even on a 2013 this code would run at Gib/s. The point of my benchmark was that C is nowhere near 50-100x faster than Go and that the user I'm replying to shouldn't make unsubstantiated claims like that.
- formerly_proven 6y agoMy claim that the trivial C code is 100x faster than the number from the article is a) well substantiated b) all there is c) perfectly clear.
- formerly_proven 6y ago> Go is not nearly as slow as you're making it seem to be It's rather obvious I compared against the quoted figure.