-
Notifications
You must be signed in to change notification settings - Fork 18.1k
cmd/compile: strange performance difference between two implementations #49785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The inner loop in To fix this I think we'd have to promote |
The problem also exists for reads: package pointers
import "testing"
const N = 1000
var a [N]int
var r int
//go:noinline
func g1(a *[N]int) int {
var r int
_ = *a
for i := range a {
r += a[i]
}
return r
}
//go:noinline
func g0(a *[N]int) int {
var r int
for i := range a {
r += a[i]
}
return r
}
func Benchmark_g1(b *testing.B) {
for i := 0; i < b.N; i++ { r = g1(&a) }
}
func Benchmark_g0(b *testing.B) {
for i := 0; i < b.N; i++ { r = g0(&a) }
}
|
It looks the read case is different from the write case. The compiler generates one more instruction |
I think clang does this for loops in c already. If it can tell that the thing being incremented in the loop is not otherwise impacting the behavior of the loop, it will use a local variable and then just assign the result of aggregation in the loop to the original target (in this case t.x). See discussion on: bddicken/languages#44 (comment) |
Uh oh!
There was an error while loading. Please reload this page.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
What did you expect to see?
Similar performances.
What did you see instead?
I checked the generated assembly instructions. Yes, they are different, but the complexities are similar. So it is some strange that the performance difference is so large.
The text was updated successfully, but these errors were encountered: