CPU cache line

在读github.com/valyala/bytebufferpool的源码时，发现这样一句：

minBitSize = 6 // 2**6=64 is a CPU cache line size

CPU cache line是什么东西？Wikipedia给出下面的解释：

Data is transferred between memory and cache in blocks of fixed size, called cache lines or cache blocks. When a cache line is copied from memory into the cache, a cache entry is created. The cache entry will include the copied data as well as the requested memory location (called a tag).

• 回到最上面的代码，bytebuffer最小的size之所以被设置为64，因为作为主内存和缓存直接数据传输的最小单元，CPU cache line的大小固定是64个字节。也就是说，对于主内存（main messary）的读写是以cache line（64字节）为单位的。即使只读写一个字节，也是对那个字节所属的整条cache line做操作（读入cache或者写入主存）。所以小于64 bytes的缓存是没有意义的；所有缓存的大小都是64的整倍数。

既然聊到了cpu缓存，就多说两句。以笔者的Mac为例，cpu有4个核心，每个核心各有一个L1数据、L2指令缓存，一个L2缓存，并且共享一个L3缓存。

相比动辄十几、几十个GB的主内存而言，cpu缓存非常小。但它的访问速度非常块。各级缓存和主存的访问延时如下：

• L1 cache: 4 cycles
• L2 cache: 11 cycles
• L3 cache: 39 cycles
• Main memory: 107 cycles

可以看到，CPU访问L1级缓存的速度是访问主内存的22倍，即使是L3级缓存的访问速度也比主内存块4倍。不难想象，如果一个程序的指令和数据能直接在CPU缓存中找到，相比去主内存中加载，程序的性能会有极大的提高。

我们知道访问内存比访问磁盘要快的得多，因而会通过缓存来提升程序的性能。一个常用的例子是使用redis来缓存数据库的查询结果。然而我们很少能更进一步，考虑到cpu缓存，把程序写的尽可能对cpu缓存“友好”，从而提升性能。

下面是一个关于缓存很经典的例子：

代码1

const (
	nRow, nCol = 1024 * 512, 1024
)

func main() {
	var matrix [nRow][nCol]byte = [nRow][nCol]byte{}
        var b byte
	t := time.Now()
	for i := 0; i < nRow; i++ {
		for j := 0; j < nCol; j++ {
			b = matrix[i][j]
		}
	}
	fmt.Println(time.Since(t))
}

输出：594.07741ms

代码2

const (
	nRow, nCol = 1024 * 512, 1024
)

func main() {
	var matrix [nRow][nCol]byte = [nRow][nCol]byte{}
        var b byte
	t := time.Now()
	for i := 0; i < nCol; i++ {
		for j := 0; j < nRow; j++ {
			b = matrix[j][i]
	    }
	}
	fmt.Println(time.Since(t))
}

输出：6.17106279s

两段代码遍历同一个二维数组，第1段代码是按行遍历，第2段是按列遍历，最终的效果完全相同，但运行速度却相差了10倍。造成这个差异的原因就是cpu cache的cache line传输机制。前面提到，缓存即使只读取一个字节，也会加载整条cache line。在代码1中，缓存在加载matrix第一行的第一个元素时，“顺带手”地把第一行的后面63个元素也读了进来。在接下来访问第二个、第三个...的元素时，直接读缓存就好了。而在第2段代码中，访问完第一行第一个元素后，接着访问第二行第一个元素，而这个元素不在缓存中，出现了cache miss，cpu不得不访问主内存。由于缓存的空间有限，当程序访问第一行的第二个元素时，相应的cache entry可能已经失效，需要重新加载。