golang 单线程原子操作性能怎么这么差？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

The Go Programming Language

› http://golang.org/

› Go Playground

Go Projects

› Revel Web Framework

这是一个创建于 3290 天前的主题，其中的信息可能已经有所发展或是发生改变。

package main
import (
    "sync/atomic"
    "fmt"
    "time"
)


func main() {

    var t1 uint64 = 0
    var t2 uint64 = 0

    endChan := make(chan int)
    for i := 0; i < 1000; i++ {
        go func() {
            for i := 0; i < 10000; i++ {
                atomic.AddUint64(&t1, 1)
                t2 += 1
            }
            endChan <- 1
        }()
    }

    for i := 0; i < 1000; i++ {
        <-endChan
    }

    // 测试非原子操作造成的值不正确
    // t1= 10000000
    // t2= 8513393
    fmt.Println("t1=", t1)
    fmt.Println("t2=", t2)


    // 性能测试
    func() {
        var t1 uint64 = 0

        startTime := time.Now()
        for i := 0; i < 1000000000; i++ {
            t1 += 1
        }
        endTime := time.Now()
        fmt.Println("非原子操作耗时：", endTime.Sub(startTime))
        // 非原子操作耗时： 535.0303ms

    }()

    func() {
        var t1 uint64 = 0

        startTime := time.Now()
        for i := 0; i < 1000000000; i++ {
            atomic.AddUint64(&t1, 1)
        }
        endTime := time.Now()
        fmt.Println("原子操作耗时：", endTime.Sub(startTime))
        //原子操作耗时： 14.7758413s
    }()
}

原子操作的实现不是锁总线？单线程应该锁总线应该不会影响性能吧？

原子

fmt

endtime

uint64

10 条回复 • 2015-11-21 23:30:03 +08:00

semicircle21

2015-11-21 13:01:00 +08:00

赞, 有意思的测试, 我猜测有几个问题:
1. 在测非原子操作耗时的时候, 我不确定 go 的编译器直接优化掉, 有精力的话, 你可以试一下 1. 用 if / else 替代 for 循环, 2. 把 t+=1 封个函数.
2. 即便真的差距这么大, 也容易用指令流水线的原理来解释.

semicircle21

2015-11-21 13:01:36 +08:00

go 的编译器直接优化掉 for 循环
-- 删删改改弄错了.

semicircle21

2015-11-21 13:06:51 +08:00

对了, 如果要有实际应用场景的话, 是不是可以考虑用一个 go routine 来维护 t 这个变量, 即增加的时候往一个有 buffer 的 chan 里写 delta, 这样一般不会阻塞, 至于查询, 如果不需要准确值, 直接读 t 就好, 如果需要准确, 就比较棘手了.

wheatmai

2015-11-21 13:20:50 +08:00

对 go 的内存模型不是很了解，这里原子操作，`atomic.AddUint64`的[实现]( https://github.com/golang/go/blob/master/src/sync/atomic/64bit_arm.go#L27)其实就是一条[`CMPXCHGQ`]( https://github.com/golang/go/blob/master/src/sync/atomic/asm_amd64.s#L55)指令，即 CAS ，`Q`代表 quadword 。

wheatmai

2015-11-21 13:38:50 +08:00

同意 @semicircle21 的猜测，在非原子操作的情况下，编译器有可能优化了 for 。但是对于原子操作，为了让`t1`对所有线程都是可见的， t1 就不会缓存在某个 cpu core 的 cache 或者其他 core 不可见的地方。同时为了线程安全，`t1`上的操作也不会与其他内存操作进行 reorder 。