文章/答案/技术大牛

发布

社区首页 >问答首页 >为什么for-range的行为会因片结构大小不同而有所不同？

问为什么for-range的行为会因片结构大小不同而有所不同？
EN

Stack Overflow用户

提问于 2020-04-24 19:30:51

回答 1查看 178关注 0票数 0

我在玩这个代码

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

回答 1

Stack Overflow用户

回答已采纳

发布于 2020-04-25 16:31:45

我发现这是因为SSA优化。在lower传递过程中更显着地。此传递将中间表示形式更改为机器特定的程序集。

在writebarrier (lower之前的1步)，对于两个结构尺寸，指令仍然是相同的。

        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

如您所见，在Move上有v27操作。

然而，在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字节)，它使用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 # <---

这个优化是由于这个重写规则AMD64.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的较大结构来说，情况并非如此。

我把它写得更详细了，这里

票数 2

页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持

原文链接：

https://stackoverflow.com/questions/61416082

复制

相似问题

问为什么for-range的行为会因片结构大小不同而有所不同？
EN

回答 1

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么for-range的行为会因片结构大小不同而有所不同？EN

回答 1

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么for-range的行为会因片结构大小不同而有所不同？
EN