编译器优化如何影响缓存不友好的算法？答案

【问题标题】：How can compiler optimizations affect on a cache-unfriendly algorithm?编译器优化如何影响缓存不友好的算法？
【发布时间】：2017-03-10 09:55:15
【问题描述】：

我注意到this question 的代码中有一个有趣的行为，它也来自Optimizing software in C++ 中的Agner Fog，它简化了数据在缓存中的访问和存储方式（缓存关联性）。解释对我来说很清楚，但后来有人对volatile... 也就是说，如果我们在矩阵声明中添加 volatile 限定符：volatile int mat[MATSIZE][MATSIZE]; 值 512 的运行时间会显着减少：2144 → 1562 μs。

正如我们所知，volatile 会阻止编译器缓存该值（在 CPU 寄存器中），并防止编译器在从程序的 POV 中看似不必要时优化对该值的访问。

一个可能的版本假设计算过程仅发生在 RAM 中，并且在 volatile 的情况下不使用 cpu 缓存。但另一方面，513 的运行时间再次少于512：1490 μs...

【问题讨论】：

听起来像是测试错误/噪音。根据您的架构和操作系统，不同的虚拟内存可能具有不同的缓存特性。尤其是对于这样的测试。一个好的基准测试在各种虚拟地址上的操作是很重要的，以确保它不会被一个棘手的虚拟机补丁严重扭曲。也就是说;您分配了大量内存，然后在该分配中的不同偏移量处运行测试。
纯猜测：volatile 的引入可能会产生更多的内存访问，从而影响缓存替换行为（即，缓存行可能是最近访问的，因此在下次使用之前不会被驱逐）。

标签： c++ optimization volatile cpu-cache

【解决方案1】：

很遗憾，我无法确认 volatile 版本的运行速度更快。我对 volatile 和 non-volatile 版本都进行了测试，两者的时间对比如下图所示。在测量性能以优化代码时，按照 Alexandrescu 的 Fastware 采取几个步骤（不仅仅是一两个，而是数千个）并采用收集数据的模式 (https://en.wikipedia.org/wiki/Mode_(statistics)) 总是很重要的。

有各种高峰，也有深谷，但看图表你不能断定波动更快。

确实，编译器生成的代码是不同的，但没到这种程度，你可以去https://godbolt.org/g/ILw3tg看看

【讨论】：