cacheline 对 Go 程序的影响

首先来了解一下来自维基百科上关于CPU缓存的介绍。

当从内存中取单元到cache中时，会一次取一个cacheline大小的内存区域到cache中，然后存进相应的cacheline中, 所以当你读取一个变量的时候，可能会把它相邻的变量也读取到CPU的缓存中(如果正好在一个cacheline中)，因为有很大的几率你回继续访问相邻的变量，这样CPU利用缓存就可以加速对内存的访问。

在多核的情况下，如果两个CPU同时访问某个变量，可能两个CPU都会把变量以及相邻的变量都读入到自己的缓存中：

这会带来一个问题：当第一个CPU更新一个变量a的时候，它会导致第二个CPU读取变量b cachemiss, 即使变量b的值实际并没有变化。因为CPU的最小读取单元是cacheline,所以你可以看作a和b是一个整体，这就是伪共享：**一个核对缓存中的变量的更新会强制其它核也更新变量。

伪共享带来了性能的损失，因为从CPU缓存中读取变量要比从内存中读取变量快的多, 这里有一个很经典的图：

在并发编程中，经常会有共享数据被多个goroutine同时访问， 所以如何有效的进行数据的设计，就是一个相当有技巧的操作。最常用的技巧就是 Padding 。现在大部分的CPU的cahceline是64字节，将变量补足为64字节可以保证它正好可以填充一个cacheline。

台湾的 盧俊錡 Genchi Lu 提供了一个很好的例子来比较pad和没有padding的性能(我稍微改了一下)。

package test

import (
	"sync/atomic"
	"testing"
)

type NoPad struct {
	a uint64
	b uint64
	c uint64
}

func (np *NoPad) Increase() {
	atomic.AddUint64(&np.a,1)
	atomic.AddUint64(&np.b,1)
	atomic.AddUint64(&np.c,1)
}

type Pad struct {
	a   uint64
	_p1 [8]uint64
	b   uint64
	_p2 [8]uint64
	c   uint64
	_p3 [8]uint64
}

func (p *Pad) Increase() {
	atomic.AddUint64(&p.a,1)
	atomic.AddUint64(&p.b,1)
	atomic.AddUint64(&p.c,1)
}

func BenchmarkPad_Increase(b *testing.B) {
	pad := &Pad{}

	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			pad.Increase()
		}
	})

}

func BenchmarkNoPad_Increase(b *testing.B) {
	nopad := &NoPad{}
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			nopad.Increase()
		}
	})
}

运行结果:

go test -gcflags "-N -l" -bench .
goos: darwin
goarch: amd64
BenchmarkPad_Increase-4     30000000	       56.4 ns/op
BenchmarkNoPad_Increase-4   20000000	       91.4 ns/op

可能每次运行的结果不相同，但是基本上Padding后的数据结构要比没有padding的数据结构要好的多。

Java中知名的高性能的 disruptor库 中的设计中也采用了padding的方式避免伪共享。

你可以使用 intel-go/cpuid 获取CPU的cacheline的大小， 官方库 x/sys/cpu 也提供了一个 CacheLinePad struct用来padding,你只需要在你的struct定义的第一行增加 _ CacheLinePad 这么一行即可：

var X86 struct {
	_            CacheLinePad
	HasAES       bool // AES hardware implementation (AES NI)
    HasADX       bool // Multi-precision add-carry instruction extensions
    ......

参考资料

1. https://zh.wikipedia.org/wiki/CPU缓存
2. https://medium.com/@genchilu/whats-false-sharing-and-how-to-solve-it-using-golang-as-example-ef978a305e10
3. https://github.com/golang/go/issues/14980
4. https://github.com/klauspost/cpuid
5. https://segment.com/blog/allocation-efficiency-in-high-performance-go-services/
6. https://luciotato.svbtle.com/golangs-duffs-devices
7. https://stackoverflow.com/questions/14707803/line-size-of-l1-and-l2-caches
8. https://luciotato.svbtle.com/golangs-duffs-devices
9. https://github.com/golang/go/issues/25203