it is clear that at 32kb level which is a common size for L1 cache there is little difference between 4way and 8 way. For larger cache the difference is neglectable. So “从8 way到16way有可见的提高” is not that true.
anyway the test is under single thread processor, more ways should help under multiple thread processor. a few server chip got 16way cache.
沙发?
首席大作终于收官了。
路过,楼下的继续!
首席,这个《全》不怎么全啊,第一部分的两张图就没有。
首席什么时候点评性能优化系列?
有个问题,Set index bits相同的地址肯定会对应同一个bin的同一个set,就算同一个bin内的其他set有空闲也不能使用吗?
Thanks to Justdo it. Fixed now.
能否讲讲cache,内存对齐,channel,rank等之间的关系
非常感谢首席的文章
非常感谢首席的整理
向首席致敬
华为1.5亿美元设印度研发中心
http://www.people.com.cn/h/2011/0616/c25408-3249866131.html
支持首席。
居然huawei去印度搞研发中心, 我看丫的是要完蛋了…
莫非huawei觉得老印写的code比自己的质量还好?
那华为就真的完蛋了…
或者哪个领导脑子被驴踢了 ?
好东西
首席,“有多少人想过,两个512k的数据结构有可能互相残杀??”这是不是有点不妥?
在2M 4way的cache中,假设从0地址开始申请两个512k连续地址空间,这两个地址空间是相同的“cache bin”没错,但是这不等于他们会互相残杀啊。
cache中一个set有4个line,一个512k地址空间将会占据所有set中第1个line,第二个512k地址空间会占据所有set中第二个line,所以两个地址空间不会互相残杀。
以上是自己理解,有可能是错误的。
陈老师,请教个问题:
如果Cache做成全相连的,是不是在最坏情况下,从Memory映射到Cache的查找操作,会退化为类似在单链表中顺序查找的过程?当然,芯片内部是并行的,可以以大大增加CPU面积、成本和发热量为代价,来提升这个查找的速度——这也是全相连Cache不实际的原因。您觉得我这样的想法对吗?
小谢同学,uuuuum,很好的问题呀。。。请问在哪里上学呀?:-)。我这个Cache Page Coloring的文章略微有点少儿不宜 or/and 女同学不方便。。。
首席明显低估现在的少儿了。。
Fully associative cache 无法实现,或者说实现的代价太大,而且,fully associative相对于16way的性能提高几乎没有。
有的时候如果coloringing没有做好,会造成若干页memory,共同映射到一片cache里面,这样就只能排队用cache,也就是造成cache ping pong,严重影响系统效率。
这让我想到了,在李敖写的一本讲台军生活的书里面,有这样的描述,台军士兵拿着发的福利券去找军妓,排队的时候,后面的士兵猴急地催前面的,前面的越催越慢,不啻是一道美妙的军营风景线。
TO 18:
也就是说,xxx way cache是一个折中的方案,用有限的成本(包括面积,费用,功耗等)提升,来换取cache命中率的大大提升,对吗?
那么,如何评估cache”利害变换线”的way数目呢?
you can get some data from
see mips run
or
Computer Architecture: A Quantitative Approach
SEE MIPS RUN的Cache部分一直没怎么看懂…… #^_^#
according to mips, 4way ~= full associative. random ~= LRU
See MIPS Run的cache部分没看懂,那就有点不应该了。阿雅,要补补基础课。是不是你们学校的老师有点问题?
set associative缓存具体是多少way,不是设计师的选择,而是集成电路工艺决定的。在一定的速度要求下,能够比较多少位的地址,就实现多少way。
从8 way到16way有可见的提高,但是模拟实验表明,从16way到32way,提高几乎没有。大概一百万次访问里面,32way可以减少个位数的缓存失误。
you can get data from
http://www-mount.ece.umn.edu/~jjyi/prof_links/L1_D-Cache_Miss_Rates.pdf
it is clear that at 32kb level which is a common size for L1 cache there is little difference between 4way and 8 way. For larger cache the difference is neglectable. So “从8 way到16way有可见的提高” is not that true.
anyway the test is under single thread processor, more ways should help under multiple thread processor. a few server chip got 16way cache.
如果你不去亲自做实验,你无法推翻这个结论。
1. 8:1 the rule of thumb of John and David
2. Cache越大越慢
3. Way越多,decode时间越长
那些似是而非的结论是有害的。
缓存可以用10级流水线,再大几倍都没有问题。
way的比较根本不是问题。
大家讨论的不是一个东西。L1不可能搞10几级流水线。L2就无所谓了。我也相信在mc,mt的场景way越多越好。
Way有多少,不是某一级Cache单独能够决定的。有的时候是设计的不得已。
简单的例子。
在L1 Cache层面。首先存储器读与写关心的重点不同。读关心Load-Use Latency,而写要关注Bus Traffic。一般说来现代微架构的Load-Use Latency在3~5之间。AMD从K8开始这个Latency为3,最新的Bulldozer的Latency为4,不是最新的不好,而是为了扩大带宽。Intel的Nehalem和Sandy Bridge是4,T4是5.
L1 Cache Pipeline不会太长,实际上L1 Pipeline中处理的内容较为固定,分Hit和Miss两种情况讨论。3~5 Cycle指Hit,Miss后多些节拍,好在都是Non-Blocking的。Hit分为AGU,Decode,Access,还有一个是L1 TLB(Virtual Cache不用),有四拍组成。
其他的不说了,Decode指N-Way search and find Hit的过程。
如果微架构的主频为3.3GHz,那个一个Cycle是300ps,做不了太多事情的,L1 Cache在我视线所及甚至没有超过8way的,其中Decode比较是个大问题,有机会大家可以用FPGA写段Verilog程序验证一下一个CAM在不同Entry下的延时就知道了。CAM条目越多,译码时间越大。频率稍高一点点,就无法满足设计要求了。
而L2 Cache的Way要看和L1 Cache的关系,是Inclusive,Exclusive或者NI/NE,不能一概而论。有些Cache的Way很长,比如16或者32,很多都是实现中的不得已,并不是单独考虑多几个Way,Hit Rate更高些,更多考虑的因素是相互间的Inclusive关系。
多级Cache使用的Coherence Protocal和Memory consistency超出越大多数没有真正做过这些设计人的想象,这是一个尚未解决的State-Explosion问题。仅是部分验证需要上万台服务器跑几个月。其中的State,Corner和Race Condition在4级Cache层次结构中太多,以至于上千万条Trace验证后,大家都不知道自己做的是不是一定正确。
进一步考虑Hit/Write policy,replacement, Speculation等一系列因素,Cache设计更为复杂。
上文列出的三个结论出自John和David的A Quantitative Approach。从宏观的角度上看,这些是考虑了千千万万因素之后,凝结后的几句话。John和David的量化分析是春秋笔法的,因为这两个人知道的东西太多,知道有些东西根本没有办法写,知道有些东西先给入门者一个直观模糊的概念更重要。
“如果系统还是我们文章中例子的2M Cache。其x是18.
(18-18+1)=1.
这意味这什么? 这意味着,一个2M的cache在OS或者应用程序的512K的页面分配机制
下,cache其实就是被拆成了两个Bin。(2^1=2)”
512KB的页面,2MB大小的cache,4-Way, 如果得出是两个Bin?
如何可以在写一篇(最最简单的)程序从磁盘加载开始…到执行第一条指令的(和cache,mmu,tlb联系在一起)文章就好了.
反正我是很混乱,不知道到底有多少人懂得呢?
或者说我这么考虑问题,想要了解的东西是不对的呢…
搞个uboot,bootcode看完就明白了就那么点东西