Thanks for the comment.
As answered to the previous comment, yes, I agree. Likely I did a poor job of explicitly saying that those advises are not generally applicable.
It usually makes sense to have a dedicated machine (pool of machines) that a properly configured to run perf tests. And nothing else is executed on them.
Yep. And I think I stated that in the beginning of the article. :)
This one:
> It is important that you understand one thing before we start. If you use all the advices in this article it is not how your application will run in practice. If you want to compare two different versions of the same program you should use suggestions described above. If you want to get absolute numbers to understand how your app will behave in the field, you should not make any artificial tuning to the system, as the client might have default settings.
Yes, that might be possible. However, you probably will get multiple cycle counts for the same function depending on which path was taken. And it works only if the amount of taken branches in the function is not that big (less than 32). Otherwise it will not fit into LBR stack. For example, if you have a loop with more than 32 iterations it will trash the LBR stack with backwards jumps. But yeah, for small functions it might work pretty well.
I would better go for analyzing not the whole function (all basic blocks of the function) but only the Hyper Blocks (typical hot path through the function). Here is the example of how to do it: https://lwn.net/Articles/680985/ chapter "Hot-path analysis".
Superblocks rather than Hyperblocks. Except for cmov which is partial predication, x86 doesn’t have predication. But SBs are probably what your optimizer wants anyways.
Hi, I'm glad you like the article.
The process how I went from TMAM metric to particular event that was used to calculate it is describe in the TMAM metrics table:
https://download.01.org/perfmon/TMA_Metrics.xlsx
In the same row for DRAM_bound metric there is precise event PEBS specified that we can use for locating the issue. Sampling on the precise event will let us detect exact place in the code where we have the most amount of L3 misses.
Regarding your example with 1000 muls followed by 1000 loads... That's why in my experiments I interleaved loads and bswaps, because that's what (hopefully) every decent compiler will do.
I interleaved loads and bswaps, because that's what (hopefully) every decent compiler will do
Your optimism about compiler behavior is charming. I think you may be disappointed if you expect compilers to interleave loads just because this approach works better on modern processors. My experience has been that GCC goes out of its way to hoist all of your carefully interleaved loads to a big block at the top.
I'm guessing it does this because it's a simple heuristic that was often helpful before out-of-order processors became common. Normally, the performance impact of this is very small, but when it does exist, it's usually negative. If I recall, ICC does a better job of interleaving, or at least leaving things interleaved.
Well, yeah.
I don't know much about the current state of the art (because I don't touch the CodeGen on a daily basis), but I kind of look into the future with hope that compilers will better handle at least those "simple" cases. :)
Compilers are rarely going to transform the 1000/1000 example into the 10/10 one, even if they were smarter.
Often such a transformation is simply impossible: the effect of interleaving the instructions may be different than what the source dictates.
Also the 1000/1000 example probably doesn't arise as a long stream of explicit instructions: it is probably just a short loop with 1000 iterations! That makes it even less likely that the compiler will simply start interleaving various instructions following the loop into the loop body somehow.
