请教 ARM920T的Cache为什么这么多路组相联的？
读宋劲杉写的《ARM920T的MMU与Cache》http://www.akaedu.org/pages/news_detail.php?id=374
此文cache一节的课后题如下：
“ARM920T的Cache是64路组相联的，而PC和服务器CPU的Cache往往只有4路组相联，路数越多查找越慢，为什么ARM要设计这么多的路数？”
查了一下，发现即使是arm也没有几款有64路这么多的cache：
http://cache.amobbs.com/bbs_upload782111/files_40/ourdev_645041MGC77H.jpg
(原文件名:ARM cache.jpg)
考虑来考虑去也没得到个确切的答案，只有一些零碎的想法：
1 cache的多路组组相连因为有CAMContent-addressable-memory的存在，其实查找过程并不是太慢。
2 arm走性能路线的 arm11 a8 a9 的L1 cache也是四路4-way set associative的。
3 更多路的cache是为了节能考虑，多路可以提高cache的命中率，而读取内存又是非常耗电的一个过程。
4 而当cpu核的性能更高时，cache的过慢的访问速度会影响cpu性能，所以在更高性能的产品中使用的更少的way。
5 有资料上说arm11访问l1 cache需要两个时钟周期，a8 a9只需要一个周期，想来arm9应该不会少于它们。
自己能想到的只有提高cache命中率，从而提高性能降低功耗。
http://cache.amobbs.com/bbs_upload782111/files_40/ourdev_645058FX553O.jpg
(原文件名:arm eng.jpg)
也按照文章里的邮件地址给作者发过邮件请教过，不过两个多月了也没回音，估计是淹没在邮件的汪洋大海里:-)
希望各位高手特别是dr2001等对arm体系有研究的高手指点一下小弟，谢谢。 请各位大侠指点 这么快又沉了 等待高手指点。 等待高手指点
端午节快乐 上班了，等待高手指教 继续求助，谢谢。 等待高手指点 等待高手指点 等待高手指点 等待高手指点 又沉了，请高手指点 PC和服务器CPU的体系结构与arm的不同，冯 诺依曼使用统一cache 有L1 Cache —> L2 Cache —> L3 Cache 相联方式可能也不同
没啥可比性 “路数越多查找越慢”--查找和路数没有直接关系
这个问题和arm没有关系，是计算机组成原理的基本内容，看看课本即可，arm也只是实现之一。
不要过度迷信arm，arm本身是简单的处理器 更多的空间吧，我记得是。
还有有一本很好的书籍讲的很生动清晰。
《ARM嵌入式系统开发:软件设计与优化》——楼主看看这本奇书就懂了。ARM公司的资深人士写的。中文有个老师翻译的不错，英文貌似也不难看懂。 回复【14楼】gooooglemangooogleman
更多的空间吧，我记得是。
还有有一本很好的书籍讲的很生动清晰。
《arm嵌入式系统开发:软件设计与优化》——楼主看看这本奇书就懂了。arm公司的资深人士写的。中文有个老师翻译的不错，英文貌似也不难看懂。
-----------------------------------------------------------------------
lz上面那图就是出自于这本书中的，书中没提到路数有多有少的问题 回复【13楼】learner123
“路数越多查找越慢”--查找和路数没有直接关系
这个问题和arm没有关系，是计算机组成原理的基本内容，看看课本即可，arm也只是实现之一。
不要过度迷信arm，arm本身是简单的处理器
-----------------------------------------------------------------------
我认为查找和路数有关系 “路数越多查找越慢”在cache中慢了，但再慢也比ram中快
宋劲杉文章中有句：如果把组分得很大，把全部Cache Line都分到一个组里面去，就变成了全相联Cache；
如果把组分得很小，每组只有一个Cache Line，就变成了直接映射Cache
折中问题
512条Cache Line分成8组，每组64条---64路
512条Cache Line分成128组，每组4条---4路
各有侧重
组数少，组内条数多；组数多，组内条数少 cache如何查找？
恐怕根本就不是循环，挨个对比！
看看数字电路方面的书参考一下数字电路的思路。如果是搞集成电路设计，恐怕是基础没打好。如果是搞计算机应用，没有必要过多关系这个，事实上cache本来就是程序员透明的。
没有必要在这种茴香豆问题上过度花费时间，搞应用就专注系统设计，搞性能就就专注于算法分析，搞商业就专注于。。。
搞学术倒是可以没事看看，但也不要玩物丧志。 上班之后工作很忙，有三个多月没来ourdev了，谢谢楼上的各位的回答。不过好像没人正面回答这个问题。
To chinaye1兄，
谢谢chinaye1兄的回复。
现在PC的处理器早就不是大学教材上的386架构，实质上是CISC和RISC的融合，吸收了很多RISC的优点，一级cache是分离的,下面是core i7移动处理器spec上面摘下来的：
Processor Feature Details
Four or two execution cores
*A 32-KB instruction and 32-KB data first-level cache (L1) for each core
*A 256-KB shared instruction/data second-level cache (L2) for each core
*Up to 8-MB shared instruction/data third-level cache (L3), shared among all cores
“如果把组分得很大，把全部Cache Line都分到一个组里面去，就变成了全相联Cache；
如果把组分得很小，每组只有一个Cache Line，就变成了直接映射Cache
全相连cache查找慢但是命中率高
直接映射cache查找快但是命中率低
n路组组相连cache是二者的折中”
我的问题就是这种折中的数据是基于什么因素来考虑的？都是折中，有的cpu选择了2而有的选择了64，问题就来了选择4（少）和64（多）是基于什么因素的权衡考虑？
To goooogleman兄，
谢谢goooogleman兄的回复。
正如chinaye1兄所说的，在问这个问题的时候我已经查过《ARM嵌入式系统开发:软件设计与优化》这本书了，里面没有提到cache line的权衡问题。
Tolearner123兄，
谢谢learner123兄的回复。
计算机组成原理没有讲的这么深入的吧？ARM内核确实架构上比CISC要简单，不过，我觉得cpu core和cache可以看成是两个系统的，cpu core的简单与否和cache没有关系。
cache的查找是通过CAM进行的，不是简答的循环比较，这个我在1楼上已经说过了。
cache的优化有时候是比较重要的，如果算法不幸的遇到cache颠簸，性能会严重受到影响，我是遇到过相关的问题之后才想要弄明白cache的实现细节，在看资料时遇到这个问题，在网上搜了很多中文英文的资料，一直没有找到确切的答案。 简单说几句，关于Cache的设计和实现相关的内容没有深入研究过，就目前回忆出来的写，供参考。
Cache中TAG的查找用CAM实现；Way多了之后，两种解决方案：
1 TAG比较流水线化，会导致Cache延迟很大，不可取；
2 继续用TAG的并行比较，这会导致CAM的面积非常大。
所以，通常来说，CAM的实现是以空间换速度，Way数变化导致Cache的访问延迟相差不大。换句话说，实现多Way的Cache，要考虑芯片面积的增加。
A8，A9的Cache印象中是PA作为Tag的，ARM920T和ARM926EJ这两个级别的是用MVA做TAG。
理论上，A8，A9要先MMU进行MVA/PA地址转化然后才能查Cache，但是因为深度流水了，看起来延迟小，实际访问时间可能比ARM9/ARM9E高。
ARM920理论上是可以Cache查询和MMU判定访问权并行的。但是ARM920流水很浅，各种访问延迟都浮出来了。
印象中有文章分析过Cache Way数和性能的提升的关系，这个是容易饱和的，但是芯片面积花的钱可是线性的，很容易得不偿失。
此外，Way的多少我认为和设计时假定的数据在内存中的分布以及使用方式相关。这个没有深入考虑，但是对于某些模式，确实没必要使用过多的Way。
我感觉ARM920T的多Way和Fast Context Switching那个功能有一定的关系。不排除后来ARM看到这个东西很少有人用，毕竟和一般的线程切换模型不一样，OS Porting支持它的概率不高，进而就没必要搞那么多Way了。 至于为什么用4路组联，直观考虑，可以如下反推：
- 假定数据访问具有局部性，这也是Cache起作用的基础。Cache缓存的一个短小连续地址空间的代码/数据对程序运行是有益的。
- 按照一般程序编译的方法，会有四个段：Text，ROData，BSS，Stack。
对于哈佛结构来说，
ICache只需要照顾Text段即可，基本上需要：OS的库，用户程序代码和用户库。
假定这些代码很少，即便地址空间LSB完全重合，Cache只需要3Way即可全命中。
对于DCache来说，需要照顾当前线程的Stack，全局数据，ROData，BSS，Heap这些可能分立的空间。
一般来说，Stack是常用的，代码可能会在BSS，全局数据，Heap中高密度的使用1-2个，可能会有偶然的ROData。
简单计数，4Way基本上能覆盖大多数的情况；如果多一些自然更好，6-8Way考虑一下局部性，也差不多了。直观上和大多数的选择是匹配的。再考虑考虑CAM面积带来的成本，直观上看还是凑合的。
Cache的实现细节对优化影响不是那么巨大，但是确实要明白Way的概念，究竟能有多少个Slot可以用。否则有的Cache空间就浪费了。
ARM上早期没有PreFetch指令，只有一级Cache，可以干的事情相对不多。
不像x86，可以从取指解码开始推，多级Cache还有Sreaming和Stride的Hardware Prefetcher，预取指令以及SSE带的临时预取指令等等。可以做的事情就多了。 十分感谢dr2001兄的回复。
你所说的东西涉及东西较多，我好好理解一下再来请教:-D 你好，请教一下，宋劲彬的《ARM920T的MMU与Cache》中的介绍“组相联Cache”时提出的那个“为什么VA Tag是VA，为什么组的编号用VA”，这个问题该如何计算
页:
[1]