比尔·肯尼迪谈机械共鸣

我是比尔·肯尼迪，现在是Go时间了。

So I'm Bill Kennedy, and it's now go time.

《Go Time》是一档每周播客，我们讨论围绕Go编程语言、社区以及其间一切的有趣话题。

It's Go Time, a weekly podcast where we discuss interesting topics around the Go programming language, the community, and everything in between.

如果你目前正在使用Go，或者希望使用Go，那么这档节目就是为你准备的。

If you currently write Go or aspire to, this is the show for you.

好了，各位。

Alright, everybody.

欢迎回到《Go Time》的又一期节目。

Welcome back for another episode of Go Time.

这是第六期。

It's episode number six.

我是埃里克·圣。

I'm Eric St.

马丁。

Martin.

今天和我一起的还有Brian Kettleson。

Today here with me, we have Brian Kettleson.

打个招呼吧，Brian。

Say hello, Brian.

大家好。

Hello.

我们还有Carlicia Campos。

And we have Carlicia Campos.

打个招呼。

Say hello.

很高兴来到这里。

Glad to be here.

大家好。

Hi, everybody.

今天我们还有一位特别嘉宾。

And we have a special guest with us today.

今天和我们在一起的是来自Arden Labs和GoBridge的比尔·肯尼迪。

Bill Kennedy from Arden Labs and GoBridge is here with us today.

你可能也熟悉他做的所有工作坊，比如现在全世界范围内的那些。

You might also know him from all of his workshops that he does, Like, the world now.

是这样吧，比尔？

Right, Bill?

是的。

Yeah.

今年我有幸去了几次欧洲。

I've been lucky enough to get into, Europe a couple of times this year.

是的。

Yeah.

这太糟糕了。

This is bad.

太疯狂了。

It's crazy.

我们每天都在别的地方看到你。

It's like every day we see you somewhere else.

我不知道飞机是怎么准时赶到你的工作坊的。

I I don't know how the planes arrive in time for your workshops.

安排时间确实有时候很困难。

Scheduling is difficult sometimes for sure.

我的意思是，你的常旅客里程有多少了？

I mean, what's your mileage look like for frequent flyer miles?

我觉得我现在大概有13万英里了。

I think I'm at, like, a 130,000 miles right now.

我真不羡慕你。

I don't envy you.

钻石精英？

Diamond Elite?

在美国航空，我现在是白金会员，正在向执行白金会员迈进。

I'm, on American, I am now platinum on my way to executive platinum.

不错。

Nice.

但这些确实不是你应该追求的目标。

But, yes, these are not goals that you should you should want to achieve.

你有喜欢的、装在小瓶里的香皂和洗发水吗？

Do you have your favorite, soap and shampoo that comes in a small bottle?

我会尽可能利用酒店提供的任何东西。

I leverage whatever the hotel has to the extent that I can.

所以今天，我们将和比尔聊聊机械同理心。

So today, we're gonna be talking with Bill about mechanical sympathy.

我觉得这个话题会非常有趣。

So I think this is gonna be a really interesting topic.

在进入主题之前，我们先聊聊新闻和一些有趣的项目。

Before we get into that, let's, let's talk news and interesting projects.

在开始和比尔讨论之前，大家有什么有趣的事情想分享吗？

Anybody have anything interesting they wanna talk about before we get into it with Bill?

你知道，从我的角度来看，GO新闻这周相当平静，但我确实发现了两个相对有趣的项目。

You know, it was a pretty quiet week in in GO News from my perspective, but I did find two relatively interesting projects.

第一个项目，我认为可能会赢得年度最佳黑客奖。

The first one, I thought might be a winner in the best hack of the year award.

在节目笔记中，你会找到来自axon.acsin.com博客文章的链接，他们拼凑出一种方法将StatsD类型的指标发送到Google Analytics，这看起来像是一个有趣的强行适配，而且似乎运行得相当不错。

In the show notes, you'll find a link to the blog post from axon, acksin,.com, where they hacked together a way to send stats d type metrics to Google Analytics, which seems like an interesting shoe horn, and it looks like it works pretty well.

所以你可以通过不当使用Google Analytics，为你的服务器获得一个不错的免费StatsD监控。

So you get a nice, free StatsD monitoring for your servers, using Google Analytics inappropriately.

我完全赞同这个计划。

I approve completely of this plan.

不过，你知道，有趣的是你可以把它和你已经在谷歌分析中收集的指标放在一起看，看看其中一些因素可能会如何影响你的转化漏斗。

You know, but the interesting thing about that though is you can see it alongside, metrics that you're already collecting in Google Analytics and how some of those things might impact, your funnel.

所以一时想不出我会用它来做什么具体用途，但我认为它确实有潜力变得很有价值。

So can't think of any specific uses I'd use it for off the bat, but it does I think it has potential to be valuable.

至少可以说，这很有趣。

It was interesting to say the least.

我不确定我会把它部署到一个有用的生产系统上。

I'm not sure I would put it in production on a useful system.

万一谷歌决定识别出这种流量并开始丢弃它呢？

What if Google decided that they could figure out that traffic and start tossing it?

是啊。

Yeah.

我觉得我更喜欢Grafana之类的工具。

