弯曲评论荣誉出品：《浅谈Cache Memory》

作者陈怀临 | 2011-10-04 21:48 | 类型专题分析, 学术园地, 科技普及 | 93条用户评论 »

分享分享到：新浪微博腾讯微信开心人人 Live Digg FB Twitter 分享
(13个打分，平均：4.92 / 5)

工具箱
本文链接 | | 打印此页 | 93条用户评论 »

雁过留声

“弯曲评论荣誉出品：《浅谈Cache Memory》”有93个回复

kevint 于 2011-10-04 11:49 下午

Latency Improvement2 ≤ Bandwidth Improvement

这个公式似乎跟现实有些出入。拿DDR,DDR2,DDR3.bandwidth翻倍，latency从绝对时间上看似乎没变
kevint 于 2011-10-04 11:54 下午

读这种东西比读WLRU那种毒草要舒服多了。
拜王大师
Farmland.Power 于 2011-10-05 12:30 上午

终于等到王齐大侠的传世佳品了。一定仔细研读。
Red 于 2011-10-05 2:48 上午

Latency Improvement2 ≤ Bandwidth Improvement
从以上公式可发现，延时在以平方增长，而带宽以线性增长。

这个说法貌似有点不妥吧。延时应该是缩小而不是增长。并且这个公式想说明延时和带宽之间性能提升的关系，说明带宽增长速度比延时缩小速度的平方还要快。并不存在个体“平方增加”、“线性增长”。
pingzo 于 2011-10-05 6:34 上午

王大侠的pcie体系结构导读正在学习研究中，个中内容真是让人受益匪浅啊，一定好好拜读下
张帆于 2011-10-05 6:43 上午

读完这篇文章，我仿佛不知廉耻的看到了多年后的自己。

作者的这份不计回报的真诚与踏实让我感慨，更是赞赏于那份隐藏在字里行间的飞扬文采。

我脱帽致敬！
张帆于 2011-10-05 6:46 上午

我用词欠考究，其实没有读完，甚至更没有细读。。弯曲应该加个评论编辑的选项，让我这样粗心的人有改正的机会。。。
James 于 2011-10-05 7:15 上午

很多时候我们的都有写一些东西的冲动, 但是霎那的冲动平息后,我们发现要想完成这些冲动尚需不少的精力. 琐碎的生活使得我们精疲力竭, 于是大多时候我们选择了放弃.

向作者致敬.
28纳米 于 2011-10-05 8:14 上午

神作，准被彻夜拜读
理客于 2011-10-05 8:38 上午

王齐是一代侠客，侠客为什么要行侠呢？因为他们是侠客。如果有人有要写点东西的冲动，就立刻写下来，其实什么也不为，就像母鸡下蛋一样，只是母鸡下蛋是一定要下出来的，而写作的冲动如果错过了，就平息了，忘了，没有了，像爱情冲动一样，当你没有勇气表白的时候，爱情就可能过去了，永远过去了，什么可以超过光速，是情感的来去，意念的变更，如量子纠缠一般的瞬间
好文于 2011-10-05 9:41 上午

wangqi等人的文章确实有料，虽然Latency Improvement2 ≤ Bandwidth Improvement
还有待斟酌，但瑕不掩瑜，佩服佩服。
还有，那个理客，怎么每个帖子都要发些乱七八糟的话，轮子附体还是洗脑过头？说点有意义的，行嘛？
理客于 2011-10-06 1:14 上午

人在江湖，有时难免看到江湖的池子浅庙小
somebody 于 2011-10-06 3:27 上午

四大皆空，哪来的脾气？
理客于 2011-10-06 3:59 上午

地球上总是有人擅长川剧变脸一样不知道什么时候一不高兴会就不管地方让自己肚子很快从上面空了，他们会觉得这样才能很有high气
几楼楼长 于 2011-10-06 7:15 上午

Latency Improvement2 ≤ Bandwidth Improvement 这个很对啊

这篇NB文章对我这个菜鸟来讲太多太深了，只能领略其中浅显的部分。

还是首席写的浅显易懂，一个page coloring用了5篇帖子，翻来覆去的讲，让你不懂都不行。
sailing 于 2011-10-07 4:55 下午

文章尚未完成，目前是0.01版。出现三级目录后是0.1版，之后等待大范围的Review，1.0版需要等待很长的时间。

对本文的任何建议，哪怕是一个错别字，也不胜感激。我的Buzz，Email，各类聊天工具的帐号都是gmail的sailing.w。

Latency Improvement2 ≤ Bandwidth Improvement这个公式被很多权威Cache文章提出过。Latency是一个相对的概念，最好是使用CPU Cycle进行计数，不要使用绝对的时间。
这个公式的背后的含义是条件为真时即为一次成功的Latency和Bandwidth间的Trade-Off。

我不准备写大白话，这个首席擅长。中文世界里我见过的文章，都很难超越首席的这些文字，我也就不再尝试了。
陈怀临 于 2011-10-07 6:17 下午

Heeee.贤弟辛苦了。。。Good job！
leviathan 于 2011-10-07 11:16 下午

三个作者认识俩，此生无憾了！！！虽然看不懂的说…

