strange benchmark result: inline is slower than function calls

[T L]

package main

import (
    "testing"
)

const N = 4096
type T int64
var a [N]T

var globalSum T

func sumByLoopArray_a(p *[N]T) T {
    var sum T
    for i := 0; i < len(p); i++ {
        sum += T(p[i])
    }
    return sum
}

func sumByLoopArray_b(p *[N]T) T {
    var sum T
    for i := 0; i < len(*p); i++ {
        sum += T((*p)[i])
    }
    return sum
}

//============================================

func Benchmark_LoopArray_0a(b *testing.B) {
    for i := 0; i < b.N; i++ {
        var sum T
        for i := 0; i < len(a); i++ {
            sum += T(a[i])
        }
        globalSum = sum
    }
}

func Benchmark_LoopArray_0b(b *testing.B) {
    for i := 0; i < b.N; i++ {
        var sum T
        p := &a
        for i := 0; i < len(p); i++ {
            sum += T(p[i])
        }
        globalSum = sum
    }
}

func Benchmark_LoopArray_1a(b *testing.B) {
    for i := 0; i < b.N; i++ {
        globalSum = sumByLoopArray_a(&a)
    }
}

func Benchmark_LoopArray_1b(b *testing.B) {
    for i := 0; i < b.N; i++ {
        globalSum = sumByLoopArray_b(&a)
    }
}

/* output:

$ go test . -bench=.
Benchmark_LoopArray_0a-4         300000          5248 ns/op
Benchmark_LoopArray_0b-4         300000          5240 ns/op
Benchmark_LoopArray_1a-4         500000          3942 ns/op
Benchmark_LoopArray_1b-4         300000          3936 ns/op
*/

why?

[Ian Lance Taylor]

Benchmarking is hard.

If you really want to know why, you will have to look at the generated
assembly code. There are likely to be differences there. For
example, your 1a and 1b loops use a pointer to a global variable, but
your 0a and 0b loops use a global variable directly. In general
references through a pointer are more efficient than references to a
named global variable. I don't know if that is the difference here,
but it could be.

It could also be something difficult to control for, like loop alignment.

Ian

[T L]

Thanks, Ian.

Yes, for 0a, it is reasonable that the reference to a global array really matters.
But for 0b, the p pointer is a local variable, so it shouldn't be much different with 1a and 1b.

If I create a local array for 0a and 0b, then their results will become much better, but still a little slower than 1a and 1b.

I write a small program and use "-gcflags -S" to check the assembly output:

package main

const N = 4096
type T int64
   

func fffffff (p *[N]T) T {

    var sum T
    for i := 0; i < len(p); i++ {
        sum += T(p[i])
    }
    return sum
}

func ggggggg () T {
    var a [N]T

    var sum T
    for i := 0; i < len(a); i++ {
        sum += T(a[i])
    }

    return sum   
}

func main() {
}

The assembly code for fffffff and ggggggg are much different.
I am not familiar with go assembly now, so I can't make a conclusion why ggggggg is slower.

[peterGo]

T L,

First, keep things simple. Delete the main function; it's an irrelevant complication. Use shorter function names. Start simply and build one feature at a time. Function gggg is exactly like ffff except that variables are substituted for the function parameter. Function hhhh is exactly like gggg except that the parameter variables are local variables not file variables. Function iiii is exactly like hhhh except that variables are used directly instead of indirectly through pointers.

For example: https://play.golang.org/p/TsPPKv14Va

It shouldn't be too hard to see what is happening and why function ffff is fast (registers versus memory in loop):

package tl

const N = 4096

type T int64

func ffff(p *[N]T) T {

    var sum T
    for i := 0; i < len(p); i++ {
        sum += T(p[i])
    }
    return sum
}

$ go tool compile -S ffff.go

