Caching 基准测试指令缓存影响

当需要对子例程进行基准测试时，为其创建工作负载相对容易，然后只需循环此工作负载即可提取统计信息。它将提供足够的信息来衡量子程序的性能

至少在理论上是这样。然而，在实践中，我发现与真实场景的等价性并没有那么简单

在基准测试中，子程序是“核心和中心”，它将反复循环，以便进行测量。在此期间，它基本上垄断了数据缓存和指令缓存。这可能会导致设计决策，从而显著提高基准数据，但代价是指令和数据缓存预算膨胀

一旦集成到一个更大的系统中，目标子程序现在会偶尔调用一次，夹在多个子例程之间。它不再是唯一的，这意味着膨胀的预算现在将与之对抗，刷新其他子程序使用的缓存

我很擅长测量和控制数据缓存的影响。但是对于指令缓存，这是一个完全不同的问题

这种影响似乎不可能在综合基准中衡量，因为子例程是单独的。然而，由于这种差异，它导致了无效的结论。这是一个大问题，使得基准测试基本上一文不值或完全具有误导性

除了测量整个系统的性能外，我还没有找到解决这个问题的方法。但是，当子例程被设计为可重用时，不清楚衡量它对单个用例的贡献是否能代表任何其他用例。 此外，当子程序对系统的影响很小时，很难以足够的精度提取其影响（系统本身的噪声可能比子程序的影响大）

---

在考虑子程序对（共享）指令缓存的影响的同时，是否有任何“良好做法”可以测量子程序的性能？

相关：-在L1d缓存中获得代码热，而无需启动分支预测。在一个更大的程序中，尝试在现实环境中对函数进行微基准标记是一个相关的问题。是的，微基准标记使巨大的展开因子看起来很好，这是一个众所周知的问题，而事实上，如果你在一个大程序中的任何地方都这样做，它们可能会损害整体。但实际影响取决于周围的代码及其热L1i封装尺寸。