I think I'd prefer Grafana or something like that.

但是

But

Datadog 所有

Datadog all the

一路。

way.

Datadog 也是好东西。

Datadog is good stuff too.

所以我发现的第二个有趣的项目是众多依赖管理项目中的一个。

So the second interesting project I found is is one in the multitude of vendoring projects.

这个项目叫 Manul，拼写是 m-a-n-u-l，你可以在节目笔记中找到它的链接。

This one's called Manul, m a n u l, and you'll find the link to that in the show notes.

它同样是使用 Git 子模块进行依赖管理的工具，看起来是支持 Git 子模块的较优依赖管理包之一。

And, it's it's another one that does vendoring, with Git submodules this time, and it looked to be one of the better vendoring packages that supports Git submodules.

因此它有一些非常不错的

So it had some very nice

命令和实用工具。

commands and utilities with it.

不过我很好奇他们是如何解决使用子模块的一些缺点的，因为很多人对使用 Git 子模块持保留意见。

I'm interested to see though how they solve some of the drawback from using submodules because a lot of people have reservations about using git submodules.

它的运作方式存在一些固有的缺陷。

There's kind of some inherent flaws with the way it works.

比如第一个问题就是，你仍然依赖于该仓库在未来是否依然存在。

Like number one would be that you're still reliant on that repository to exist in the future.

所以如果它宕机了，或者有人决定删除他们的项目，因为这种事情完全不会发生。

So if it went down or somebody decided to delete their project, because that totally never happens.

或者甚至只是重命名一下。

Or even just rename it.

你仍然无法访问代码，但这也与子模块的工作方式有关。

You still wouldn't have access to the code, but some of it also comes in the way sub modules work.

所以如果我拉取你的项目，我需要执行 git submodule update 来更新我本地的那些子模块，但如果我不这么做，我仍然在使用那些子模块的旧版本。

So if I pull down your project and I need to do a git submodule update to update my local versions of those sub modules, but if I don't do that, I'm still running with my prior versions of those sub modules.

但当你检出代码时，它并不会自动更新我的子模块。

So but by checking out your code, it doesn't move my sub modules with it.

所以我可能会不小心提交了你项目的旧版本，而这些错误非常容易被忽略。

So I can accidentally commit my older versions of your stuff, and those lines are really some like, really easy to miss.

而且这些子模块在合并时也存在一些问题。

And there's a couple issues too with the way those things are kind of merged and stuff too.

所以我很好奇他们是如何解决这些问题的。

So I'm interested to see how that's solved.

因为人们经常覆盖彼此的子模块。

Because people step on each other's sub modules all the time.

你会看到这种情况，比如我拉取了你的更改，但没注意到你更新了子模块。

You see it where, you know, I pull down your changes, but I didn't notice you had sub module updates.

但当我提交我的更改时，我的子模块版本和你的不同，结果我就覆盖了你的版本。

But then I commit my commit and my sub module versions are different than yours, and I just kind of step on yours.

不过这些问题几年前就有人遇到了，所以也许 Git 现在已经有了一些应对措施。

But I mean these are problems that people were having years ago, so maybe there's some stuff in git now that accounts for it.

也许工具本身也稍微做了一些处理。

Maybe the tool accounts for it a little bit too.

我想如果你在提交钩子之类的地方做点处理，大概是可以解决的。

I guess if you did it on like a commit hook or something you could probably.

但确实挺有意思的。

But yeah, it's interesting though.

子模块可能很有用，但也可能很麻烦，不过我想编程里的所有东西都差不多，对吧？

Submodules can be valuable and they can also be a pain, but I guess everything in programming can be, right?

总是如此。

Always.

你们之前用过子模块吗？

Have you guys used submodules before?

有人用过吗？

Anybody?

我用过。

I have.

我用过。

I have.

我用的时候没遇到什么问题。

I did not run into any problem with it.

没做什么疯狂的操作。

Didn't do anything crazy.

只是把子模块放进去用来访问它。

Just drop a submodule there to access it.

是的。

Yeah.

我会找一个关于这些陷阱的链接，并在发布前放到节目笔记中。

I'll find a link surrounding some of those pitfalls, and we'll drop it in the show notes before this is released.

这件事已经过去几年了，所以我一时想不起具体的名字，但我知道很多人遇到了很多奇怪的问题。

This has been a couple years, so I can't remember the name of one off the top of my head, but I know people were having a lot of weird issues.

我们还想聊点别的吗？

So anything else we want to talk about?

我没什么了。

That's all I had.

我也没有。

I don't have anything.

我知道我们想聊什么。

I know what we do want to talk about.

机械交响曲？

Mechanical symphony?

没错。

Exactly.

是的。

Yes.

首先，这个名字是从哪里来的？

First first thing, where did this name come from?

我们之前聊过这个，但我想要听亲口说的人讲。

We were talking about this earlier, but I want to hear from the horse mouth.

这名字不是我起的。

It didn't come from me.

这个术语，我想我是从马丁·汤普森那里听说的，看过他视频的人都知道，他说他是从一位赛车手那里听来的。

This is a term that, I think I got from, Martin Thompson who watched any of his videos, he says he got it from a race car driver.

对。

Yeah.

杰基·斯图尔特是一位一级方程式车手。