PS，@首席：我一兄弟前几天去你的公司面试了，给了offer，世界很小啊哈哈
xux 于 2011-10-10 12:53 上午

万木杨需要向这位前辈学习学习了
Ma Ling 于 2011-10-10 12:55 上午

“与Nehalem 微架构在一个Cycle 中只能执行一条128b 的Load 和Store 指令[1][12]相比，
Sandy Bridge 微架构在一个Cycle 中可以执行两条128b 的Load 和一条128b 的Store 指令，”
错了，SNB一个cycle只能执行 1 load, 1 store 或者 2 个 load.
Ma Ling 于 2011-10-10 1:11 上午

“这些飞翔的指令无序，而且指令流水线会让最笨的鸟尽可能的提前飞翔”
请问这个观点出处？是paper还是有cpu实现.
Ma Ling 于 2011-10-10 1:16 上午

无序执行不需解释，我很想知道笨鸟先飞从哪来，因为指令的延迟基本上从 reserve station发射的时候无法预测。
sailing 于 2011-10-10 7:41 上午

仔细查了一下，SNB一个cycle只能执行 1 load, 1 store 或者 2 个 load.是对的。L1 DCache有两个128b的read和一个128b Store every cycle.多谢，已将您加入本书的Contributor List。希望更多的人能够帮忙修改。这些改动将出现在0.02版，还有很多很多工作要做。

笨鸟先飞发生在Load Speculation。因为一次读过程由AGU，LSU和ALU联合完成。我的笨鸟先飞指Load Speculation可以在AGU没有完成前即可预测执行。
另外如果考虑Out-of-Order Issue架构，可能后面的指令先Issue出去。
这些说法在概念上比较模糊，有些随手，确实不够严谨，再次感谢您指出的这些问题。
sailing 于 2011-10-10 7:43 上午

另外大家有什么可以做文档管理的Version Control工具吗？
理客于 2011-10-10 8:40 上午

专门针对文档的倒是没见过，多是代码文档都可以管理的，常用的有开源的CVS、微软的source safe和IBM的rational clear case，其他Google一下应该还有很多，N年前做过版本管理员，知道一点
x86门外汉 于 2011-10-10 8:43 上午

数据口有3个128位， 2*128 load + 1*128 store.
但地址端口只有2.每周期只能有两。。。。。
x86门外汉 于 2011-10-10 8:44 上午

out了吧，

opensource流行git
Ma Ling 于 2011-10-10 6:04 下午

“我的笨鸟先飞指Load Speculation可以在AGU没有完成前即可预测执行。”
我的理解是因为load的地址与前面的store的地址没有清晰辨别前，我们仍然发射load操作，很多正规叫法称为memory disambiguation,现在cpu也不会使用bi-modle的预测发法，load提交前检查一下store buffer就好了。
在cpu中所有 load 操作都可以 out of order,
所有的 store操作都毕业 in exeution order.
由于精确异常和miss branch predication 的要求他们所有指令的提交都必须 in program odrer。

只看了一点，感觉写的很好，恕我直言有些细致的地方还有偏差，如果有时间我再吹毛求疵的提出些意见。
xux 于 2011-10-10 6:41 下午

学习中。。。

学习中。。。
multithreaded 于 2011-10-10 7:29 下午

料很多、很深。但不知读者对象如何考虑的。我的感觉是：如果一个人没有把ref[7]读十遍以上的话，无法理解本书的内容。好像是给体系结构PH。D 读的,大宋顶尖级学校的的MS学生很难读下来。

建议还是把memory和cache分开吧。能把cache coherence写好已经是一件了不起的事。比如讨论一下，cache 和NIC上DMA的关系。这个坛里做networking的人很多，这个话题容易引起共鸣的。

最后，ref[34] and [96] 重复了。 Hebert Hum would be smile if he knew it
sailing 于 2011-10-11 7:07 上午

multithreaded您的名字是什么，我目前只能用multithreaded作为名字加入到Contributor List中，已加入，感谢万分。今晚还有一堆事情要处理，来不及说更多的了。
flyfish30 于 2011-10-11 5:03 下午

可以用git作文档的版本管理挺不错的，如果用latex写文档，还可以让其他人象提交patch一样提供修改。
ASR2K 于 2011-10-11 8:07 下午

只能说，做通用CPU，真TNND不容易哟。看得我直叹气。
Ma Ling 于 2011-10-12 1:58 上午

“存储器写在Commit之前也如存储器读一样自由，而且在多数情况下写操作也需要首先读取数据，之后进行数据合并，然后进行真正的写操作”
有问题。写操作在pipeline的执行过程不会touch cache, 只是提交的时候把数据写入 store buffer, 然后由store buffer来完成 read-for-ownership的操作，这样做的好处是可以将写操作的latency变成beckend work，所以说写在store buffer不满的情况下，比 load 操作快。
sailing 于 2011-10-12 3:25 上午

写操作在pipeline的执行过程不会touch cache, 只是提交的时候把数据写入 store buffer, 然后由store buffer来完成 read-for-ownership的操作。呵呵，这个说法也正确，马上改正。
sailing 于 2011-10-12 3:28 上午

