计算所 。张晓东 。multicore（5）
作者 陈怀临 | 2009-11-24 15:24 | 类型 专题分析 | 28条用户评论 »
|
在张老师回答我问题的间隙，我似乎还与张老师讨论了一下他总结出来的那几个调试cache性能方法。记得我大概是这样说的。 × 对Implicit编译的方式能编译出一个高效的Cache Friendly的程序不是很看好。Implicit的意思是编译器后端做优化，你写的C代码什么也不用做，不用感知Cache的友善性（否则叫做Explicit），顶多编译的时候加几个选项。张老师似乎比较同意这个观点。 毕竟他不是做编译的。贬低编译他好像一点意见都没有：-） ×认为从应用系统的角度来提高系统cache利用率是目前不错的方法。我好像在那里说了一下我有过这方面的经验。张老师非常客气的让我简单的讲了讲。大概就是通过gcc extension的attribute你可以把你认为系统中的working set（数据和指令）都规划到相应的ELF文件的段中。从而，在4G空间中，耦合性比较强的函数（即TEXT）和数据（即DATA和BSS） 都可以在一起，从而提高其Locality。并且加上gcc的对齐（Align）等等，你可以非常容易的判断出相应的函数之间是否有指令Cache的冲突，全局数据之间是否有数据Cache的冲突。通过objdump，看一个函数的虚拟地址和一个数据的虚拟地址，然后知道相应CPU的Cache的Index方法（用那些Bit做Index），我们就可以非常容易的知道两个函数是否在挤同一个Cache Set。张老师很耐心的听我讲完，问了一个问题：（陈首席），你的这些方法能否做出一个通用的框架？我说不能。。。 教授们如获至宝的是一个通用的框架，算法和曲线； 工程师要解决的是某个具体产品的问题，定期发布。 【注：在系统调试中，人的交互式参与估计是必不可少的。目前，许多系统有很多Profiling工具。其主要目的就是找出Working Set。例如系统中最Heavy的函数和数据集。一旦找出，如果是自动调控，例如通过Cache Locking的方式。这方面我曾经实验过，但感觉对系统的性能提高不大，特别是在L2 Cache不大的情况下。我对动态调整Cache利用率目前没有实验过。ELF一旦链接完毕，其实虚拟地址就已经敲定了。如果这时许多函数或者working set是不Cache Friendly的，似乎很难在动态中调整。。。当然，这是教授们应该研究的话题。例如可以在页面管理做Paging的时候做一次调整。这也就是张老师在Page Coloring方面的工作】 ×应用系统与操作系统核心部分是要合作来完成Cache的利用率。 ×最难的部分就是系统不知道高层应用的语义。例如，在什么时候，那部分函数是系统的working set。在通信系统中，不同的配置，不同的报文，一个系统的working set都可能是在变化的。难，确实太难。 在这些问题上，只有次优解，基本上不可能存在什么算法，或者最优解。所以最好的方法就是，不同的场合，做不同的调整。不能教条主义。。。 后来陆陆续续有一些计算所的研究生提问。现在能记得的就是一个很好的，但张老师没有回答上来的问题。 TLB的问题。 是一个前排学生提的问题。问题大概是：TLB的Entry的互相挤压的问题。也是一种cache问题。问张老师如何看待。 张老师似乎在回答这个问题时有点含糊。感觉没有很清楚TLB与DARM中的Page Table的关系其实就是一种缓存关系。但这种事情按理说是不应该发生的！现在我想张老师估计是累了。讲一个半小时，是非常累的。 记得我上次在北邮，没吃饭，侃完后基本上虚脱。。。。。。 TLB这个东西其实很简单（理论上）。就是MMU拿着虚拟地址去找物理地址的映射的。例如一个CPU的TLB条目可以有48个。那么大家也就得按照LRU等什么算法和谐共存了。。。、 其实，不够指令Cache也好，数据Cache也好，TLB Entry也好，掌握这些最重要的就是把握住：CPU是通过虚拟地址的某些Bits去做索引(Index)的。找到Index，就找到了相应的Cache Set。通常一个Set里可以有多个条目（Entry）。例如，不同进程的VA可以说在同一个Cache Set里（因为通过虚拟地址做Index），但是因为通过物理地址做Tag(注：Tag的检查就相当于第二道岗哨，当然也是最后一道。一旦匹配，就是一个cache hit了），从而，不会有二义性，是两个完全不同的cache line。 一旦把握好这个概念，什么Cache 二义性，冲突，颠簸等等，都会变得很清晰，很好理解。 。。。 散会的时候，我正好在走廊里接电话。 两个计算所的研究生把我截住了！ 要问多核处理器与Router的问题！天哪，还真有懂行的！：-） 在反复解释无效的情况下，我非常及时的让他们上《弯曲评论》阅读ASR1000和其他相关文章。。。 希望计算所现在，研究生们都每天挂在《弯曲评论》上。设成default site最好。 我没有再去打扰张老师。而是在离开的时候，从远处看了看他 。。。 一个人20年来，这样踏踏实实的用自己的实际行动帮助中国的计算机研究，这就是张晓东的过人之处。 其实，张老师在美国又帮了何止1，2，N个中国的起步助理教授。。。。。。 多谢张老师！ 陈怀临，2009年11月24日于硅谷，加州。 | |
 (11个打分， 平均：5.00 / 5) |
雁过留声
“计算所 。张晓东 。multicore（5）”有28个回复
VIPT,如果index bits 大于 page bits会发生cache alias.
Cache的应用主要是为了解决高速的cpu与低速内存之间不平衡带来的问题，这种解决方法有利有弊，主要弊端是万一在Cache找不到所要的数据就必须花费更多的时间读取更多的数据，并且在独立多核的环境下，各个核之间很难通过Cache取得共用数据。解决未来Cache与多核数据传输可能不是简单加大或加快Cache就能解决的，必须从计算理论及cpu架构上寻找解决方法。
小黄，你先给我解释一下天傲的评论，再批评Cache和做革命性的创新：-）。另外，这与计算理论或者道系统没啥关系吧：-）？
>>并且在独立多核的环境下，各个核之间很难通过Cache取得共用数据
恰恰相反，cache使得memory consistency的设计简单了很多很多….
“另外，这与计算理论或者道系统没啥关系吧”，我主要感觉cache要好好利用一下，不能让它仅干点搬运工的工作。
“恰恰相反，cache使得memory consistency的设计简单了很多很多….”，我想如果主板只插一个多核cpu那什么都好解决，但如果在主板插很多cpu怎么解决，难道再设计外置的cache管理芯片，或干脆在外置的cache上添加cpu。
推荐黄大师阅读 parallel computer architecture a hardware/software approach 的第 6 和 第 8 章先
我的意思主要是并行计算机系统在有限的带宽下要共用数据很难，即使cache速度再高也要通过一定的带宽通道。是否有更好的方法解决并行系统共用数据的问题？
“希望计算所现在，研究生们都每天挂在《弯曲评论》上。”
没设为default，就订阅到Google Reader了，嘿嘿。
另外我也不是学硬件的，不过看弯曲评论还是挺有意思的
“教授们如获至宝的是一个通用的框架，算法和曲线；
工程师要解决的是某个具体产品的问题，定期发布。”
精辟，略微补充一下：
通用框架、体制，往往包含逻辑的、数理的因素以及工程规划的因素在内，这些共性的基本原则首先被从实践中总结形成，回头来又指导着工程师解决单点问题乃至多点问题的归一化与细粒度平衡度的控制设计。
应用到具体的工程领域中，Practice Makes Perfect.
我今天斗胆给张老师发了一个email。介绍了一下我写的白话文文章：-）和忽悠了一下弯曲评论。紧张了一天。张老师至今没有回email。。。
不会生气，或者我的email进了Spam folder吧？；-）
Yes!!!!张老师给我回信了。记得我，而且抽空阅读了我5篇科技白话文。而且很鼓励我。说要refer弯曲评论给学生们。
张老师夸我（3）写的最好。并且说看了我的文章之后，评价我对体系结构和系统有“……The notes also show your insightful understanding of the architecture and systems. …..”.
请注意，这是OSU的系主任和IEEE Fellow对我的评价！我真的很高兴。。。
同学们，要读张老师的博士的同学们，要常来弯曲评论呀。没准哪天张老师就整一nickname在这里蜗居了：-）
首席, 我查了一下 张教授的 履历, 他是 从 William and Mary 跳到 osu 的. 我又查了一下 WM和OSU的cs 2010 排名, WM 比 OSU 差的很多阿.
张教授能从一个比较弱一点的学校跳到强校作系主任,可见是相当NB阿.
你还好意思说你查了一下，才知道。你自己找个豆腐撞死拉到。另外，WM也不弱。你这样说话会伤人的。。。例如，你能排除WM的人不在这里吗？
首席,别激动.马屁拍到马腿了…
2010 UNEWS CS OSU 31, WM 在 前75 里面是没看到. 当然排名都是浮云…..
你要这样说，WM已经够牛的了，结果还跳到更牛的OSU去做Chair了。你想想，WM和OSU的叫兽们都高兴。是不是？实话与你说，不少WM的教授会看Tektalk。你完了。。。申请学校的时候请把WM飘过。
另外，别人我就不说了。你跟我多年，为何在学术八卦方面没长进。张老师的事情还需要到今天去查一下？：-）
>你要这样说，WM已经够牛的了，结果还跳到更牛的OSU去做Chair了.
受教受教!!!
哈哈，很可爱的师徒之争，yajin谦虚的态度希望能永久保持下去。
陈博主确是同道性情中人
〉通过objdump，看一个函数的虚拟地址和一个数据的虚拟地址，然后知道相应CPU的Cache的Index方法（用那些Bit做Index），我们就可以非常容易的知道两个函数是否在挤同一个Cache Set。
How about dynamical linked code and malloc memory addresses?
I am not sure the scheme works in practice. In general, cache optimization is very hard.
首席很在乎浮云哦，呵呵。
我一定会死于中年痴呆。。。从昨天下午开始，到现在，突然对Page Coloring糊涂了。搞到现在，才（重新）搞明白。。。
我以前一直以为自己对cache是久经沙场。。。实战经验无数。
但还是犯糊涂。。。
Cache呀，cache。。。
linux kernel 里的slab 就应用了cache color技术，在应用态程序中实现了cache color,基本无效。
page color和slab color是同一件事吗？至少slab color和cache没有什么关系。slab color是要把object分不到不同的memory address上去，这样可以避免同一个memory channel的竞争。这个和memory controller的设计有关，一般memory controller有多个channel或者bank。（个人理解，不负责对错）。
首席进来澄清吧，kernel的slab有一个cpu high_cache， 每个cpu都对应一个high_cache,正是high_cache的实现决定了slab机制的高速，因为不用mutex.
Page(Cache) Coloring主要是解决，在Physically Indexed的情况下，L2，L3 大cache的情况。。。
当然，其实许多事情的不同的形，其实神都相似。例如都是为了使数据在cache里比较均匀（even。。。）的分布。
再说深点，跟CPU的cache设计机制有关，望首席深入CPU的cache设计优化。龙芯的CPU设计就有讲到Cache的优化.