Jackie Stewart was a Formula One driver.

我认为在一次采访中，他曾说过类似这样的话：你不需要是工程师或机械师才能成为赛车手，但你必须具备机械共鸣感。

And I think during an interview, had said something along the lines of, you you don't need to be an engineer or a mechanic or something to be a race car driver, but you need to have mechanical sympathy.

基本上，他的意思是，只要对机器——也就是汽车——的工作原理有一定理解，就能让你成为一个更好的驾驶员。

And basically, he was just implying by having some level of understanding of how the machine, the car worked, that it made you a better driver.

而且我认为，正如比尔指出的，马丁·汤普森——我想是他——开始将这一理念应用到编程中。

And I think, as Bill pointed out, Martin Thompson, I think it was, started applying that to programming.

所以比尔，你能不能给我们详细讲讲，你认为这个概念是如何应用于编程的？

So Bill, would you like to fill us in a bit on how how you think that that concept applies to programming?

是的。

Yeah.

我的观点仅限于Go语言这一方面，这也是我在培训中非常关注的一点。

I mean, I I only have a perspective on it from the Go side and it's something I really focus on in the training.

我在培训中主要关注两个方面：数据导向设计和机械共鸣感，并试图展示Go语言本身是如何紧密契合这两个理念的。

I kind of focus on two things in the training, data oriented design and mechanical sympathy and try to show how the language Go itself is very in tune around these two ideas.

我深信，如果你不理解你所处理的数据，你就无法真正理解你试图解决的问题。

And really believe, that if you don't understand the data that you're working with, you do not understand the problem that you're trying to solve.

一切都从这里开始。

It all starts there.

就像我们试图解决的每一个问题，本质上都是某种形式的数据操作问题。

Like everything, every problem that we're trying to solve is really a data manipulation problem in some fashion, in some way.

所以一切都始于数据，这个观点是：如果你不了解你所处理的数据，你就无法理解这个问题。

So it all really starts with the data And it's this idea that if you don't understand the data you're working with, you don't understand the problem.

如果你不了解解决这个问题的成本，你就无法真正地思考如何解决它。

And if you don't understand the cost of solving that problem, you can't really reason about solving it.

要能够评估成本，你必须理解每一行代码的作用，以及它如何影响操作系统和硬件——这些硬件正是用来执行你花时间编写的指令的。

And to be able to reason about the cost, you have to have some understanding of what every line of code is doing and how that's affecting the operating system and the hardware, which is there to execute those instructions that you're spending time writing to begin with.

因此，我真正感兴趣并思考的是这种关系，以及Go语言如何帮助我们实现这一点。

So I I think it's it's that relationship that I'm really interested in and and think about in terms of what Go is doing to help us.

当你谈到机械同理心时，你指的是磁盘、缓存、CPU等物理层面的东西，是电气层面的事务。

So when you talk about mechanical sympathy, you're talking about things at the physical level, like the disks, the caches, the CPU, electrical things.

作为程序员，我们需要关心其中多少内容？

How much of that as a programmer do we have to care about?

我真正关注的是你所处理的数据。

I really focus it around the data that you're working with.

因此，我学到的一点是，我们今天所使用的硬件是处理器。

And so, you know, one of the things that I've learned is that the hardware that we're working today are processors.

它们现在都是多核处理器，每个核心都有自己的本地缓存。

You know, they're now multicore processors, and every core has their own sets of local caches.

在许多情况下，L1和L2缓存属于每个核心。

That l one and l two cache, in many cases, belong to each core.

核心之间可以共享L3缓存，而你已无法直接访问主内存。

Cores could then share an l three cache, and you just don't have access anymore directly to main memory.

因此，如果你编写的代码导致硬件无法预测你所访问的数据，就会出现缓存未命中，这可能耗费数百个时钟周期。

So if you're writing code where the hardware cannot predict access to the data you're working with, then you're going to have these cache misses that can cost you hundreds of clock cycles.

在Scott Myers的一次演讲中提到的一种架构里，每次缓存未命中都会耗费107个时钟周期。

In one architecture that Scott Myers uses in one of his talks, it's a 107 clock cycles every time you have a cache miss.

不过，这个数值会因硬件不同而有所变化。

And now that's going to change from hardware to hardware.

但如果你想象使用某种链表数据结构，在每次迭代中访问列表中的不同节点，而列表中的每个节点都与缓存系统不兼容，不在同一缓存行上。

But if you can imagine employing some sort of linked linked list data structure, where on every iteration, you're accessing a different node in the list and every node in that list is not sympathetic to the caching system, doesn't exist on their on the same cache lines.

我的意思是，你可能在不知不觉中大量访问内存，却根本不知道为什么速度这么慢。

I mean, you could be chugging through memory without even realizing it, without even understanding why it's as slow as as it is.

所以让我们稍微退一步，因为很多人

So from Let's let's back up here just a a second too because, a lot

许多人都来自动态语言，比如 Ruby、Python，甚至 Go 也把这些概念对你隐藏了。

of people come from dynamic languages, you know, Ruby, Python, and even Go abstracts these concepts from you.

让我们花点时间谈谈 CPU 缓存以及它们是什么。

Let's let's take a second and talk about CPU caches and and what those are.