今天和人讲课时，也是这么说的，写的时候反而错了。

Ma Ling，感谢您能抽出时间，不断的指出错误。
sailing 于 2011-10-12 3:33 上午

估计还有Load和Store指令的类似错误，我会在0.02版在仔细检查一下。对了Ma Ling你有其他的聊天工具如Buzz和Gtalk，这样我在改写有疑惑的时候，可以和您直接讨论。
我的都是Google的sailing.w
Ma Ling 于 2011-10-12 4:09 上午

email: ling.ma.program@gmail.com
您客气，我也是在学习,希望这本书能提出些挑战的题目，比如由于power的问题我们需要缩减 branch history table而不影响性能,我们需要考虑突破rename 的 n^2-n的限制,为什么我们cpu指令不可以out of program order retire,虽然这样做会对性能有很好的帮助（至少GPU已经这样做了），以及hybrid cache 的研究,,,

Thanks
Ling
三千大千世界 于 2011-10-12 8:08 上午

刚刚拜读完大话处理器，再来读这篇文章还是比较费劲，ref太多了。
processor 于 2011-10-12 10:04 下午

Re:34,35,

store操作在提交前是否touch D$，这个各家的uarch设计不一样，也有在提交前probe D$的，这样做的好处是可以尽早知道是否D$ miss，如果有miss尽早进行D$ refill。

另外，感觉sailing文章中以AMD K8的设计做例子讲解LSU有点过了，K8的LS1,LS2设计挺复杂的（或曰比较先进），如果文章是面向cs方向的大众读者（而非专业processor研发人员），那可能反而不容易让读者了解掌握LSU的运行原理。
Ma Ling 于 2011-10-12 11:54 下午

请举例说明现代cpu哪一款是这样操作.
写操作不touch cache可以尽快提交，把复杂的操作变成 back end work 不占用cpu的执行时间。
sailing 于 2011-10-13 5:46 上午

store操作在提交前是否touch D$，这个各家的uarch设计不一样，也有在提交前probe D$的，这样做的好处是可以尽早知道是否D$ miss，如果有miss尽早进行D$ refill。

这个我同意Ma Ling的观点，Store在Commit前不应该Probe Cache，除了学术领域中可能有模拟CPU可以做这样的Probe Cache，具体实现中，至少我没有发现这些的微架构。

不过这个观点可能依然可以研究，有具体的量化分析数据更好了。可能这种方法对某类应用，会强于不Probe Cache。有待研究。
processor 于 2011-10-13 8:27 上午

以Alpha 21264为例，参考文献及出处为：
Alpha 21264/EV67 Microprocessor Hardware Reference Manual
http://www.compaq.com/alphaserver/technology/literature/21264hrm.pdf

其中有如下描述：

Stage 6 — Dcache Access
Memory reference instructions access the Dcache and data translation buffers. Normally load instructions access the tag and data arrays while store instructions only access the tag arrays. Store data is written to the store queue where it is held until the store instruction is retired. Most integer operate instructions write their register results in this cycle.

Store操作将源操作数写入D$ data array是在commit(retired)后，但是在这之前需要访问D$ tags以判断是否D$ miss。如果等到commit后再查询D$ tags判断是否D$ miss，这时如果真有miss，那么refill完全串行了。如果在store操作提交前查询D$，在发生miss时进行refill，这样当store操作提交时，refill可能已经完成。
sailing 于 2011-10-13 5:18 下午

Hi processor，

Store指令执行时，都会写入到Store Queue中，这个没有争议。

是否是在Commit时写入到Store Queue(1)，还是写入到Store中并等待，然后在Commit后可以离开(2)，是一个Trade-Off。
方法(1)的优点是Store Queue可以做的很长，不会丢弃了，但是将浪费一个Cycle。
方法(2)的优点是节约一个Cycle，但是因为Speculation的原因，在某些场合需要丢弃在Store Queue中的指令重新执行。在实现中Store Queue与Cache设计类似，并行查找需要使用CAM，所以不能很长。
还有一个问题是一个CPU在进行Hold and Probe Cache行的过程,丢弃的实现并不易，尤其在很多个CPU同时做Coherency的时候。Refill已经完成，但是会污染Cache。

但是如果丢弃的概率很低的话，依然是一个好的Trade-Off。采用方法(2)可以至少节约一个Cycle，Cache Miss时节约的更多。但是要看Miss的概率。

所以我现在觉得两种都可以。而采用哪种方法，依然需要数据支撑。我怎么觉着我的书籍中一直说的都是第2种方法，没有说过第1种说法。

这周的思路都在网络报文的处理中，下一周切换到流水线中，再多看一些实现继续讨论。这篇文章在涉及流水线时很多地方不够严谨。

我觉得应该找个更好的讨论这些问题的地方。比如找个专门的时间，通过实时聊天工具，更好一些。这样讨论延时太长，太乱。严重污染弯曲评论空间。

Processor已将您加入Contributor List。

Sailing
sailing 于 2011-10-13 5:19 下午

还有首席是不是应该加上一个修改功能？有时候即使是简单的笔误也该不过来。
陈怀临 于 2011-10-13 6:19 下午

