以 Go 语言为例解释什么是伪共享以及如何解决

作者：江湖十年

2024-07-04
浙江
本文字数：2565 字
阅读完需：约 8 分钟

本文翻译自：What’s false sharing and how to solve it (using Golang as example)

译文

在解释 伪共享（false sharing）之前，有必要简要介绍一下 CPU 架构中缓存是如何工作的。

CPU 缓存中的最小单位是缓存行（cache line）（如今，CPU 中常见的缓存行大小为 64 字节）。因此，当 CPU 从内存读取一个变量时，它会同时读取该变量附近的所有变量。图 1 是一个简单的例子：

当 core1 从内存读取变量 a 时，它会同时将变量 b 读入缓存。（顺便说一句，我认为 CPU 从内存批量读取变量的主要原因是基于空间局部性理论：当 CPU 访问一个变量时，它可能很快就会读取旁边的变量。）

这种缓存架构存在一个问题：如果一个变量像图 2 那样存在于不同 CPU 核心的两个缓存行中：

当 core1 更新变量 a 时：

即使变量 b 没有被修改，它也会导致 core2 的缓存失效，因此 core2 将重新加载缓存行中的所有变量，如图 4 所示：

这就是所谓的伪共享：一个核心更新一个变量会迫使其他核心也更新缓存。我们都知道，CPU 从缓存读取变量比从内存读取要快得多。因此，当这个变量总是存在于多核中时，这将显著影响性能。

解决这个问题的常见方法是缓存填充（cache padding）：在变量之间填充一些无意义的变量。这将迫使一个变量单独占用一个核心的缓存行，所以当其他核心更新缓存变量时，不会使该核心从内存中重新加载变量。

让我们使用下面的 Go 代码片段简要介绍这个伪共享的概念。

这里是一个包含 3 个 uint64 的 Go 结构体，

type NoPad struct {  a uint64  b uint64  c uint64}
func (myatomic *NoPad) IncreaseAllEles() {  atomic.AddUint64(&myatomic.a, 1)  atomic.AddUint64(&myatomic.b, 1)  atomic.AddUint64(&myatomic.c, 1)}

复制代码

还有另一个我在变量之间添加了 [8]uint64 以进行填充的结构体：

type Pad struct {  a   uint64  _p1 [8]uint64  b   uint64  _p2 [8]uint64  c   uint64  _p3 [8]uint64}
func (myatomic *Pad) IncreaseAllEles() {  atomic.AddUint64(&myatomic.a, 1)  atomic.AddUint64(&myatomic.b, 1)  atomic.AddUint64(&myatomic.c, 1)}

复制代码

然后我编写了一个简单的代码来运行基准测试：

func testAtomicIncrease(myatomic MyAtomic) {  paraNum := 1000  addTimes := 1000  var wg sync.WaitGroup  wg.Add(paraNum)  for i := 0; i < paraNum; i++ {    go func() {      for j := 0; j < addTimes; j++ {        myatomic.IncreaseAllEles()      }      wg.Done()    }()  }  wg.Wait()
}func BenchmarkNoPad(b *testing.B) {  myatomic := &NoPad{}  b.ResetTimer()  testAtomicIncrease(myatomic)}
func BenchmarkPad(b *testing.B) {  myatomic := &Pad{}  b.ResetTimer()  testAtomicIncrease(myatomic)}

复制代码

在 2014 年的 MBA 上运行的基准测试如下：

$> go test -bench=.BenchmarkNoPad-4 2000000000 0.07 ns/opBenchmarkPad-4 2000000000 0.02 ns/opPASSok 1.777s

复制代码

基准测试的结果显示，性能从 0.07 ns/op 提高到了 0.02 ns/op，这是一个很大的改进。

你也可以在其他语言（如 Java）中测试这一点，我相信你会得到相同的结果。

在你将其应用到生产环境之前，你应该了解两个关键点：

确保了解你系统中 CPU 的缓存行大小：这与你使用的缓存填充大小有关。
填充更多变量意味着你将消耗更多的内存资源。运行基准测试并确保你的投入是值得的。

我所有的示例代码都在 GitHub 上。

P.S.

之所以选择翻译此文，是因为我正在写关于 Go 结构体内存对齐的文章，需要介绍「伪共享」这个概念，受限于篇幅所限，就决定针对伪共享这个概念单独写一篇文章。我在查阅资料过程中发现此文讲解浅显易懂，于是想着把此文翻译下共读者查阅。

不过虽然这篇文章思路清晰易懂，但作者提供的基准测试代码并不够严谨，我在 2022 款 M2 芯片的 MBA 上测试得到如下结果：

$ go test -bench=. -vgoos: darwingoarch: arm64pkg: false-sharingBenchmarkNoPadBenchmarkNoPad-8        1000000000               0.09618 ns/opBenchmarkPadBenchmarkPad-8          1000000000               0.1065 ns/opPASSok      false-sharing      2.368s

复制代码

跟作者的结果完全相反，哈哈😄。

我们可以写一个简单的基准测试来验证使用 cache padding 来解决 false sharing 的效果：

package main
import (  "sync/atomic"  "testing")
func BenchmarkPadding(b *testing.B) {  b.Run("without_padding", func(b *testing.B) {    nums := [128]atomic.Int64{}    i := atomic.Int64{}    b.RunParallel(func(pb *testing.PB) {      id := i.Add(1)      for pb.Next() {        nums[id].Add(1)      }    })  })  b.Run("with_padding", func(b *testing.B) {    type pad struct {      val atomic.Int64      _   [8]uint64    }    nums := [128]pad{}    i := atomic.Int64{}    b.RunParallel(func(pb *testing.PB) {      id := i.Add(1)      for pb.Next() {        nums[id].val.Add(1)      }    })  })}

复制代码

在 without_padding 场景中，由于 nums 数组的元素可能共享相同的缓存行，多个 goroutine 同时修改相邻元素时会导致缓存行失效，从而降低性能。

而在 with_padding 场景中，通过在高频访问的变量之间加入缓存填充 _ [8]uint64，使得每个元素都占据独立的缓存行，减少了这种缓存行的失效情况，预期能观察到性能的提升。

执行基准测试代码，输出如下：

$ go test -bench=. -vgoos: darwingoarch: arm64pkg: false-sharingBenchmarkPaddingBenchmarkPadding/without_paddingBenchmarkPadding/without_padding-8              55441728                22.09 ns/opBenchmarkPadding/with_paddingBenchmarkPadding/with_padding-8                 1000000000               1.075 ns/opPASSok      false-sharing      4.255s

复制代码

基准测试的结果显示，性能从 22.09 ns/op 提高到了 1.075 ns/op。

这段代码由原文评论区提供，你可以自行尝试验证。

延伸阅读

原文地址: https://medium.com/@genchilu/whats-false-sharing-and-how-to-solve-it-using-golang-as-example-ef978a305e10

联系我

微信：jianghushinian
邮箱：jianghushinian007@outlook.com
博客：https://jianghushinian.cn

发布于: 19 分钟前阅读数: 6

原文链接:【http://xie.infoq.cn/article/3c3d53d92937e9696a38d7c46】。文章转载请联系作者。

江湖十年

关注

野生程序员 2018-11-10 加入

分享不限于 Go、Python、Docker、K8s 技术。

发布

暂无评论

创作场景

以 Go 语言为例解释什么是伪共享以及如何解决

译文

P.S.

江湖十年

评论