When a sub-routine needs to be benchmarked, it's relatively easy to create a workload for it, and then just loop over this workload to extract statistics. It will provide enough information to measure the sub-routine's performance.
At least in theory. However, in practice, I find the equivalence with real-world scenarios not that straightforward.
In a benchmark, the sub-routine is "core and center", it will loop over and over, in order to be measured. During this period, it essentially has monopoly over both data and instruction caches. This can lead to design decisions which measurably improve benchmark figures, though at the expense of inflated instruction and data cache budgets.
Once integrated into a larger system, the target sub-routine is now invoked once in a while, sandwiched between multiple other sub-routines. It's no longer alone, meaning that the inflated budget will now play against it, flushing the cache used by other subroutines.
I'm fine with measuring and taming the impact of data cache. But for the instruction cache, it's an entirely different problem.
This impact seems impossible to measure in a synthetic benchmark, where the sub-routine is alone. Yet, because of this difference, it leads to invalid conclusions. This is a big problem, making benchmark's essentially worthless or downright misleading.
I haven't found a solution to this problem yet, apart from measuring performance of a whole system. But when the sub-routine is designed to be re-used, it's unclear if measuring its contribution to a single use case is representative to any other use case. Also, when the sub-routine is only a small contributor to the system, it's more difficult to extract its impact with enough accuracy (the system itself may have more noise than the sub-routine's contribution).
Is there any "good practice" thats make it possible to measure the performance of a sub-routine while taking into account its impact on the (shared) instruction cache ?