译者谢宝友 下午10:01
But why can’t CPU designers simply ship
the addition operation to the data, avoiding the need to circulate the
cache line containing the global variable being incremented?
但是CPU设计者为什么不简单的将额外的操作与被操作的数据打包，以避免在所有CPU间传播缓存行的需求，该缓存行包含要递增的全局变量？
译者谢宝友 下午10:01
这样翻译怎么样？@郭健
鲁阳 下午10:03
这里的addition不是额外的意思，就是指增加
鲁阳 下午10:03
自增指令
译者谢宝友 下午10:03
对的，递增操作
译者谢宝友 下午10:07
Shipping operations among CPUs will likely require more lines in the system
interconnect, which will consume more die area and more electrical power.
如果在CPU之间传递相应的操作，那么在系统互联模块中，极有可能需要更多连线，这些连线将消耗更多的布线面积，并且将消耗更多电量。
译者谢宝友 下午10:08
@译者鲁阳，请检查一下
译者谢宝友 下午10:09
@译者鲁阳，请检查一下5.10小问题的问题和答案，感觉原来的翻译不大对。
鲁阳 下午10:32
好的
郭健 下午11:58
@码农谢宝友 我自己再理一理，总感觉逻辑没有那么顺畅。
译者谢宝友 上午7:03
5．10这个问题，是一个槛
译者谢宝友 上午7:04
我会详细解释它
译者谢宝友 上午7:05
上午我用电脑上微信来解释
鲁阳 上午8:27
问题5.10 But why can’t CPU designers simply ship the addition operation to the data, avoiding
the need to circulate the cache line containing the global variable being incremented?
但是为什么CPU设计者不能简单地把自增指令传给数据？这样就不用将待自增的全局变量所在的缓存行来回传递了。
鲁阳 上午8:27
这样更正，更方便理解。
ZP 上午8:33
问题5.10 But why can’t CPU designers simply ship the addition operation to the data, avoiding
the need to circulate the cache line containing the global variable being incremented?
但是为什么CPU设计者不能简单地把自增指令传给全局变量？这样就不用将其所在的缓存行来回传递了。 如何？
鲁阳 上午8:33
5.10答案部分的疑惑，主要是那三个条件：
1. If the value of the variable is required, then the thread will be forced to wait for
the operation to be shipped to the data, and then for the result to be shipped back.
如果需要获取变量，当前（硬件）线程必须等待数据收到指令，然后再将操作结果发送回来。
2. If the atomic increment must be ordered with respect to prior and/or subsequent
operations, then the thread will be forced to wait for the operation to be shipped
to the data, and for an indication that the operation completed to be shipped back.
如果原子递增操作必须与其前后的操作按某种顺序进行，当前线程不仅必须要等待数据收到指令，还要等待操作完成的通知返回
3. Shipping operations among CPUs will likely require more lines in the system
interconnect, which will consume more die area and more electrical power.
在CPU间传递指令很可能需要系统互联模块增加更多电路，这将占据CPU核内更多的空间，并且消耗更多电能。
鲁阳 上午8:35
这样说确实更精练。我小改几个字：但是为什么CPU设计者不能简单地把自增指令传给那个全局变量？这样就不用将它所在的缓存行来回传递了。
译者谢宝友 上午8:36
请等一下
译者谢宝友 上午8:36
我觉得不能说将指令传给全局变量
译者谢宝友 上午8:37
“传”的意思，表示消息只包含Add指令
译者谢宝友 上午8:37
相信大家对这个问题本身已经了解，在正式讨论前，先啰嗦两句题外话
ZP 上午8:40
下发？
译者谢宝友 上午8:43
1、这个问题体现了本书一个特点，正如冯博群大侠在推荐语中所说：阅读本书的小问题，会使并行编程变得更容易。
2、这个问题本身是本书第一个槛，不管是译者还是读者，甚至是作者本人，也许都会在这个槛上面遇到小麻烦，这是正常的。
3、这个问题和斯坦福大学的《数据库实现》一书里面类似，问题或者习题很难，需要读者翻阅不少的参考资料才能得到答案，或者看懂作者所给出的答案。否则连看答案都困难。但是正如作者所说，这实际上是国外教学的一个优点，值得我们国内大学教学参考：如何启动学生提出有价值的问题，并且动手去解决？毕竟“educate”一词，从词根的意思来说，就是把学生的什么东西拉出来？
译者谢宝友 上午8:45
顺便我在这里也抛出一个问题，把大家的什么东西也拉出来一下：）一个关于Caches的问题。读者需要先看看@陈莉君 老师的《深入理解Linux内核》一书，温习一下内存着色问题。
译者谢宝友 上午8:47
问题：着色功能最初的设计目的是什么？它会有什么预期的好处，为什么？实际上达到预期效果没有，为什么达到或者没有达到预期的效果？它可能会有什么坏处？新版本的内核还有没有着色功能，为什么有，为什么没有？
驴肉火烧 上午8:48
这些问题好[强]
译者谢宝友 上午8:49
接下来我说一下我对这个问题的理解，再强调一次，这个问题需要对芯片有一定的了解，Paul本人的答案，也许是咨询过硬件工程师才给出来的，所以问Paul的话，他也许不能立即给出让大家满意的答案。当然，我也不一定能给出好的答案，也许我的答案就是错的呢？？
译者谢宝友 上午8:50
幸好这两年，我在芯片公司工作，偶尔从芯片工程师那里“偷”了一点硬件知识：）
译者谢宝友 上午8:52
实际上，5.10这个问题，和MESI消息传递有关。这里的问题，正如答案所说，实际上是值得芯片设计公司好好考虑的问题，也许就是一个优化点。
鲁阳 上午8:52
老谢这个问题有深度，让我思考思考。
HeJie 上午8:53
[表情]
译者谢宝友 上午8:55
在上下文中，作者已经提到：一个原子自增指令，可能会消耗上千个CPU执行周期，这导致并行编程的困难。其根本原因是原子自增指令，需要通过系统互连模块，向所有CPU核发送“读使无效”消息，这会形成一次MESI消息风暴，导致所有CPU核的“抖动”，影响其他CPU的性能（这是真的，迫不及待的读者可以看一下《并行实时计算》一章）。
译者谢宝友 上午8:55
所有CPU核收到“读使无效”消息后，会向发出这个消息的CPU回复一个“读使无效响应”消息
译者谢宝友 上午8:56
这又会形成一次消息风暴
译者谢宝友 上午8:57
为了避免这些消息风暴，会给硬件工程师带来不少的挑战，也许现在，某个ARM芯片设计师正在考虑如何优化这些消息风暴呢[Grin]
宇宙超人 上午8:57
[发呆][发呆][发呆]
译者谢宝友 上午8:57
当大家有这些知识作为垫底以后，就能够理解作者的问题和答案了
译者谢宝友 上午8:57
==，我接一个电话
译者谢宝友 上午9:02
作者抛出的问题，或者说芯片设计师能够优化的一点，就是：当前执行ADD操作的CPU，其实不必发送“读使无效”消息并等待其响应，它只需要将要Add的值，以及被Add的全局变量地址“打包”（注意不是传递），作为一个MESI消息广播出去（注意，广播一条消息是无法避免，因为不知道当前哪一个CPU拥有这个全局变量的缓存，换句话说，不知道哪个CPU的相应缓存处于Owner状态）
译者谢宝友 上午9:05
接收到该消息（此时不是“读使无效”消息了，我们暂且称之为Add打包消息）的CPU，检查自己的缓存状态，如果该全局变量正好被自己“拥有”，那么就由它代为执行Add指令，并且继续拥有此缓存行，最终的后果是：真正执行Add指令的CPU，它继续拥有缓存行，避免了缓存行在CPU之间的颠簸，并且“所有”CPU都可以避免发送“读使无效”消息的“响应”，相当于将整个总线的拥塞程序降低一半。
译者谢宝友 上午9:05
我不知道这样解释以后，大家能不能看懂问题和答案
鲁阳 上午9:06
大家可以跳个顺序，先把附录C看一下，这样就不会对书中很多默认读者知道的背景介绍感到迷惑了。
译者谢宝友 上午9:07
再补充一点：这些MESI消息不可避免的原因，就在于光速的限制，CPU没有办法在一个CPU指令周期内，将所有指令所影响的结果通知到所有CPU
译者谢宝友 上午9:08
大家先看一下附录C中的背景知识。否则会被5.10这个问题KO
郭健 上午9:10
@码农谢宝友 @译者鲁阳 多谢，多谢，已经明白了，还好我有一点点cache coherence的基础[呲牙]
译者谢宝友 上午9:10
@译者鲁阳，请把答案改一下，翻译确实有不太正确的地方，我想强调的是，Paul本人也许也会错误，大家不要强求。
译者谢宝友 上午9:11
我能答复一点，是因为我大概将本书看了5遍，并且可以和公司里面的硬件工程师随时讨论。
译者谢宝友 上午9:11
@郭健，能听明白的，都是牛人：）
孟德国 上午9:11
[强]
译者谢宝友 上午9:12
没听明白的，也很正常
孟德国 上午9:12
具体的MESI可以不知道，但是你讲的过程很明白了
译者谢宝友 上午9:13
@孟德国?[表情][表情]
译者谢宝友 上午9:14
所以我想对@博文视点符隆美?@张国强?说
译者谢宝友 上午9:14
这本书很难找到合适的审阅者呢：）
译者谢宝友 上午9:15
也许@郭健 兄比较合适，他满足几个条件：
1、有深厚的技术功底
2、对本书有感情
3、一线工作多年
郭健 上午9:18
@码农谢宝友 客气客气，老谢同学，其实这两天都加班加点的审阅呢[呲牙]，就等着这个月靠勘误红包存点私房钱呢[呲牙]
鲁阳 上午9:19
答案这样修改，我相信会更容易理解。
5.10答案：
1.如果当前（硬件）线程需要获取变量的值，必须等待（缓存中的）数据收到操作指令，之后还需等待操作的结果通知回来。
2.如果原子递增操作必须与其前后的操作按顺序进行，当前线程不仅必须要等待数据收到操作指令，还要等待操作完成的通知返回。
3.在CPU间传递指令很可能需要系统互联模块增加更多电路，这将占据CPU核内更多的空间，并且消耗更多电能。
译者谢宝友 上午9:20
问题也可以考虑修改一下
鲁阳 上午9:21
即使有不了解的，只要坚持到本书的后半部分，也会有恍然大悟的感觉。对于经典来说，“读书数遍，其义自见”。
译者谢宝友 上午9:22
3.在CPU间传递指令很可能需要系统互联模块增加更多电路，这将占据CPU核内更多的空间，并且消耗更多电能。
电路->连线
占据CPU核内更多的空间->增加更多CPU流片面积
这个更符合硬件工程师的习惯
鲁阳 上午9:23
问题5.10：但是为什么CPU设计者不能简单地把自增指令发送给数据？这样就不用将数据所在的缓存行在CPU之间来回传递了。
译者谢宝友 上午9:24
流片面积增大的后果，是增加了流片成本，带来布线的困扰，消耗更多的电量，所以说是一个需要硬件工程师仔细权衡的优化手段
鲁阳 上午9:24
OK，我对硬件术语不是特别了解。如果这样可以让大家易于了解，那就这样改。
译者谢宝友 上午9:25
@译者鲁阳，问题中，不要用“发送给数据”，而是将“指令与数据打包”，注意打包这个词的用法
孟德国 上午9:25
我还没有读完这本书，但是我觉得 读懂这本书要求一定的计算机体系结构的积累，仔细读过计算机体系结构量化研究方法又仔细看过ARM 体系结构TRM的同学 应该觉得还好
译者谢宝友 上午9:26
@孟德国，如果要完全读懂当然需要这样，但是如果没有这些底蕴，那么就可以考虑简单的略过这些小问题。没有这些小问题，也会学习到不少的知识。
孟德国 上午9:26
嗯
雨润万物 上午9:27
这本书需要读多遍
鲁阳 上午9:28
其实不要被老谢带偏了，这本书对于纯软件开发者来说也是很有用处，毕竟并行编程在操作系统/系统软件/应用软件上都是大量应用，这里面讲的很多原则都是不限硬件架构的。
从本书的组成篇幅也可以看出来，硬件只占一小部分内容，更多的是从代码的角度考虑如何更好地实现并发。
译者谢宝友 上午9:28
对头
译者谢宝友 上午9:28
只不过刚才这个问题，正好与硬件紧密相关而已，这个问题是留给“大内高手”看的：）
鲁阳 上午9:29
看到小问题，最好不要马上看答案，想不明白，带着问题思考也好。
周文嘉 上午9:29
@译者鲁阳?我看这本书的一个目的就是为了更好的理解同步和并发[呲牙]
译者谢宝友 上午9:30
@李晓辉，可惜了，刚才你错过一个非常精彩的问题讨论，比损失一个亿的红包还可惜
李晓辉 上午9:31
哎，我现在做嵌入式了，之前做服务器内核调查，不过嵌入式 也能望内核方向靠
李晓辉 上午9:32
把刚才的讨论 贴到你的博客网站上吧，你的人气会再飙涨的
鲁阳 上午9:32
我日常的工作是开发分布式数据库，节点之间的消息传递也可以想象是一块CPU的放大版，翻译这本书对我的工作有很大帮助。
鲁阳 上午9:34
CPU之间协调缓存一致性的MESI协议，和分布式系统的raft协议有异曲同工之妙
郭健 上午9:35
@李晓辉 放心吧，我有记录的，上次不是整理了一些微信群讨论的问题吗？下一次整理的问题会包括这个群讨论的一些精彩内容。
译者谢宝友 上午9:35
@译者鲁阳 翻译完本书后，就被VoltDB录用了，这家公司可是图灵奖得主创办的哦，可以近距离接触顶尖牛人
李晓辉 上午9:35
好的，最好出本书，呵呵
鲁阳 上午9:36
这个作为参考材料，有兴趣的同学也可以看看。
译者谢宝友 上午9:36
而且现在他在VoltDB挑大梁了，我想可能也和他翻译本书有关。VoltDB目前也大量用于国内招行。
puckCC 上午9:36
@郭健?[表情]看郭大侠的整理一定有更多额外收获
Newbie Rock 上午9:37
两位作者的头像能不能有点差异？看着聊天记录，晕菜了
译者谢宝友 上午9:37
@郭健，你的群里有不少高价值的讨论知识点，别忘了在我们群里也分享一下文档。
郭健 上午9:38
@码农谢宝友 OK
鲁阳 上午9:40
如果群里的同学有使用招商银行信用卡的，无论是你刷实体卡，还是微信上用招行卡支付，小菊花转的那一瞬间，背后都是VoltDB在进行风险监测，延迟不能超过50ms，招行调研了大量数据库，只发现VoltDB能做到这点。
