我试图使用VsPerfCmd.exe来分析已检测的本机应用程序中的分支错误预测和最后一级缓存未命中。
设置的工作原理与tin相同，但结果我似乎并不合情合理。例如，据报道，总是触摸24MB数据集的函数在被调用〜2000次时仅导致约700个高速缓存未命中。现在让我把它放到透视图中 - 该函数线性遍历两个12 *字节元素的1024 * 1024个元素的数组。对于每个元素，它随机决定是否需要在其之前或之后的元素1024索引的信息。这意味着为了不产生任何高速缓存未命中，CPU将始终必须在高速缓存中具有至少三个1024 * 12字节的这两个数组。此外，在每次迭代之后，该过程使用sleep（）产生CPU大约8毫秒。我无法想象任何硬件预取器做得很好。
与VsPerfCmd相比，这些愚蠢的数据量怎么会产生更多的最后一级缓存未命中？即使我的i7拥有8MB的共享L3缓存，这似乎也不太可能。谁能分享他们对这里可能发生的事情的看法？当然＆＃34; VsPerfCmd.exe很糟糕＆＃34;这将是一个有效的答案，但如果有人要这么说，我想至少听到有人作为这个断言的基础的类似经历。
答案 0 :(得分：2)
回答我自己的问题 - 因此，在尝试使用Intel VTune Amplifier XE™验证VsPerfCmd结果后（这不是广告，我只是喜欢输入类似的产品名称，因为它让我感觉它们如此愚蠢），我可以肯定地说它们是<强>垃圾
这只是一个粗略的比较，因为我还没有找到如何获取从VTune调用函数的次数，但是 900 的近似调用导致 1,040,000 根据VTune的说法，Last Level Cache未命中。 与使用VsPerfCmd和报告的〜 700 LLC错过的〜 2000 调用相比，可以安全地假设VTune结果更合理。
当然，我不能说比“VsPerfCmd很可能是错误的”更具体 - 这个现象的原因和方法仍然不清楚。任何了解更多信息的人都应该对此进行详细阐述，请给我发表评论！
答案 1 :(得分：2)
首先关闭 - 硬件LLC未命中计数器（让我们称之为）实际上并不计算LLC在您的特定应用程序中未命中。它的作用是计算所有LLC未命中数，并将数字与预设阈值进行比较（称为SAV - 值后的样本，通常为数千甚至数百万的数量级）。如果当前计数等于SAV，则会引发中断，此时指向的任何IP都将保存在跟踪计数器和时间戳旁边（例如，使跟踪合理）。如果此IP指向模块中的指令，则所有这些缓存未命中都归因于您的模块/功能/指令。因此，您看到的结果图片不是真实的，而是统计上正确的。我没有使用VsPerfCmd，但是有什么可以帮助你检查它为LLC未命中设置的SAV。如果它比VTune设置的数量级大，那么可能是你将700,000个LLC未命中与1,040,000个LLC未命中进行比较，这将更有意义。
然后是应用程序工作负载和工作集的主题。 3 x 1024 x 12B仅为36KB，这对于8MB LLC来说无关紧要。如果算法是一致地来回跳转，而不是总是向前或向后跳跃，那么它将只是那些频繁使用的24 MB的一小部分，这意味着最热门的数据也很可能适合LLC。另外，CPU只看到称为高速缓存行的块内存，长度为64字节。因此，无论何时算法向前跳转或反向访问接下来的12个字节，都会将52个相邻字节加载到L1中，因此如果跳转后的下一步是*（ptr ++），则不会导致高速缓存未命中。产生8毫秒的CPU不应该影响缓存性能，除非您怀疑为下一个量程调度的线程正在执行其他内存密集型操作，这将导致您的数据缓存行被驱逐。否则，如果只是某个操作系统线程在后台只接触几个字节，那么就不应该进行大规模的缓存驱逐。