因为我认为，很多人甚至都不熟悉 CPU 缓存是什么。

Because I I would argue that probably a lot of people aren't even familiar with what a CPU cache is.

所以我们必须以非常高层的抽象层面来讨论这个问题，因为硬件差异真的很大。

So we've gotta talk about this at a very high representative level because hardware is really different.

但本质上，我们处理的是一种带有缓存的硬件，从我们的角度来看，它们可能都是一样的。

But in essence, we're dealing with piece of hardware that has caches, and from our perspective, it can be all the same.

因此，其理念是硬件需要将我们所使用的内存尽可能靠近它。

And so the idea is that hardware needs to have the memory that we're working with as close to it as possible.

而今天的情况是，如果你需要主存中的哪怕一个字节，它也必须从主存移动到一级或二级缓存中才能被使用。

And what's going to happen today is if you need any even a byte of memory that's sitting out in main, it's got to move from main memory into into, let's say, the l one or l two cache for it to be used.

这些缓存是以缓存行的形式被加载和卸载的，而目前默认的缓存行大小通常是64字节。

And these caches get pulled in and out on cache lines, and the default cache line today will probably work when there's a 64 byte cache line.

因此，现在的理念是，如果你的指令正在处理数据——而这正是我们所做的。

And so the idea is that we the the idea now is if you have instructions that are working with data, which is what we do.

对吧？

Right?

我的意思是，这正是我们每天都在做的事情。

I mean, this is what we do all day.

我们在读取内存。

We're reading memory.

我们在向内存写入。

We're writing to memory.

这些内存现在必须进入缓存系统，我们才能使用它。

This memory has to now get into the caching system in order for us to be able to use it.

这些数据将通过64字节的缓存行在主存和缓存之间来回移动。

This data is gonna be moving on these 64 byte cache lines from main and back in.

因此，为了顺应硬件，我们可以尽量以连续的块来处理数据。

And so one of the things that we can do to be sympathetic with the hardware is try to work with data in as contiguous blocks as possible.

我们的数据越连续，通常就意味着你正在遍历这些数据。

The more contiguous our data is, you usually then at that point are probably iterating over that data.

遍历数据可以产生所谓的可预测访问模式，现代硬件能够识别这些模式。

And iterating over data can create what are called, you know, predictable access patterns to that data that the hardware today can pick up on.

因此，如果我们真的想让硬件充分发挥其潜力，就必须顺应它。

And so if we really want to give the hardware its best opportunity to take advantage of everything that's in there, we've got to be sympathetic with it.

我们必须从数据的工作集角度来审视数据。

We've got to try to look at data in a way of what are our working sets of data?

我们能否将数据连续排列、连续处理，并围绕它创建可预测的访问模式？

Can we lay data out contiguously, work with data contiguously, and can we create predictable access patterns around that?

因此，硬件可以识别出哪些是接下来可能用到或肯定会用到的缓存行，并在这些指令需要它们之前将它们提前加载到缓存中。

So the hardware can pick up on what what are the next cache lines that are probably in play or will definitely be in play and pull those into the caches before those next instructions need them.

人们该如何学习什么是可预测的访问模式呢？

How does somebody learn about what predictable access patterns look like?

他们又该如何实现这种模式呢？

And what can they do to achieve that?

从今天的视角来看，数组确实是硬件层面最重要的数据结构，因为只有数组能让你创建连续的内存块。

From today's perspective, it is the array that is really the most important data structure from the hardware perspective, because it is the array that allows you to create contiguous blocks of memory.

嗯，我想结构体也是这样对齐的，对吧？

Well, I guess structs are aligned that way too, right?

再说一遍，我没听清。

Say it again, I'm sorry.

结构体也是连续对齐的。

Structs are also aligned contiguously.

没错，但假如我要创建一个用户结构体，并且要创建十万条这样的数据，如果我没有把它们连续排列，而是用链表的方式存放，这些用户值就会随机地分散在内存各处。

They are, but but if I was gonna create a user struct and I was gonna create a 100,000 of those and I didn't lay that out contiguous, I've laid you know, I created a just a linked list of these particular user values and they laid out all over in memory almost randomly.

当你开始遍历这个链表时，硬件无法识别出任何模式，你基本上只能逐个访问内存，因为每次访问都会导致缓存未命中。

And you started walking down that linked list, the hardware is not going to be able to pick up on any pattern there, and you're basically going to be chugging through memory because every access is going to be a cache miss.

因此，我们试图通过尽可能将所有数据集中在一起，尽量减少占用的缓存行数量来消除这种情况。

So we're trying to eliminate that by trying to keep all of the data that we can as close together as possible on the least number of cache lines as possible.

没错，因为多年来，尽管处理器的速度没有显著提升，但它们在多任务处理方面变得好得多。

Right, because over the years processors, even though they haven't got significantly faster, they've become much better at multi tasking.

因此，即使处理器在同一周期内正在执行数学计算，它也可以预取下一次步长并加载下一个缓存行，这样在下一次迭代时，数据已经就位，几乎是免费的。

So while the processor may be performing a math calculation in the same cycle, it can be pulling, making the next stride and pulling the next cache line in, so that the next iteration, the data is already there and it's basically for free.

