cmd/compile: CMOV instruction slower than branch

[PeterRK]

What version of Go are you using (go version)?

go1.11beta1 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rk/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/rk/GoSpace/Projects"
GOPROXY=""
GORACE=""
GOROOT="/home/rk/GoSpace/GO"
GOTMPDIR=""
GOTOOLDIR="/home/rk/GoSpace/GO/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build473408654=/tmp/go-build -gno-record-gcc-switches"
VGOMODROOT=""

What did you do?

I built the code below with go 1.10 and go 1.11.
https://play.golang.org/p/22MEbiXFpzo

What did you expect to see?

The binary built by go 1.11 is as fast as that built by go 1.10.

What did you see instead?

The binary built by go 1.11 is incredibly slower than that built by go 1.10.

Go 1.11 compiles the function "down" to assembly like this:

    MOVQ pos+32(SP), AX
    MOVQ list+8(SP), CX
    MOVL (CX)(AX*4), DX
    LEAQ 1(AX)(AX*1), BX
    MOVQ list+16(SP), SI
    DECQ SI
    JMP L42
L28:
    MOVL DI, (CX)(AX*4)
    LEAQ 1(BX)(BX*1), DI
    MOVQ BX, AX
    MOVQ DI, BX
L42:
    CMPQ BX, SI
    JGE L73
    MOVL 4(CX)(BX*4), DI
    LEAQ 1(BX), R8
    MOVL (CX)(BX*4), R9
    CMPL DI, R9
    CMOVQHI R8, BX
//  JHI L100
L66:
    MOVL (CX)(BX*4), DI
    CMPL DX, DI
    JCS L28
L73:    
    CMPQ BX, SI
    JNE L97
    MOVL (CX)(BX*4), SI
    CMPL DX, SI
    JCC L92
    MOVL SI, (CX)(AX*4)
L88:    
    MOVL DX, (CX)(BX*4)
    RET
L92:
    MOVQ AX, BX
    JMP L88
L97:    
    MOVQ AX, BX
    JMP L88
L100:
//  MOVQ R8, BX
//  JMP L66

If replacing the CMOV instruction with a branch, it can be 80% faster.

[josharian]

cc @TocarIP @rasky

[ianlancetaylor]

@PeterRK What processor are you running?

[ulikunitz]

I've microbenchmarked the code here on my Core i7-4510U between go1.10.3 and go1.11beta1 and benchstat returns the following:

name        old time/op  new time/op  delta
HeapSort-4  52.3µs ± 3%  39.8µs ± 2%  -23.89%  (p=0.000 n=10+10)

This would indicate there is actually a 24% speed improvement between go1.10.3 and go1.11beta1. I can confirm that the difference is the use of the CMOV instruction in the down function.

Here is the Benchmark function:

const size = 1000

func makeSlice(size int) []uint32 {
	a := make([]uint32, size)
	for i := range a {
		a[i] = rand.Uint32()
	}
	return a
}

func BenchmarkHeapSort(b *testing.B) {
	a := makeSlice(size)
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		HeapSort(a)
	}
}

[ulikunitz]

For larger arrrays (size = 1000000) go1.11beta1 is getting slower.

name        old time/op  new time/op  delta
HeapSort-4  75.9ms ± 2%  86.0ms ± 1%  +13.29%  (p=0.000 n=10+9)

[PeterRK]

I have tried i7-8700 & i5-7500.
Binary built by go 1.11 have less cache miss and less branch miss，but 80% more execution time.
I think it can not be said 5x slower. @josharian

test with 20M list:

test code:
https://play.golang.org/p/h8mmeue7v1R

[ALTree]

Here's an auto-contained benchmark that can be directly copy-pasted in a _test.go file for whoever wants to try it: https://play.golang.org/p/4VwOmmmX069

Here's the result with count=5 on my machine for sizes from 100 to 1000000 (old is 1.10, new is tip):

name                old time/op  new time/op  delta
HeapSort/100-4      1.79µs ± 3%  2.45µs ± 2%  +36.43%  (p=0.008 n=5+5)
HeapSort/1000-4     52.1µs ± 3%  39.2µs ± 0%  -24.73%  (p=0.016 n=5+4)
HeapSort/10000-4     607µs ± 7%   540µs ± 0%  -11.08%  (p=0.016 n=5+4)
HeapSort/100000-4   6.55ms ± 1%  7.09ms ± 2%   +8.20%  (p=0.008 n=5+5)
HeapSort/1000000-4  75.0ms ± 0%  85.7ms ± 2%  +14.27%  (p=0.008 n=5+5)

On a i7-4510U cpu.

[agnivade]

Thanks @ALTree for the self-contained benchmark. I was very interested in the CMOV instruction so I gave it a shot too. I see different results in my CPU (Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz).

name                old time/op  new time/op  delta
HeapSort/100-4      2.03µs ± 1%  2.43µs ± 1%  +19.92%  (p=0.008 n=5+5)
HeapSort/1000-4     60.0µs ± 0%  38.8µs ± 1%  -35.29%  (p=0.008 n=5+5)
HeapSort/10000-4     681µs ± 1%   529µs ± 0%  -22.26%  (p=0.008 n=5+5)
HeapSort/100000-4   7.61ms ± 1%  6.78ms ± 1%  -10.93%  (p=0.008 n=5+5)
HeapSort/1000000-4  87.8ms ± 2%  85.9ms ± 1%   -2.19%  (p=0.008 n=5+5)

Things look more or less same, except the last row, where I see perf improvement rather than a slowdown. For the 100 case, I see a slowdown too.

Sorry if this just adds noise. I only posted because I saw different results in the last case.

[ulikunitz]

This might be related to #25298 as pointed out by @randall77 on golang-dev. See the discussion branch predictor versus CMOV.

[ulikunitz]

The benchmark code has the problem that after the first iteration slice a is already sorted.
Here is a fix: https://play.golang.org/p/b_-IC1OSEWq

The new benchstat looks like this:

name                 old time/op  new time/op  delta
HeapSort/100-4       5.59µs ± 3%  3.74µs ± 4%  -33.14%  (p=0.000 n=10+10)
HeapSort/1000-4      75.0µs ± 0%  50.1µs ± 1%  -33.26%   (p=0.000 n=7+10)
HeapSort/10000-4      879µs ± 2%   610µs ± 0%  -30.61%   (p=0.000 n=10+8)
HeapSort/100000-4    10.8ms ± 0%   8.8ms ± 1%  -18.80%   (p=0.000 n=8+10)
HeapSort/1000000-4    141ms ± 1%   146ms ± 1%   +3.62%  (p=0.000 n=10+10)
HeapSort/10000000-4   2.54s ± 3%   4.23s ± 6%  +66.86%  (p=0.000 n=10+10)

Apparently branch prediction and speculative execution (loads) are faster than CMOV if the slice size exceeds the level 2 cache.