Почему for-range ведет себя по-разному в зависимости от размера структуры среза?

Question

Я играл с этим кодом

main_var. go

package main

func main() {
    const size = 1000000

    slice := make([]SomeStruct, size)
    for _, s := range slice { // line 7
        _ = s
    }

}

type_small. go

package main

type SomeStruct struct {
    ID0 int64
    ID1 int64
    ID2 int64
    ID3 int64
    ID4 int64
    ID5 int64
    ID6 int64
    ID7 int64
    ID8 int64
}

Я заметил, что если я добавлю еще 64 бита int64 ID9 (всего 10 * 8 байт = 80 байт) для структуры, for-l oop становится медленнее.

Если я сравнил сборку, он добавил инструкцию для копирования element

// with 9 int64 (72 bytes)
    0x001d 00029 (main_var.go:6)    LEAQ    type."".SomeStruct(SB), AX
    0x0024 00036 (main_var.go:6)    MOVQ    AX, (SP)
    0x0028 00040 (main_var.go:6)    MOVQ    $1000000, 8(SP)
    0x0031 00049 (main_var.go:6)    MOVQ    $1000000, 16(SP)
    0x003a 00058 (main_var.go:6)    CALL    runtime.makeslice(SB)
    0x003f 00063 (main_var.go:6)    XORL    AX, AX
    0x0041 00065 (main_var.go:7)    INCQ    AX
    0x0044 00068 (main_var.go:7)    CMPQ    AX, $1000000
    0x004a 00074 (main_var.go:7)    JLT    65
    0x004c 00076 (main_var.go:7)    MOVQ    32(SP), BP
    0x0051 00081 (main_var.go:7)    ADDQ    $40, SP
    0x0055 00085 (main_var.go:7)    RET
    0x0056 00086 (main_var.go:7)    NOP
    0x0056 00086 (main_var.go:3)    CALL    runtime.morestack_noctxt(SB)
    0x005b 00091 (main_var.go:3)    JMP    0

// with 10 int64 (80 bytes), it added DUFFCOPY instruction
    0x001d 00029 (main_var.go:6)    LEAQ    type."".SomeStruct(SB), AX
    0x0024 00036 (main_var.go:6)    MOVQ    AX, (SP)
    0x0028 00040 (main_var.go:6)    MOVQ    $1000000, 8(SP)
    0x0031 00049 (main_var.go:6)    MOVQ    $1000000, 16(SP)
    0x003a 00058 (main_var.go:6)    CALL    runtime.makeslice(SB)
    0x003f 00063 (main_var.go:6)    MOVQ    24(SP), AX
    0x0044 00068 (main_var.go:6)    XORL    CX, CX
    0x0046 00070 (main_var.go:7)    JMP    76
    0x0048 00072 (main_var.go:7)    ADDQ    $80, AX
    0x004c 00076 (main_var.go:7)    LEAQ    ""..autotmp_7+32(SP), DI
    0x0051 00081 (main_var.go:7)    MOVQ    AX, SI
    0x0054 00084 (main_var.go:7)    DUFFCOPY    $826 # <-- copy the element
    0x0067 00103 (main_var.go:7)    INCQ    CX
    0x006a 00106 (main_var.go:7)    CMPQ    CX, $1000000
    0x0071 00113 (main_var.go:7)    JLT    72
    0x0073 00115 (main_var.go:7)    MOVQ    112(SP), BP
    0x0078 00120 (main_var.go:7)    ADDQ    $120, SP
    0x007c 00124 (main_var.go:7)    RET
    0x007d 00125 (main_var.go:7)    NOP
    0x007d 00125 (main_var.go:3)    CALL    runtime.morestack_noctxt(SB)
    0x0082 00130 (main_var.go:3)    JMP    0

Мне интересно, почему различное поведение для большей структуры (> 80 байт), даже если в обоих случаях элемент слайса не используется.

Answer 1

Я узнал, что это из-за оптимизации SSA. Более четко во время прохода lower. Этот проход изменяет Промежуточное представление на машинную спецификацию c сборки.

