Powered by FirstCloudIT.com, a division of DriveHQ, the leading Cloud IT and Cloud Surveillance Service provider since 2003.
更多的写策略
上次说到，写策略有写通和写回。而根据对写未命中的处理方式，写回策略还可以细分。对传统的写回，当发生写未命中事件时，缓存会从下一级存储器读取整个缓存块，然后把所写数据写入缓存块中。这应该说对很多情况是有好处的，比如连续的写，第一次的写将是写未命中，而后续的在同一缓存块内的写操作都将是写命中。通常，把这种写操作叫做“Write Allocate”（写－分配？不太切意），因为写未命中事件将为所写的地址分配一个缓存块。在程序中我们把这种策略叫做“Write Back (Miss Allocate)”，或者减写为“W-Alloc”。但这种策略也有其坏处，就是写未命中将启动一个大的读操作，如果后续不使用这些读出的数据，将是极大的浪费。对多媒体程序来说，通常不会对某个范围的内存进行交替的读和写，通常的运算是从几个缓冲区中读出数据，运算后写入另一个缓冲区。这种情况下，如果处理的数据量很大，将伴随着大量的写未命中事件，从而降低整个程序的性能。
另外的写策略是在写未命中发生的时候，并不分配缓存块，而是按写通策略处理，直接把数据写入下一级存储器。当写命中时，按写回处理，把对应缓存块标志为“已修改（Dirty）”。在程序中，我们把这种策略叫做“Write Back (Through on Miss)”，简写为“W-Back”。这种操作看起来比前面的好，其实也是有缺点的。对顺序写操作（这也是很常用的操作），对这一块的所有写操作都是写未命中，可能会导致程序性能下降。
在多媒体程序中，写的方式大部分是：（1）多路顺序写（很多路，可能有32～64路）；（2）多路顺序写，每次写伴随着将刚才写出的数据读回的操作。对这2种写方式，前面的写策略都不适合了，而且Intel的“写合并”缓冲区也无济于事：写合并缓冲区太少了（PIII才4个，P4也仅6个，而且建议同时只用4个），根本不够用。所以，Intel建议一种软件优化方法，叫做“软件写合并”。所谓“软件写合并”，就是先开辟一个小的缓冲区（可以在L1中放下），所有写操作先向这个缓冲区写（所有写都命中，伴随的读也命中），然后在这个缓冲区满时一次把这个缓冲区复制到目的缓冲区（此时可以利用写合并缓冲区）。经过初步测试，“软件写合并”在不考虑后面的复制操作的情况下可以达到加速的目的，但如果考虑复制操作，由于复制操作本身需要很多指令，虽然其速度很快，仍然需要时间，而前面的加速有限，所以整体的速度几乎没有变化。至于更定量的分析，必须要编写精确的程序来测试。
无论如何，前面的2种写策略也是可以区分的，“W-Through”和它们也是可区分的。可以想象，对“W-Alloc”，“W－M”和“W－H”的差异将是巨大的，而“W-Back”对此应该不敏感，但对“W-Back”，“R－CH”和“R－M”仍然有非常显著的差异。对“W-Through”来说，“W－M”和“W－H”、“R－CH”和“R－M”都不会有显著的差异。根据这些信息，可以区分“W-Alloc”、“W-Back”和“W-Through”。
经初步测试，PII的L2满足上面的“W-Back”的规律，而PII的L1和PIII的L1、L2以及P4的L2均满足“W-Alloc”的规律，而P4的L1满足“W-Through”的规律。至于真正的策略，只有Intel知道了。具体测试数据这里就不再列出，大家自己测试。