如果它能预测下一个缓存行的位置，那么它完全可以做到这一点。

If it can predict what that next cache line is, then it absolutely can do that.

但如果我们不配合、不帮助它预测这些内容，它就无法提前加载缓存行，直到它确切知道‘现在我需要的数据就在这里’。

But if we're not being sympathetic and helping it be able to predict these things, then it can't pull that cache line until it knows exactly, now this is where the data is that I need.

抱歉。

I'm sorry.

我本来想说，访问模式——你提到的关于数据以及你如何使用数据的重要性。

I was just going to say, so the access patterns, how you talk about it being important thinking about the data and how you're working with it.

我想了想，主要有两个要点：时间局部性和空间局部性，也就是处理内存中相邻的数据，或者同时处理相同的数据块，对吧？

I guess the two main points I can think of is basically temporal and spatial locality, Working with things that are located next to each other in memory or working on the same pieces of data at the same time, right?

这跟你提到的尽量减少缓存未命中有点关系。

Kind of to your point where you can minimize the number of cache misses.

是的。

Yeah.

而且希望即使我这么说吧，你不可能完全避免缓存未命中，但如果你有一组数据需要频繁处理，一旦被加载进来，它就一直在那里，你可以反复利用。

And hopefully, even if I mean, you're not gonna avoid cache misses altogether, but if you have a working set of data that you're gonna be doing a lot of processing on, once it gets pulled in, now it's there, you can leverage it.

如果你一直在内存中来回跳转，而且这种跳转还比较随机，那就只能慢慢拖着走了。

If you're bouncing around memory all the time and it's somewhat random, you're just going to chug through it.

我们来举个例子说明一下什么是内存中的来回跳转。

Let's give an idea of bouncing around memory.

对我而言，链表就是一个典型场景：你有一个数据节点，这个节点指向另一个数据节点，而那个节点又指向下一个数据节点。

A link a link list to me could be a scenario where, right, you have a node of data, that node of data points to another node of data, and that node of data points to another node of data.

而这些数据是何时、如何创建的，决定了它们可能分布在堆中的任意位置，具体取决于它们的创建方式、时间以及连接方式。

And depending on how and when that data was created, that could be almost anywhere, in the heap, depending on how that's getting created and when and how it's getting hooked up.

在这种情况下，你无法保证每个节点都在同一个缓存行上，甚至无法保证它们在相邻的缓存行中。

You can't guarantee in that case that every single node is on the same cache line or even in cache lines that are next to each other.

我想另一个例子是多维数组，对吧？按行遍历和按列遍历的区别。

And I guess another example would be like a multidimensional array, right, iterating over row based versus column based.

是的。

Yeah.

是的。

Yeah.

我们在训练中实际上有一些相关的基准测试示例，可以明显看到性能上的差异。

We actually have some examples in the training with that over benchmarking where you actually see a significant difference in performance.

如果你按行遍历，速度会快得多；而按列遍历则相当于逆着数据的自然顺序进行，效率很低。

If you go row based, you see it's much faster than if you go in column based, kind of breaking the going against the grain.

是的。

Yeah.

不过，这很有趣，对吧？

So it's interesting, though, right?

因为我们通常认为内存是免费的，对吧？

Because we we typically think about memory for free, right?

你知道，我们就像，哦，是的。

You know, we're like, oh, yeah.

它在内存里。

It's it's in RAM.

内存很快。

RAM's fast.

至少我不需要为此访问磁盘。

At least I don't have to go to disk for it.

对吧？

Right?

但是像先列后行或先行后列这样遍历数组的方式，确实很好地说明了访问RAM比CPU缓存慢了多少。

But doing something like column first or row first, iteration over like an array like that, I mean, it really demonstrates the point how much slower it is to go to RAM than CPU cache.

而且随着规模增大，这种差异会愈发明显。

And it really shows its head the bigger that grows.

还有其他因素，仅仅因为我们使用的典型操作系统有——我总是记错这个名字。

And there's other things too, even just because we use typical operating systems have the I always mess up this name.

我想它叫做事务后备缓冲器（TLB），基本上它将程序中的内存地址映射到实际的物理内存地址。

The transaction look aside buffer, I think is what it's called, where basically it maps the address from memory your program has to the real memory, physical memory address.

它也有页表，可能会被换出，然后需要重新加载进来。

And that has pages too that you can blow out, and it kinda has to load back in.

这代价很高。

That's expensive.

对吧？

Right?

所以每次当你因为处理的内存不是相邻位置而导致缓存失效时。

So every time you blow that out because you're you're not working with memory that's located next to each other.

你知道，我对此的兴趣其实是在接触Go语言后开始发展的，因为在此之前，我使用的是C#，我们有列表、队列、栈和各种数据结构。

You know, my interest in this actually started to develop when I came into Go because of from that before that, I was in c sharp, and we had lists, we had queues, we had stacks, we had data structures.

对吧？

Right?

就连 C++ 也给我们提供了所有这些数据结构。

And even c plus plus gave us all these data structures.

当我接触 Go 时，我就想：我的那些数据结构去哪儿了？

And when I came into Go, I was like, where are all my data structures?

我不理解这个。

Like, I don't understand this.

所以我只看到一个数组。

