Re:Precise timing of machine code with Linux perf
by A2017U1 on Sunday May 05, 2019 @09:12AM
(#19832626)
This is great. Always love seeing what can be accomplished with just a shell.
Wish I could get more time to work on micro-optimisations, in this age you often get funny looks proposing to dig down and optimise sluggish code. Spin up more compute and call it a day they say.
While that's completely understandable from a business perspective, it's somewhat unsatisfying as a developer, the expertise that comes from it surely has lasting benefits too.
Re:Precise timing of machine code with Linux perf
by darawk on Sunday May 05, 2019 @05:22PM
(#19835159)
Would anyone who understands mind explaining the phrase "prefetch window"? I don't quite get what's meant by that from context, and can't seem to find anything from googling.
Re:Precise timing of machine code with Linux perf
by PowerfulWizard on Sunday May 05, 2019 @08:07PM
(#19835878)
I'm just going off the article, here is my understanding.
The sample program is doing 2^7 = 128 NOPs, 4 at a time for 32 cycles, and then it is doing a memory access.
The address of memory that is going to be accessed is known right before doing the 32 cycles of "work", so a prefetch can be issued at that time.
The meaning of the 'prefetch windown' term is the number of cycles that you have between when you issue the prefetch to when you issue the instruction that accesses the address that was prefetched. So it is based on the structure of the program being analyzed.
Re:Precise timing of machine code with Linux perf
by vbernat on Sunday May 05, 2019 @04:50PM
(#19834969)
This is quite interesting. Is there anything preventing the collection of the number of cycles spent in an arbitrary function? It seems this is just a matter of identifying all branches.
Re:Precise timing of machine code with Linux perf
by dendibakh on Monday May 06, 2019 @01:31PM
(#19841727)
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".
Re:Precise timing of machine code with Linux perf
by CalChris on Tuesday May 07, 2019 @02:03PM
(#19851889)
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.
Wish I could get more time to work on micro-optimisations, in this age you often get funny looks proposing to dig down and optimise sluggish code. Spin up more compute and call it a day they say.
While that's completely understandable from a business perspective, it's somewhat unsatisfying as a developer, the expertise that comes from it surely has lasting benefits too.
The sample program is doing 2^7 = 128 NOPs, 4 at a time for 32 cycles, and then it is doing a memory access.
The address of memory that is going to be accessed is known right before doing the 32 cycles of "work", so a prefetch can be issued at that time.
The meaning of the 'prefetch windown' term is the number of cycles that you have between when you issue the prefetch to when you issue the instruction that accesses the address that was prefetched. So it is based on the structure of the program being analyzed.
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".