应该可以吧？不能回去修改？
Ma Ling 于 2011-10-16 12:53 上午

processor: “如果等到commit后再查询D$ tags判断是否D$ miss，这时如果真有miss，那么refill完全串行了”
CPU从 store buffer提交数据的时候如果是write back cache 他必须保证store in order 应该就是你谈到的串行refill，所以无所谓miss or not, store buffer 都要进行FIFO 操作进入 cache.

sailling:
写入 sotor buffer的操作是在pipeline中完成，store 指令不仅要向store buffer写入数据同时还包括要写入cache的地址，最后指令提交的时候会把这个store buffer 至为 avaialble，同时sotre指令retire from pipeline,store buffer 会负责把数据写入cache in porgram order.
processor 于 2011-10-16 4:12 上午

Re:47
>>”CPU从 store buffer提交数据的时候如果是write back cache 他必须保证store in order 应该就是你谈到的串行refill，所以无所谓miss or not, store buffer 都要进行FIFO 操作进入 cache.”

Hi Ma Ling,
Store操作在commit后写D$ data array时，需要待写的数据字节（对于普通的定点写操作，通常1～8字节）所在的cache line在D$中。我43文中提到的”那么refill完全串行了”是说如果写操作在commit后再去probe D$ tags，这样如果待写数据所在cache line不在D$中(miss)，那么该cache line refill过程与写操作在store buffer中等待提交的过程就完全serialize了（虽然LSU的设计与memory ordering密切相关，但在这里我指的不是sequential consistency中的串行；也不是为了保证精确例外而需要指令按序提交的串行）；如果写操作在AGU流水级后（这时得到了x86中的linear addr，其它arch 中virtual addr）就去probe D$ tags (写操作这时不去碰D$ data array)，则如果发现有D$ miss，可以马上开始回填cache line的过程（通用的、不针对具体处理器uarch的说法，是在MSHR中进行cache line refill），这时该写操作可能尚未commit，或者已经commit但尚未到store buffer的队头，总之这样可以将D$ refill的时间与写操作等待到达store buffer对头（最终写入D$ data array）的时间overlap起来。

除了Alpha 21264，AMD Opteron执行写操作时也是在commit前probe D$。在专利6,473,832“LOAD/STORE UNIT HAVING PRE-CACHE AND POST-CACHE QUEUES FOR LOW LATENCY LOAD MEMORY OPERATIONS”中对LS1/LS2的逻辑进行了较为详细的描述。由于该专利与Opteron研发人员发表在IEEE MICRO杂志上的文章“The AMD Opteron Processor for Multiprocessor Servers”在关于LSU的内容部分大体吻合，所以该专利描述的内容很可能与Opteron实际的uarch设计类似。Opteron的load/store unit内部分为LS1(pre-cache buffers)和LS2(post-cache buffers)。LS1保存尚未probe D$的访存操作，而LS2保存已经probe D$的访存操作。以下是专利中关于LS1流水线的描述：

“Turning next to FIG. 4, a timing diagram is shown illustrating an exemplary pipeline for a memory operation probing data cache 28 from LS1 buffer 60. …此处省略xxx字…”

“Clock cycle CLKO is the decode/dispatch cycle for an instruction specifying the memory operation. During clock cycle CLKO, the decode unit 20 decoding the instruction signals load/store unit 26 regarding the memory operation. LS1 control logic 64 allocates an LS1 buffer entry for the memory operation during the decode/dispatch stage for the corresponding instruction. Additionally, the decode unit 20 transmits the decoded instruction to the corresponding reservation station 22.”

“During clock cycle CLK1, the address generation unit generates the data address for the memory operation and transmits the data address to load/store unit 26. During this clock cycle, the memory operation participates in the scan performed by LS1 control logic 64 (by virtue of the data address being provided) and is selected to probe data cache 28. … …”

“During clock cycle CLK2, the data address is transmitted to data cache 28. As illustrated by the arrow within clock cycle CLK2, the memory operation is moved from LS1 buffer 60 to temporary buffer 68 at the end of clock cycle CLK2. The memory operation is in the address to data cache stage of the LS1 pipeline during clock cycle CLK2.”

“During clock cycle CLK3, the data address accesses data cache 28. Data corresponding to the memory operation (if the memory operation is a load) is forwarded at the end of clock cycle CLK3. Additionally, the memory operation is moved from temporary buffer 68 to LS2 buffer 62. The memory operation is in the cache access stage during clock cycle CLK3.”

“During clock cycle CLK4, …此处省略xxx字…. the memory operation is in the response pipeline stage during clock cycle CLK4. Data cache 28 provides hit/miss information and the physical address during the response stage. Accordingly, LS2 control logic 66 associates hit/miss information and the physical address with a memory operation in the response stage.”

“During clock cycle CLK5, the memory operation is in a response2 pipeline stage. During this stage, the miss address buffer tag identifying the miss address buffer entry assigned to the cache line accessed by the memory operation (if the memory operation is a miss) is provided by data cache 28. Accordingly, LS2 control logic 66 associates a MAB tag received from data cache 28 with a memory operation in the response2 stage.”
Ma Ling 于 2011-10-16 7:29 上午

