Add repeatCount in superpmi.exe to repeat the compilation of 1 or more methods
#93417
Conversation
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsI wanted to investigate the TP of 1 particular method and why it takes longer to JIT. Using superpmi if I can compile it multiple times I can see the area that is slow. One option would be to specify the method context id in
|
|
@dotnet/jit-contrib |
| for (int iter = 0; iter < o.repeatCount; iter++) | ||
| { |
There was a problem hiding this comment.
It seems like we shouldn't need to change the MethodContextReader at all. Instead of the "repeatCount" loop here, couldn't it be just before the CompileResult* crl = mc->cr; line? (There might need to be some kind of saving/restoring of the originalCR).
There was a problem hiding this comment.
possibly, the problem with that though is that the display of percent completion report will be slower. E.g. if someone pass -repeatcount 10000 for entire mch, the time after which you would see the console output would be after 10000 * 500 compilations.
There was a problem hiding this comment.
It seems wrong that the MethodContextReader should have any knowledge of the repeatCount.
How about have the repeatCount loop include the %complete logging, and displayed % complete would be repeatIteration * reader->PercentComplete() / repeatCount. For a repeatCount of 1, this would be no change.
Then, change it to output every 500 iterations whether that is due to loadedCount or repeatCount, e.g.,
if ((totalIterations++ % 500 == 0) && (loadedCount > 0))
There was a problem hiding this comment.
How about have the repeatCount loop include the %complete logging, and displayed % complete would be
repeatIteration * reader->PercentComplete() / repeatCount. For a repeatCount of 1, this would be no change.
My math here is wrong. It would need to be:
100.0 * (((reader->CurrentCount() - 1) * repeatCount + repeatIteration) / (repeatCount * reader->TotalCount())
for newly exposed MethodContextReader curIndexPos (as CurrentCount()) and IndexCount (as TotalCount())
(this depends on curIndexPos returning 1 when you're processing the first method context. curIndexPos and IndexCount also depend on there being a .MCT file, which there isn't always, in which case we would have to return the pos/fileSize like PercentComplete does, which wouldn't be as accurate.)
There was a problem hiding this comment.
sorry, just seeing your comment. One of the other problem of moving loop to iterate over jit->CompileMethod() is that it will be a tight loop without showing the % progress unless we add another LogVerbose inside it. So for eg, if I pass -c 59 -repeatCount 10000, i am expected to see % completion after every 500 iterations or so. Unless I am misunderstanding your suggestion of where to add the logging.
Passing `-repeatCount N` for some integer `N > 0` will compile each function `N` times. This is true for each function in the MCH file, by default, or each one specified by a `-c` argument or .mcl file. This can be used to help investigate the JIT throughput for compilation of a particular function or set of functions. This is based on dotnet#93417.
|
Replaced by #94503 |
Passing `-repeatCount N` for some integer `N > 0` will compile each function `N` times. This is true for each function in the MCH file, by default, or each one specified by a `-c` argument or .mcl file. This can be used to help investigate the JIT throughput for compilation of a particular function or set of functions. This is based on #93417.
I wanted to investigate the TP of 1 particular method and why it takes longer to JIT. Using superpmi if I can compile it multiple times I can see the area that is slow. One option would be to specify the method context id in
mclfile repeatedly, but we have a check that they should be incremental. So I added a-repeatCountflag that will compile a single context id or entiremchfile specified number of times, which will help in gathering accurate profile information.Edit: For now, I did not propagated to
superpmi.pyand can be done if people find this option useful.