So I I just see an array.

我看到一个切片，当时我根本不懂它，还看到映射。

I see a slice, which I honestly didn't understand at the time, and I see maps.

这其实很可笑，因为我根本没理解切片是什么。

And it's really silly because I didn't really understand what slices were.

我只是觉得它们就是普通的数组。

I just thought they were really just arrays.

在学校里，我们被教导说，数组很难使用。

And back in school, we were really taught that, you know, arrays are difficult to work with.

在刚开始使用Go语言的头几个月里，我实际上避开了切片，转而使用链表，因为我真的不明白为什么我们没有那些数据结构。

And I actually avoided slices for the first couple of months working in Go using linked lists because I I I honestly didn't understand why we didn't have data structures.

但最终，在某个时刻，我意识到大家都在使用切片，而语言本身也在引导你使用切片。

And, eventually, at some point, I realized that everybody's using slices and the language is pushing you towards slices.

于是我意识到，我必须真正弄清楚这到底是什么。

And I figured out I had to really learn what this is.

现在，当你从这个角度回头审视时，切片的底层数据结构其实就是一个数组。

And now when you step back and you look at it from this point of view, I mean, the the underlying data structure for the slice is an array.

对吧？

Right?

切片是Go语言中最重要的数据结构。

The slice is the most important data structure in Go.

随着我每个月都更深入地了解Go语言，我不断发现，Go其实一直在引导我们编写富有同理心的代码。

And as I peel this onion every month about more and more about Go, all I keep seeing is how Go is pushing us towards writing sympathetic code.

Go在无声无息中引导我们去做正确的事。

Go is pushing us towards doing the right things without anybody realizing it.

Go 希望我们使用这些切片，因为这样我们实际上是在操作数组和连续内存，它为我们提供了在不知不觉中与硬件保持协同的最佳机会。

Go wants us to work with these slices because then we're really working with arrays and contiguous memory, and it's giving us our best opportunity to have these sympathies without even realizing that we're being sympathetic with the hardware.

所以就这一点而言，Go 对我来说是一种极其迷人的语言。

So Go to me is just an incredibly fascinating language when it comes to that.

在语言的其他方面也是如此，比如并发层面的操作系统调度器，你也在不知不觉中与之保持协同。

And other areas of the language too where you see that you're really being sympathetic or like the operating system scheduler on the concurrency side without even realizing it.

对吧？

Right?

我们经常告诉人们去做的这些惯用法和做法，并不仅仅是因为。

Just these idioms and these things that we tell people to do all the time, they're they're they're based not on just, hey.

我们希望你这么做。

We want you to do this.

它们基于性能、简洁性、可读性等真实因素。

They're based on real things around performance, simplicity, readability, those types of things.

这一切最终形成了一个完整的循环。

It all kind of comes full circle.

是的。

Yeah.

我认为有很多编程习惯用法可以遵循来提供帮助。

Think there's a lot of programming idioms that can be followed to help.

但我觉得你是对的。

But I think you're right.

我想我从未真正考虑过某些语言功能，它抽象掉了这些东西，并默认使我们的程序更具协同性。

I guess I had never really considered some of the language functionality that, it's abstracting away these, these things and making our programs more sympathetic by default.

通道也是一个很好的例子，对吧？

Channels are a good example too, right?

你知道，你在线程之间传递数据片段，这样数据就可以保留在本地缓存或特定线程上。

You know, you're you're you're passing pieces of data over between threads so that, the data can stay locally on the cache or that particular thread.

或者引用类型呢？

Or what about the reference type?

你的切片、你的映射、你的通道值。

Your slice, your maps, your channel values.

对吧？

Right?

我们总是被告诉，不要共享这些。

We're always told, do not share these.

每个人都可以获得这些值的副本。

Everybody can get a copy of these values.

这样做让我们避免给垃圾回收器带来压力。

And what that's doing is it's allowing us to not put pressure on the GC.

我们可以充分利用栈，因为每个人都可以获得这个切片的副本。

We get to leverage the stacks to the fullest extent because everybody can get a copy of this slice.

真正需要在堆中共享的，只是底层的那部分内容。

The thing that's being shared underneath is what, let's say, necessarily has to be in the heap, just that.

所有这些我们需要在程序边界之间传递的小小对象，我们都可以利用栈。

And all these little objects that we need to pass values around across these program boundaries, we get to leverage the stack.

对吧？

Right?

因为有两个领域我们会想要关注性能。

Because there's gonna be two areas where we're gonna wanna focus around performance.

一个我认为会是关于数据导向设计，以及我们是否对硬件和缓存系统友好？

One will be, I think, around data oriented design and are we being sympathetic with the hardware and the caching systems?

我们是否以最佳方式处理数据？

Are we working with data the best way we can?

另一方面则是，我们能否减轻垃圾收集器的压力，让它不必频繁运行？

And then the other side is gonna be, can we reduce pressure on the on the garbage collector so it doesn't have to run as much?

对吧？

Right?

我认为有两个方面，我们可以在第一天就关注性能问题，尤其是在性能不足的时候。

And these are two areas, where I think we can focus just day one around performance when we're not getting enough of it.

但我总是告诉班上所有人，不要被这些东西搞得束手束脚。

