Cache in action

cache这个东西在游戏开发中绝对是扮演超级巨星的角色。

在处理器（cpu，gpu）发展如此神速的今天，几乎ALU计算很难成为瓶颈，而数据访问则常常成为问题所在。

cache是一个硬件上的结构（virtual memory则是由操作系统来控制），是对processor访问memory的一种优化。

概率问题在软硬件设计中起了很大作用像cache这个依照space和时间上的重用高概率，像swizzle格式的texture遵守texture访问在块状（而不是线性的）上的高概率。

cache就是对物理内存最近常用的部分做备份，以cache line为单位（类似virtual memory以page为单位），cacheline是硬件决定的。

其中有n-way associative和write through/back等需要注意的地方。

所有这些性质决定了写程序时候会产生非常大的效率差别。

先来个powerpc的例子吧(见到什么说什么，也不局限于cache了)

---

InstructionUnit

• L1 cache----32k, 2way associative, 128B cache line(cache line大小和page没关系的，一个是硬件的事情，一个是操作系统的事情）
• 64 entry, 2way associative, TLB-----page table的cache
• 4k*2 branch hitory table-----有根据历史记录预测branch的能力呃
• out of order completion of load cache miss instructions----会导致processor级别的读乱序，必要时候注意多线程同步呃，参见前面lockless programming处理情况。sync系列函数搞定。
• 12 stage issue queue for separate handling of VXU/FPU instructions----(应该是instruction pipeline)

FixedPoint and Load/store execution Unit

• 32k, 4way, 128B cache line, write through
• 64 entry, 2way, TLB
• 8 load miss queue, 16 store queue,

Vector/Scaler Unit(VSU)

• no L1 cache

---

提升cache性能的一些方法，只总结开发者可控部分吧，类似增加cache size，增加cache level这种是硬件开发者的事情，就飘过。

• 数据的alignment----这个可以保证数据会占用尽可能少的cache line，cache performance也会变小
• 压缩数据----bitfield替换bool，尽可能小的数据格式，编译时候选择最小size而不是最优化（优化instruction cache)都是不错的选择
• 常访问的数据集中化
• prefetch，在知道后面要用这个数据了，就先把数据读进来

最后要说的就是现在硬件过于复杂，在某个平台上开发经验有限的情况下，general的知识最好只做指导方向用，真正优化还是要跟着硬件手册和profile结果来，而不是主观推测。

假设经常出错呃。