好的，让我看看这个 paper，我确定intel core2 =>Nehalem => sandy bridge 他们的 store 指令都不在 pipeline 中probe cache，因为我仍然怀疑这种设计所带来多少好处：
1. store buffer的好处之一就是使store 造成的cache miss 与cpu执行可以并行化，只有是 store intensive（导致在rename & allocation 的时候没有得到可用的 store buffer) 并且中间有几个孤立的 sotre miss 的操作我们才会看到这种设计的好处,但是有多少这样的case才能足以说服我们去抢占load在pipeline中对内存的操作（load 几乎占用 35%， sotore 10%) ，说实话我想看到 benchmark.

2. 这样做只有 data 类型是 exclusive 才有意义,否则几乎没有什么区别。
sailing 于 2011-10-16 6:21 下午

上周出奇的忙。这周看完你说的这几个IP，我之前实际上看过，不过没有仔细看。

这几周将完成0.02版，主要包括Memory Consistency部分，会将各个流派的LSU统一看一下，然后补充进去。

Ma Ling的联系方式我已经有了。
Processor您的联系方式是什么。我再找几个人，我们最好离线讨论完毕，之后把我们的共识贴到弯曲上，这样好一些。
我的联系方式是sailing.w
processor 于 2011-10-16 9:46 下午

hwanghe AT gmail.com
2 于 2011-10-18 2:15 上午

错别字也算嘛?

这”歌”(个), har’e'ware(hardware) 之类的…
sailing 于 2011-10-18 4:39 下午

算。报上名来，以加入Contributor List。已改正。
et 于 2011-10-19 9:15 上午

ding
2 于 2011-10-19 6:11 下午

re 53, Xei.
bbuy 于 2011-10-19 10:14 下午

sorry I cant type Chinese at the moment. Although i haven’t finished yet, i have to say , this is a really good review and summary about modern cache,very comprehensive.
I have a suggestion about chapter 2.4 Cache block replacement policy, i think you spend too much effort on introducing the page level replacement policy like LRU-k and people might get confused here.

@P32 5th paragraph , first sentence: i guess you are trying to say block replacement instead of page replacement.

Anyway, im really executed to find this article, i will definitely read through it tonight.
sailing 于 2011-10-20 8:09 下午

P32页已改正，已将您加入Contributor Lists。
2.4节将来会有若干子节。现在使用页面替换算法也不一定不会出现在FPGA中，所以我加入了这些算法。将来会把页面替换算法单独做一子节。

还有52楼。我现在只能把你们写成
2.tektalk
bbuy.tektalk

最好给我一个拼音姓名。
sailing 于 2011-10-20 8:19 下午

首席，能加一个有人回复我关心的帖子，自动给我发一个email的功能吗？
陈怀临 于 2011-10-20 9:15 下午

明天晚上与体系结构的大牛王齐一起，为体系结构方面的小牛人Xi Yang接风。如果符合下面标准的，可以参加：－－买单做票友的。［含公款］－－对计算机体系结构确实爱好的。上述标准缺一不可。估计不是在上地，五道口这边。是Qi Wang那边。
billy 于 2011-10-21 12:12 上午

首席，这是赤果果的“敲诈”…请五道口的兄弟们擦亮眼睛…
2 于 2011-10-21 3:17 上午

唉~ Xei 不算个名字嘛…人家英文名字呢!
Ma Ling 于 2011-10-24 9:31 上午

Hi hwanghe,
我认为这篇paten描述store 需要访问data cache 的目的在于进行address translation 和检测异常，例如 page的属性，tlb miss,page fault, 因为 tlb level1/2都在 data cache 中（文中 17节提到），这也是 load 和 store 都必须经过的路径，他们都由LS1来处理，然后os会接管产生的exception. 同时看到LS2中对于store 的描述如下：“Stores are selected to reporbe in response to being retired”而 LS2正是处理所有真正与data cache 产生数据交流的地方，但是在pipeline中只有 load需要，对于sotor的操作是他retire 之后才开始。

我认为我们看到的alpha 21264中 store 在 pipeline中需要访问cache也是基于address translation 和 address validation的要求。
Ma Ling 于 2011-10-27 7:30 上午

sailing,

1.”因为在Front-End BTB 中只有4096 个Entry，所以Miss 时有发生，在Miss 时，需要根据相应的替换算法淘汰一个Entry，并重新创建一个Entry”

BTB 只包含预测为 tanken 的branch 如果执行后的指令被预测taken他会放入 btb, 用简单的
LRU算法替换原有的，如果是 not taken 直接invalidate 对应的一项。

2. “如果Hit，需要检查BTB 预测的结果是Not Taken 还是Taken。”
同上 BTB 只包含预测为 tanken 的branch，如果如果HIT 那么branch 为taken,
否则判断为not taken,btb 不包含 not taken的内容.

另外 4.2 存储器读写指令的发射与执行有些模糊的概念，我相信我们可以确定store不touch cache，
除了address translation & address validation.

Ling
sailing 于 2011-10-31 5:19 下午

Hi Ma Ling,