But I I tell everybody in my classes all the time, I go, don't become paralyzed by all this stuff.

你必须先让你正在做的东西运行起来，然后才能分析和衡量哪些是有效的。

You you have to get whatever it is you're working on working first, and then you can profile and and measure what's working.

但性能分析工具非常出色。

But the the profiling tooling is amazing.

对吧？

Right?

你可以看到那些容易解决的问题，然后找出真正值得投入时间的地方。

You can see the low hanging fruit and then look at where you can spend real time.

你的精力应该用在哪儿？

Where does your time need to be?

然后这些工具会帮助你理解：我该如何在这里获得更好的性能？

And then these things kick in to help you understand how can I get some better performance here?

我有没有考虑到缓存系统？

Am I not being sympathetic with the caching system?

我有没有考虑到操作系统？

Am I not being sympathetic with the operating system?

我有没有考虑到垃圾回收器？

Am I not being sympathetic with the garbage collector?

因为我在这里分配了太多不需要的东西。

Because I'm just allocating too much stuff here where when I don't need to.

那数据导向设计呢？

How about the data oriented design?

我的意思是，我理解我们不希望在还不知道需要优化什么、在哪里优化之前就提前最大化性能。

I mean, I understand we don't want to maximize performance ahead of time before you know what you need to optimize and even where you need to optimize.

数据导向设计这个概念呢？

How about the concept of data oriented design?

我很难想象你能设计出一种完全不以数据为导向、却还能正常运行的软件。

I can't totally see you designing your software in a way that is not data oriented, and is to make it work.

你可能会有性能问题，也可能没有。

And you might or might not have performance issues.

但假设你确实有，你知道，你想做一些调整。

But let's say you do, you know, you want to change things around.

在我看来，如果你一开始就没有考虑数据导向的设计方式，那么要做出这些改变将会非常困难。

It seems to me, if you didn't start out thinking about data oriented, that way of doing it, the changes will be so great.

重新做会非常困难，而如果你一开始就以这种方式思考，就不会这么麻烦。

The redoing will be so great versus if you had started out thinking in that way.

我们是否应该这样做，不是为了过早地优化性能，而是因为从数据导向设计开始，是否还能带来超越性能的其他好处，比如代码的可读性、可维护性之类的？

And should we be doing that not so much in terms of let's try to optimize performance too early, but is there are there payoffs of starting out with data oriented design that go beyond performance, maybe just code readability, maintainability, that kind of thing?

Go 是一种面向对象的编程语言，但我不希望人们用 Go 写面向对象的程序，我认为这就是界限。

So Go is an object oriented programming language, but I don't want people writing object oriented programs in Go, and I think that's the line.

如果你在写面向对象的软件，你就没有先考虑数据，而是在考虑所有那些关系。

I think if you're writing object oriented software, you're not thinking about the data first, you're thinking about all of those relationships.

面向对象的编程设计最终往往会形成链表。

Object oriented programming designs tend to create linked lists at the end of the day.

它们就是在做这件事。

That's what they're doing.

在我看来，它们不契合当今硬件的工作方式。

They're, to me, not sympathetic with the way the hardware works today.

对我来说，这关乎尽可能分离你所处理的数据和作用于这些数据的行为。

For me, this is about separating where you can, the data that you're working on and then the behavior that's going against that data.

我是函数的忠实粉丝。

I'm a big fan of functions.

我热爱函数。

I love functions.

当初接触Go语言时，最棒的一点就是我能重新使用函数了。

One of the things that was so great when when I I got got into back, Go was I had my functions back.

并非所有东西都必须作为类的方法存在。

Not everything had to be a method on a class.

而且我认为，当你以‘这是我的状态，这是一些行为’的方式使用函数时，它们也能帮助大幅减少代码量。

And I think functions can also help reduce a huge amount of your code when you're using them in a sense where here's my state and here's some behavior.

我的意思是，方法在Go语言中扮演着非常重要的角色。

I mean, methods play a huge role in Go.

我并不是说你就不会使用方法。

I'm not saying that you're not gonna have methods.

但对我来说，关键在于不要以面向对象的设计模式来架构事物，而是要真正思考：这是数据，这些是操作，这是输入，这是输出，以及如何用最少的代码来实现它？

But for me, it's about not thinking about architecting things in terms of an object oriented designer pattern, but really thinking about this is the data, these these are the manipulations, this is the input, this is the output, and how do I do that with the least amount of code?

数据导向设计这个概念我认为源自游戏编程领域。

And now the data oriented design concept came from the game programming world, I I believe.

是的。

Yes.

而且他们面临的问题也非常相似。

So and a lot of their problems were were similar.

对吧？

Right?

他们需要事情快速发生，因为他们需要高帧率。

They needed things to happen fast because they need high frame rates.

因此，他们尝试以一种方式组织代码，使他们处理的数据在空间上集中在一起。

So they tried to start organizing their code in a manner so that their so that the data that they were working with was spatially located.

他们将经常一起使用的数据分组在一起进行传递，而不是处理对象。

So they grouped the data they worked with commonly together to pass around versus working with objects.

是的。

Yes.

对。

Right.

他们必须在固定的时间内完成若干任务，而时间是不会变的。

