为何for-range在不同大小的切片结构上表现不同？

一分耕耘，一分收获！既然都打开这篇《为何for-range在不同大小的切片结构上表现不同？》，就坚持看下去，学下去吧！本文主要会给大家讲到等等知识点，如果大家对本文有好的建议或者看到有不足之处，非常欢迎大家积极提出！在后续文章我会继续更新Golang相关的内容，希望对大家都有所帮助！

我正在研究这段代码

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 循环就会变慢。

如果我比较程序集，它添加了复制元素的指令

// 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 字节）的行为不同，即使在这两种情况下都没有使用切片的元素。

解决方案

我发现这是因为ssa优化。 在 lower 过程中更明确。此遍将中间表示更改为机器特定的程序集。

在 writebarrier（lower 之前 1 步），两种结构尺寸的说明仍然相同。

v22 (7) = phi <*somestruct> v14 v45
        v28 (7) = phi  v16 v37
        v23 (7) = phi  v12 v27
        v37 (+7) = add64  v28 v36
        v39 (7) = less64  v37 v8
        v25 (7) = vardef  {.autotmp_7} v23
        v26 (7) = localaddr <*somestruct> {.autotmp_7} v2 v25
        v27 (+7) = move  {somestruct} [72] v26 v22 v25  # <-- copy operation

如您所见，v27 上有 move 操作。

但是，在 lower 通过之后，指令出现分歧。

9 个 int64（72 字节）

v22 (7) = phi <*somestruct> v14 v45
        v28 (7) = phi  v16 v37
        v23 (7) = phi  v12 v27
        v37 (+7) = addqconst  [1] v28
        v25 (7) = vardef  {.autotmp_7} v23
        v26 (7) = leaq <*somestruct> {.autotmp_7} v2
        v44 (7) = cmpqconst  [1000000] v37
        v32 (+7) = leaq <*somestruct> {.autotmp_7} [8] v2
        v31 (+7) = addqconst <*somestruct> [8] v22
        v29 (+7) = movqload  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  v44
        v42 (7) = testb  v39 v39
        v30 (+7) = movqstore  {.autotmp_7} v2 v29 v25
        v41 (+7) = movoload  [8] v22 v30
        v20 (+7) = movostore  {.autotmp_7} [8] v2 v41 v30
        v34 (+7) = movoload  [24] v22 v20
        v19 (+7) = movostore  {.autotmp_7} [24] v2 v34 v20
        v33 (+7) = movoload  [40] v22 v19
        v38 (+7) = movostore  {.autotmp_7} [40] v2 v33 v19
        v47 (+7) = movoload  [56] v22 v38
        v27 (+7) = movostore  {.autotmp_7} [56] v2 v47 v38

使用 10 int64（80 字节），使用 duffcopy 设备优化 move

v22 (7) = phi <*somestruct> v14 v45
    v28 (7) = phi  v16 v37
    v23 (7) = phi  v12 v27
    v37 (+7) = addqconst  [1] v28
    v25 (7) = vardef  {.autotmp_7} v23
    v26 (7) = leaq <*somestruct> {.autotmp_7} v2
    v44 (7) = cmpqconst  [1000000] v37
    v32 (+7) = leaq <*somestruct> {.autotmp_7} [8] v2
    v31 (+7) = addqconst <*somestruct> [8] v22
    v29 (+7) = movqload  v22 v25
    v39 (7) = setl  v44
    v42 (7) = testb  v39 v39
    v30 (+7) = movqstore  {.autotmp_7} v2 v29 v25
    v27 (+7) = duffcopy  [826] v32 v31 v30 # <---

这次优化是因为这个rule on 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 未读 autos），ssa 优化可以检测到临时变量 autotmp_7 未被使用，可以将其删除。 duffcopy 的较大结构并非如此

我写得更详细一些here

今天关于《为何for-range在不同大小的切片结构上表现不同？》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！