"".ffff t=1 size=49 args=0x10 locals=0x0
    0x0000 00000 (ffff.go:7)    TEXT    "".ffff(SB), $0-16
    0x0000 00000 (ffff.go:7)    FUNCDATA    $0, gclocals·aef1f7ba6e2630c93a51843d99f5a28a(SB)
    0x0000 00000 (ffff.go:7)    FUNCDATA    $1, gclocals·33cdeccccebe80329f1fdbee7f5874cb(SB)
    0x0000 00000 (ffff.go:9)    MOVQ    "".p+8(FP), AX
    0x0005 00005 (ffff.go:9)    MOVQ    $0, CX
    0x0007 00007 (ffff.go:7)    MOVQ    $0, DX
    0x0009 00009 (ffff.go:9)    CMPQ    CX, $4096
    0x0010 00016 (ffff.go:9)    JGE    $0, 43
    0x0012 00018 (ffff.go:10)    TESTB    AL, (AX)
    0x0014 00020 (ffff.go:9)    LEAQ    1(CX), BX
    0x0018 00024 (ffff.go:10)    MOVQ    (AX)(CX*8), SI
    0x001c 00028 (ffff.go:10)    ADDQ    SI, DX
    0x001f 00031 (ffff.go:9)    MOVQ    BX, CX
    0x0022 00034 (ffff.go:9)    CMPQ    CX, $4096
    0x0029 00041 (ffff.go:9)    JLT    $0, 18
    0x002b 00043 (ffff.go:12)    MOVQ    DX, "".~r1+16(FP)
    0x0030 00048 (ffff.go:12)    RET
    0x0000 48 8b 44 24 08 31 c9 31 d2 48 81 f9 00 10 00 00  H.D$.1.1.H......
    0x0010 7d 19 84 00 48 8d 59 01 48 8b 34 c8 48 01 f2 48  }...H.Y.H.4.H..H
    0x0020 89 d9 48 81 f9 00 10 00 00 7c e7 48 89 54 24 10  ..H......|.H.T$.
    0x0030 c3                                               .
gclocals·33cdeccccebe80329f1fdbee7f5874cb t=8 dupok size=8
    0x0000 01 00 00 00 00 00 00 00                          ........
gclocals·aef1f7ba6e2630c93a51843d99f5a28a t=8 dupok size=9
    0x0000 01 00 00 00 02 00 00 00 01                       .........

$ go tool objdump ffff.o

TEXT %22%22.ffff(SB) ffff.go
    ffff.go:9    0x325    488b442408    MOVQ 0x8(SP), AX   
    ffff.go:9    0x32a    31c9        XORL CX, CX       
    ffff.go:7    0x32c    31d2        XORL DX, DX       
    ffff.go:9    0x32e    4881f900100000    CMPQ $0x1000, CX   
    ffff.go:9    0x335    7d19        JGE 0x350       
    ffff.go:10    0x337    8400        TESTB AL, 0(AX)       
    ffff.go:9    0x339    488d5901    LEAQ 0x1(CX), BX   
    ffff.go:10    0x33d    488b34c8    MOVQ 0(AX)(CX*8), SI   
    ffff.go:10    0x341    4801f2        ADDQ SI, DX       
    ffff.go:9    0x344    4889d9        MOVQ BX, CX       
    ffff.go:9    0x347    4881f900100000    CMPQ $0x1000, CX   
    ffff.go:9    0x34e    7ce7        JL 0x337       
    ffff.go:12    0x350    4889542410    MOVQ DX, 0x10(SP)   
    ffff.go:12    0x355    c3        RET           

References:

Names
https://research.swtch.com/names

A Quick Guide to Go's Assembler
https://golang.org/doc/asm

GopherCon 2016: Rob Pike - The Design of the Go Assembler
https://www.youtube.com/watch?v=KINIAgRpkDA

Command compile
https://golang.org/cmd/compile/

Command nm
https://golang.org/cmd/nm/

Command objdump
https://golang.org/cmd/objdump/

Command asm
https://golang.org/cmd/asm/

A Foray Into Go Assembly Programming
https://blog.sgmansfield.com/2017/04/a-foray-into-go-assembly-programming/

Intel® 64 and IA-32 Architectures Software Developer Manuals
https://software.intel.com/en-us/articles/intel-sdm

Peter

[peterGo]

T L,

ffff.go : https://play.golang.org/p/GPGO7YnLxh

Peter