I think this is a consequence of variables being sent to a channel effectively having their address taken, disabling register allocation for them.
We should fix this. Probably a vestige of old bits of the compiler.

cc @golang/compiler

The following hack of unnamed enclosed function also works, and is 4 times faster than original sumpar1 (copied below):

// 4 times faster version of sumpar1:
func sumpar1(numiter int, c chan<- float64) {
	sum := func() float64 {
		sum := 0.0
		for i := 0; i < numiter; i++ {
			sum += 1.0
		}
		return sum
	}()
	c <- sum
}

// original sumpar1:
func sumpar1(numiter int, c chan<- float64) {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	c <- sum
}

Also, I tried some more meaningful logic (instead of adding a constant 1.0), like accumulating a billion preloaded random float64 values from memory, and the observed speed difference is similar. Of course the speedup will go down with increased logic per iteration, but tight loops doing one or two arithmetic ops are out there.

I think this is a consequence of variables being sent to a channel effectively having their address taken, disabling register allocation for them.

I've been thinking for a little bit that maybe we shouldn't mark variables addrtaken due to runtime calls at all, at least for SSA-able types. Instead, if we need to pass a value by address to the runtime and it's not already addrtaken, we allocate a temporary variable to spill into it just for the runtime call.

And this following simple trick (below) of creating a new (and useless) variable sendsum works too... Similar behavior is seen where loop aggregates like sum are pre-allocated in memory, for instance if sum were a member of a struct on which a method like subpar was called. @mdempsky the change you have in mind, will it optimize all of the cases 1., 2., 3., below? Is there a guiding document for producing performant code in go?

1. Create a useless variable sendsum, first assign sum to it, and then send sendsum over channel:

// 4 times faster version of sumpar1 (by creating sendsum):
func sumpar1(in []float64, start int, end int, c chan<- float64) {
	sum := 0.0
	for i := start; i < end; i++ {
		sum += in[i]
	}
	sendsum := sum
	c <- sendsum
}

// original sumpar1:
func sumpar1(numiter int, c chan<- float64) {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	c <- sum
}

2. Example without channel (method and struct member), and normal function returns:

// 4 times faster aggregation
func (sp *special) sumseq(in []float64, start int, end int) float64 {
	sum := 0.0
	for i := start; i < end; i++ {
		sum += in[i]
	}
	sp.sum = sum
	return sp.sum
}

// compared to the following:
func (sp *special) sumseq(in []float64, start int, end int) float64 {
	sp.sum = 0.0
	for i := start; i < end; i++ {
		sp.sum += in[i]
	}
	return sp.sum
}

3. Lastly, go compiler does not optimize pointer references within loop:

// this runs 4 times slower than the original version below
func sumseq(numiter int) float64 {
	sum := new(float64)
	for i := 0; i < numiter; i++ {
		*sum += 1.0
	}
	return *sum
}

// original version of sumseq
func sumseq(numiter int) float64 {
	sum := 0.0
	for i := 0; i < numiter; i++ {
		sum += 1.0
	}
	return sum
}

@amanvm No, the change I suggested would only help the first case.

The second and third cases require pointer alias analysis, which we don't currently do much of. E.g., in case two, it's possible through the use of package unsafe for sp.sum and in[start:end] to alias.

Case 3 seems like it should be possible to optimize if we had a pass that looked for memory-resident variables that could be lifted to SSA form.

Change https://go.dev/cl/541715 mentions this issue: cmd/compile/internal/walk: copy SSA-able variables

@mdempsky Thanks for the fix! Does the patch fix just case 1? If yes, do you think it is a good idea to open other issues for case 2 and/or 3?

@0-issue Correct, only the first issue is fixed.

Filing issues for the other two is fine. I'd suggest filing them as two separate issues, because they're going to need different fixes. Please link back to this issue if you do.

Thanks.

@mdempsky I saw a release (1.21.5) happen since this fix, but the behavior is the same. Did this go in that release, if not which release would have this fix? Thanks!

This change wasn't backported, it'll only be available in the next minor release (1.22.0)

It's in now, and works great! Thanks @mdempsky