при writebarrier (1 шаг до lower), инструкции для идентичных размеров обоев одинаковы.

        v22 (7) = Phi <*SomeStruct> v14 v45
        v28 (7) = Phi <int> v16 v37
        v23 (7) = Phi <mem> v12 v27
        v37 (+7) = Add64 <int> v28 v36
        v39 (7) = Less64 <bool> v37 v8
        v25 (7) = VarDef <mem> {.autotmp_7} v23
        v26 (7) = LocalAddr <*SomeStruct> {.autotmp_7} v2 v25
        v27 (+7) = Move <mem> {SomeStruct} [72] v26 v22 v25  # <-- copy operation

как вы можете видеть, * v100 работает Move.

Однако после прохода lower инструкции расходятся.

с 9 int64 (72 байта)

        v22 (7) = Phi <*SomeStruct> v14 v45
        v28 (7) = Phi <int> v16 v37
        v23 (7) = Phi <mem> v12 v27
        v37 (+7) = ADDQconst <int> [1] v28
        v25 (7) = VarDef <mem> {.autotmp_7} v23
        v26 (7) = LEAQ <*SomeStruct> {.autotmp_7} v2
        v44 (7) = CMPQconst <flags> [1000000] v37
        v32 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [8] v2
        v31 (+7) = ADDQconst <*SomeStruct> [8] v22
        v29 (+7) = MOVQload <uint64> v22 v25
        v24 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [40] v2
        v15 (+7) = ADDQconst <*SomeStruct> [40] v22
        v46 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [56] v2
        v35 (+7) = ADDQconst <*SomeStruct> [56] v22
        v21 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [24] v2
        v17 (+7) = ADDQconst <*SomeStruct> [24] v22
        v39 (7) = SETL <bool> v44
        v42 (7) = TESTB <flags> v39 v39
        v30 (+7) = MOVQstore <mem> {.autotmp_7} v2 v29 v25
        v41 (+7) = MOVOload <int128> [8] v22 v30
        v20 (+7) = MOVOstore <mem> {.autotmp_7} [8] v2 v41 v30
        v34 (+7) = MOVOload <int128> [24] v22 v20
        v19 (+7) = MOVOstore <mem> {.autotmp_7} [24] v2 v34 v20
        v33 (+7) = MOVOload <int128> [40] v22 v19
        v38 (+7) = MOVOstore <mem> {.autotmp_7} [40] v2 v33 v19
        v47 (+7) = MOVOload <int128> [56] v22 v38
        v27 (+7) = MOVOstore <mem> {.autotmp_7} [56] v2 v47 v38

с 10 int64 (80 байт), он оптимизирует MOVE с помощью устройства DUFFCOPY

    v22 (7) = Phi <*SomeStruct> v14 v45
    v28 (7) = Phi <int> v16 v37
    v23 (7) = Phi <mem> v12 v27
    v37 (+7) = ADDQconst <int> [1] v28
    v25 (7) = VarDef <mem> {.autotmp_7} v23
    v26 (7) = LEAQ <*SomeStruct> {.autotmp_7} v2
    v44 (7) = CMPQconst <flags> [1000000] v37
    v32 (+7) = LEAQ <*SomeStruct> {.autotmp_7} [8] v2
    v31 (+7) = ADDQconst <*SomeStruct> [8] v22
    v29 (+7) = MOVQload <uint64> v22 v25
    v39 (7) = SETL <bool> v44
    v42 (7) = TESTB <flags> v39 v39
    v30 (+7) = MOVQstore <mem> {.autotmp_7} v2 v29 v25
    v27 (+7) = DUFFCOPY <mem> [826] v32 v31 v30 # <---

Эта оптимизация обусловлена ​​этим правилом для rewriteAMD64. go

match: (Move [s] dst src mem)
cond: s > 64 && s <= 16*64 && s%16 == 0 && !config.noDuffDevice
result: (DUFFCOPY [14*(64-s/16)] dst src mem)

на более позднем этапе (elim unread autos) оптимизация SSA может обнаружить, что временная переменная autotmp_7 не используется и может быть удалена. Это не относится к большей структуре с DUFFCOPY

Я написал это немного подробнее здесь