再次感谢您指出的问题。所有这些改动都会出现在0.02版。即时我将与Huang He和您再次认真核实LSU的问题。Huang He在MIPS中发现有在Pipeline中Store指令Touch D$的情况，到时候我们统一改一下，我会将0.02的Draft首先发给你们。

BTB中Taken与Not Taken我也会仔细核实。

另外0.02版将加入Memory Consistency的详细描述，并且会加入Directory-Based Cache Coherency机制的描述。我计划在12月底完成这些修改。

再次表示感谢。

Qi.
Ma Ling 于 2011-11-01 6:33 上午

Hi Qi,

从您的作品中我也学到很多东西，非常感谢您能分享这些知识。今天又看了看最新arm A15的架构，store 指令在pipeline里面也不touch cache 从性能的的角度来看，如果有store buffer 我不能理解要touch cache 的必要性。

Ling
FAN TO sailing and 首席 于 2011-11-01 10:40 下午

首席可以下载个ReplyMe插件for WordPress，当某人的评论被回复时自动发送邮件给被回复者。
并且可以自定义发送的内容。
processor 于 2011-11-06 7:46 上午

Hi Ma Ling,

Store操作是否在commit前probe D$ tag，不同的微结构设计是不同的，Intel的方法（在commit后probe D$）是一种设计，但是还有其它的设计。

我在前面的帖子中已经给出了公开文献中关于Alpha 21264和AMD Opteron这两款具体的处理器中store操作执行过程的描述，我认为文献中的描述是清楚的，即在21264和Opteron中，store操作在commit前就probe D$ tag。为了更为清晰明了，再额外引用一些文献中的相关文字。

关于Alpha 21264
===============
参考文献：Alpha 21264/EV67 Microprocessor Hardware Reference Manual
http://www.compaq.com/alphaserver/technology/literature/21264hrm.pdf

<<ALPHA21264
2.8.3 Memory Address Space Store Instructions

The Mbox begins execution of a store instruction by translating its virtual address to a physical address using the DTB and by probing the Dcache. The Mbox puts information about the store instruction, including its physical address, its data and the results of the Dcache probe, into the store queue (SQ).

If the Mbox does not find the addressed location in the Dcache, it places the address into the MAF for processing by the Cbox. If the Mbox finds the addressed location in a Dcache block that is not dirty, then it places a ChangeToDirty request into the MAF. A store instruction can write its data into the Dcache when it is retired, and when the Dcache block containing its address is dirty and not shared. SQ entries that meet these two conditions can be placed into the writable state. These SQ entries are placed into the writable state in program order at a maximum rate of two entries per cycle. The Mbox transfers writable store queue entry data from the SQ to the Dcache in program order at a maximum rate of two entries per cycle.
ALPHA21264

关于AMD Opteron
===============
专利6,473,832内容较为dense，比较简洁的描述可以参考Hennessey & Patteson的CAAQA 4th Edition的5.6节：
Putting It All Together: AMD Opteron Memory Hierarchy

<<AMDOPTERON
Suppose the instruction is a store instead of a load. When the store issues, it does a data cache lookup just like a load. A store miss causes the block to be filled into the data cache very much as with a load miss, since the policy is to allocate on writes. The store does not update the cache until later, after it is known to be nonspeculative. During this time the store resides in a load-store queue, part of the out-of-order control mechanism of the processor. It can hold up to 44 entries and supports speculative forwarding results to the execution unit.
AMDOPTERON
Ma Ling 于 2011-11-06 7:46 下午

Hi Huang He

我同样不认为某一种体系结构就是正确，关键是否是有意义并且逻辑是否合理，我说过我从performance的角度解释不通store touch cache in pipeline的原因。从《The AMD Opteron Processor for Multiprocessor Servers》同样没有看到store需要touch cache 的说法，我会把你上面提到的文章看一看。如果时间允许我也可以用simulator 在 cpu2006上来测试store touch cache in pipeline。 Arm最新的 A-15 store 也不会touch cache,我没有足够的时间看更多的架构，如果版上有兴趣的朋友请看看 IBM power7的体系结构，ibm目前仍然是体系结构的经典。
sailing 于 2011-11-07 5:35 下午

store with touch D$ or not in pipeline.

1. Touch. 可见的优点是可以缩短写的延时。当然问题也有很多。Cache Block处于Exclusive状态时，提高得有限。如果是其他状态，本地CPU可以有两种做法。
a. 设置专门的Buffer处理Refill。这种方法我的直觉是与不Touch D$，最终的效率几乎不会有太大的出入。
b. Hold住一个Cache Block做Refill。这样会好些。只是在因为Exception和Misprediction需要reexecution时，会给硬件设计带来不小的麻烦，而且会在一定程度上Pollute Cache。
可能的方法是设置多个专门的Cache Block状态处理这些情况。在多处理器系统下不好做。

事实上，在多数应用中，读写的比例大约是3：1，所以更多的Cache优化发生在读上。

Don’t Touch D$最大的优点莫过于简化设计。另外我和几个人简单试了试touch cache in pipeline，在单处理器环境下与Don’t Touch性能差异不明显，不过我们也没有跑很多Trace，简单验证一下而已。多处理器环境还没有试。