They have to do n number of things in x amount of time, and and time is not changing.

对吧？

Right?

所以他们必须让这一切发生。

So they have to make that happen.

因此，是的，他们逐渐意识到，他们必须比任何人都更体贴。

And so, yeah, they they started to learn that if they they had to be even more sympathetic, than anyone else.

但我认为，只要可行、合理，充分利用切片这个概念，就能在你不知不觉中为你带来很多好处。

But I think the slice, the idea of being able to leverage the slice as much as possible, when it is practical, when it is reasonable, is giving you a lot of this without you even realizing it.

这就是我喜欢Go语言的一点：Go语言给了我们所需的东西，并通过说‘我不会给你其他数据结构’来引导我们走向这些理念。

And that's one of the things I love about Go is that Go has given us the things that we need and is pushing us towards these things by saying, well, I'm not going to give you any other data structure.

我只给你映射和切片。

I'm giving you maps, I'm giving you slices.

即使是映射，其底层也在利用连续内存。

Even maps are leveraging contiguous memory underneath.

对于所有引用类型值，如果我们不共享或传递它们，每个人都会得到一份副本。

Then with all the reference type values, if we're not sharing them, or passing them around, everybody gets a copy.

你只是在获得这些东西。

You're just getting these things.

但没错，我想我最早是在迈克·阿克顿2014年的一次演讲中听到这个术语的，他深入探讨了底层细节，有些内容我甚至都看不懂，讲的是他在构建游戏系统时如何利用数据导向设计。

But yeah, I think I heard the term first from Mike Acton on a talk from 2014 where he goes into lower level detail than some of it I can't even understand about how he's leveraging data oriented design, in that gaming systems that he's building.

所以当我们研究这期节目时，我发现了‘伪共享’这个术语。

So when we were researching this show, I came up I found the term false sharing.

这个概念在这个整体图景中是如何体现的？

How does that fit into this whole picture?

没错。

Yeah.

现在我们开始深入到硬件层面了。

So now we're getting really deep inside the the hardware a little bit.

但关键是，由于每个核心都会加载缓存行，如果你有两个线程，分别运行在两个不同的核心上，并且它们操作的数据恰好位于同一个缓存行中，那么实际上你就有了两份该数据的副本——一份在核心一的缓存中，另一份在核心二的缓存中。

But the idea is that because every core is going to be loaded with cache lines, If you have, let's say, two threads, one each running on a different core, working with the same data that happens to be on the same cache line, you now technically have two copies of that data, one in the cache for core one and one in the cache for core two.

因此，即使每个线程只是操作缓存行中的不同字节，你也不会遇到并发问题。

And so you don't really have, let's say and even if each thread is working with a different byte on each cache line, you don't have a concurrency issue there.

你也不会有数据竞争的问题。

You don't have a data race issue.

但你确实会遇到一种情况：同一份数据被重复存储在两个不同核心的缓存中。

But you do have a situation where the same data is now duplicated inside of a cache for two different cores.

而虚假共享正是由此产生的。

Now the false sharing comes in because of that.

从你的角度来看，这其实是‘虚假’的共享，因为你并没有真正地共享数据。

It's false you don't really from your perspective, you're not really sharing data.

但从硬件的角度来看，这些数据确实被共享了。

But from the hardware perspective, this data is being shared.

虚假共享的问题并不源于读取操作，因为如果你只是读取数据，问题只会在数据被修改时出现——一旦某个核心上的线程修改了该缓存行中的任何数据，所有其他核心中该缓存行的副本都会被标记为无效。

The problem with fault sharing doesn't come from reading because if you're reading data, I mean, it's it's when that data gets mutated because as soon as one thread on one core mutates any data in that cache line, all other copies of that cache line in all other cores now have to be considered dirty.

当另一个线程想要操作该缓存行时，它的缓存行副本是脏的，此时你必须等待新的缓存行版本加载进来。

And when that other thread goes to do something on that cache line, its own copy of the cache line, and it's dirty, you now have to wait for a new version of the cache line to come in.

这可能会导致性能问题。

That can create performance problems.

Scott Myers 举的一个例子是，有人创建了一个全局的计数器数组。

An example that Scott Myers uses is that somebody's created a global array of counters.

这些计数器全部位于同一个缓存行上，假设共有16个计数器，你启动16个线程，每个线程获取该缓存行上的一个独立计数器索引，且每个线程都运行在独立的核心上。

So all of these counters, let's say there's 16 counters all on the same cache line, and you launch 16 threads, each thread getting its own index of counter on this cache line, and all 16 threads getting their own core.

现在，这个缓存行和其中的计数器在每个核心中都拥有了16份副本。

We now have 16 copies of this cache line, of these counters in every single core.

每当一个线程写入并递增其计数器时，其他15个缓存副本都必须被标记为脏。

And every time one thread writes, increments its counter, all other 15 other caches now have to be marked as dirty.

你正在频繁地访问内存，因为每个线程对其计数器执行自增操作时，都会迫使其他所有线程等待其缓存行副本被更新。

And you're chugging through memory because every thread that does a plus plus on their counter is causing every other thread now to have to wait for their copy of the cache line to get updated.

这正是伪共享的真正含义。

So that's really what default sharing is all about.