所以我并不支持Touch Cache。
实际上Huang He也不一定支持Touch Cache，只是指出有的体系结构这样做了。

这个月一直再做和体系结构一点关系都没有的事情，等下个月切换过来，把一些内容补齐。

Ma Ling，Huang He，有机会来北京找我，好好聊聊。
中医码农 于 2011-11-08 7:47 下午

随便翻了一下，说实话，文章有点乱，目标读者不明确。

另：差分比单端更慢吗？做signaling的人哭了。
你说的commit是更新arf吧，现代处理器有不顺序commit的吗？如何保证精确中断？

ref里面居然没看到jacob的memory system和mark hill的primer on mc/cc，虽然王大师说hill的3c模型误导业界几十年，但我们这种不是炼道的凡夫还是该看看
multithreaded 于 2011-11-08 8:56 下午

现在的读者群是有点窄，估计就是几个体系结构熟悉的人能体会其中的奥妙。最近看了一下这篇文章：

http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf

感觉非常好！建议采用McKenney的机器模型（Fig.1, 5, and 6) 把Store Buffer讲的更清楚些。
中医码农 于 2011-11-09 4:58 上午

读了前面一点，作者对（superscalar）microarch的理解有待讨论啊，看完感觉有点晕
1，笨鸟先飞的说法没听过，issue逻辑在关键路径上，再做花样影响时序。load speculation我的理解是发生在访存指令issue到lsu部件之后，为了解决与之前访存指令的数据相关；而且compiler已经做了调度-尽力在load和后续使用该load数据的指令中插入无关指令。
2，microarch的术语使用要十分小心，有时各家厂商说法不同且混用（比如commit/graduate/retire/complete），有时设计选择不同（issue queue/rs/rob）部件融合了
3，AGU这个部件单独拿出来好像只有x86这么做，x86的寻址模式太复杂了
4，value prediction（address/data）虽然研究很早，但我印象中还只是paper machine，商用处理器有成功应用？
5，关于OoO的先驱，有段公案，看水木网友zeal的博客（http://zeal.haliluya.org/blog/2008/01/26/lynn-conway/）；另外，Tomasulo必须改进才能支持精确中断。
6，non-blocking/MSHR的地位说得也有点太过了，1980s，logic和memeory的差异还不是那么大，单芯片的超标量还远着呢，何况集成cache；

前沿里“cache层次结构是微架构的核心”，“几乎没有更复杂”等说法建议改改（IBM对core microarchitecture的定义是pipeline+unlimited L1$），不然做内核的又得哭了，以为王大师来了。
中医码农 于 2011-11-09 5:07 上午

首席确实不凡，八大胡同的文章深入浅出，oh，不对，应该是page coloring的论述。

几楼楼长于 2011-10-06 7:15 上午
Latency Improvement2 ≤ Bandwidth Improvement 这个很对啊
这篇NB文章对我这个菜鸟来讲太多太深了，只能领略其中浅显的部分。
还是首席写的浅显易懂，一个page coloring用了5篇帖子，翻来覆去的讲，让你不懂都不行。
miki 于 2011-11-09 5:15 上午

中医码农，你得了花柳病还是怎么了，技术讨论，八大胡同都出来了，想骂街去别地，别污染弯曲。
中医码农 于 2011-11-09 5:21 上午

@miki：去你妈的
miki 于 2011-11-09 5:46 上午

被说中了，也别激动，赶紧找个砖家看看，不过身体的病能治，脑子的病就难了。
sailing 于 2011-11-09 4:50 下午

@multithreaded

http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf

这篇文章下载不了，好像连接不对。

是指
“Memory Barriers: a Hardware View for Software Hackers”这篇文章吗？

之前看过，但是没有太认真的看。12月的时候再仔细看看。
中医码农 于 2011-11-09 8:05 下午

建议单独写一章lsu，画个详细结构图。循序渐进，先in-order，再ooo发射；先说load bypasaing和forwarding，再讲load speculation和prediction。文中的lsq也有点模糊。

p.s: 为什么优化多针对load，一是程序basic block更多起始于load操作。二是core pieline在数据和地址ok后就将store操作视为finished等待rob的顺序提交，提交后视为architectural完成，rob可以继续推进，但这时store尚未retire-更新memory state。这是访存指令的独特之处。

一般store buffer有两部分：完成执行等待rob提交的-可能因为中断或推测等撤销；第二部分是已经完成架构提交的-退出rob，但等待更新memory state的。执行同步指令（同步指令有数种类型，也要分开看待）
或中断时需要刷掉第二部分。
至于是否touch d$，两部分最好分开考虑。
中医码农 于 2011-11-09 8:10 下午

之前说的王大师不是指wang qi哈，别误会。
miki，再说一遍，去你妈的！
multithreaded 于 2011-11-09 8:24 下午

To #77: yes, that is it. As for the memory consistance model, I think if you can explain the X86 consistance model that should be good enough since the IA architecture is widely used one.

“x86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors” is the one I like most.

I think the GWF blocks this paper’s access since I have no problem to download it in USA.
miki 于 2011-11-10 5:18 上午

中医码农，去你妈的！！
理客于 2011-11-10 7:54 上午

实力相当的时候，常常伤人也是伤己。适当的妥协，对大家都好，拼到底的结果，有时未必有真正的赢家，和谐本来是一个好词，爱人也是爱己。
路过的路过 于 2011-11-10 5:33 下午

You guys cute..适当的妥协/和谐…
“黃絹，幼婦，外孫，受辛。”
拍板砖的 于 2011-11-25 1:59 上午

大概看了一下，就最后一章还有点意思，前面扯的微体系结构部分有点乱，与楼上有同样感觉，王大师对超标量的理解有偏差。

切以为，与其搜文献写综述，还不如实现一个 cycle-by-cycle 的模拟器，理解要比这深刻的多

PS: 关于 cache memory 的，搞系统软件的可以参考：

搞处理器实现（微体系结构）的可以参考：　将近 1000 页，很给力的
拍板砖的 于 2011-11-27 5:43 下午

PS: 关于 cache memory 的，搞系统软件的可以参考：

What every programmer should know about memory

搞处理器实现（微体系结构）的可以参考： memory system: Cache, DRAM, disk　将近 1000 页，很给力的
multithreaded 于 2012-04-13 10:10 上午

第一章的各个小节应该做到：提纲要领。建议如下：

1.1 缓存的核心地位
。。。
1.4 投机执行的代价

3.1 Cache Coherence

Please use MESI as an example and remove IVRD discussion (Fig. 3.1). I think you need only discuss the MESI protocol and explain it well. The key is to explain:

1. FSM
2. Protocol message

And the messages trigger the state transfer.
sailing 于 2012-04-16 7:17 下午

计划一推再推，估计我要今年8月之后，才会开始更新这些有关Cache Memory的内容。
下一版估计会出现3级目录了，把一些想说清楚的内容，首先做到自己真正搞明白，这个确实很难。可能历时会很长，目前没有太多的头绪。

我很想多加入一些广义Cache的内容，但是有些内容确实不是我能够书写的。实际上狭义Cache的很多内容，我也并不清楚。

有些事情不经过真正的实践，确实不敢写。而这些实践的机会很少，同时也需要太多人和太多的经历做这件事情。

所以我能做的事情就是将这篇文章以及所有的更新都会在电子版中率先出现，供更多的人批评指正。
luchenggang 于 2012-04-19 7:47 上午

感谢王齐
multithread 于 2012-04-20 10:08 下午

P66, 第三段，performance重复了三遍。

最好少用英文，把Supercomputer, Stability, Scalability, programmability 等改成中文。
multithread 于 2012-05-23 11:28 下午

在P89页上，又发现了两个问题：

1．图4-18上没有GPU, 当文字中说：“并在其内部集成GPU”. SB-EP 应该是没有GPU的。
2． “首先进行Hush”应该是“Hash”
3． iMC 应该是 IMC.
turboant 于 2012-08-06 4:36 上午

今天刚开始读，刚看完1章，文章写的很棒。刚发现一个问题，前面还没有人提过：第1.1节（第5页倒数第三段）：如论L1和L2 Cache之间是Inclusive还是Exclusive，读操作不命中L1 Cache后，都必须访问L2 Cache，因为不管是那种关系L1 Miss都不能反映L2 Cache中是否存在该数据的副本。Inclusive还是Exclusive的差别主要体现在Cache一致性查询请求（Snoop或Probe）从外到内访问Cache层次的时候，Inclusive时一致性查询请求不命中L2Cache就不用再查L1 Cache了，Exclusive关系时，及时一致性查询请求不命中L2 Cache也必须查询L1 Cache才能知道核心内是否存在Cache副本。
turboant 于 2012-08-06 4:54 上午

关于“Store操作是否在commit前probe D$ tag”的问题，我认为“Processor”的观点是正确的，Intel的做法不了解，不敢妄加评论，Alpha和AMD在Store请求查询D$不命中或者命中但副本状态不是“独占、脏“的情况下，都会推测地向一致性串行点发送请求，前者是“读脏”请求，后者是“置脏”请求，但请求处理完毕后，D$的Tag状态都会变成“独占、脏”。此时Store指令可能已经Commit了，也可能还没有。但Store指令Commit后会重新查询D$状态，如果仍然保持“独占、脏状态”，则开始对D$中的Cache块进行“读、修改、写操作”，否则将重新根据D$状态发起Refill请求或者置脏请求。
虽然这样做可能会由于Store指令处在错误的推测路径上，而错误的将数据的“独占、脏”副本移动到D$中，对D$中的数据造成污染，但只是在Cache系统中移动数据副本，改变状态，不会修改数据内容，因此不会造成错误。而且，转移预测在绝大部分情况下都会是正确的，因此错误推测路径Store指令毕竟是小概率事件，所以推测获取“独占、脏”副本的方式仍然对性能有好处。
xtaci 于 2013-08-11 8:54 下午

如此好文，相见恨晚！

最新用户评论

最新文章

分类

弯曲评论荣誉出品：《浅谈Cache Memory》

雁过留声