Repository navigation
Provide block counts in tiered compilation from R2R images #13672
Description
Tiered compilation can reduce the performance of application by replacing IBC tuned R2R code with non-tuned jitted code. See #13451 Consider enhancing the R2R format to allow method block counts to be stored in R2R images and used by the runtime. This is causing a ~20% regression in the performance of the StringBuilder.Append code
Activity
EgorBo commentedon Oct 28, 2019
Not sure it's related but today I found this gem:
https://github.com/dotnet/coreclr/blob/8460516ceb23458f7a279bb73aa6176e17e8a90d/src/jit/emit.cpp#L4542-L4552
PS: Don't we need a kind of
deoptimizationin order to rely on PGO data? E.g. something in the app session changed and now blocks' weights are not relevant anymore.BruceForstall commentedon Oct 28, 2019
cc @briansull @AndyAyersMS
briansull commentedon Oct 28, 2019
Yes, That is already what we do when a method is modified and the ILsize no longer matches.
https://github.com/dotnet/coreclr/blob/2f1d783cbaa806981c6640d85a28da8f5875b735/src/jit/compiler.cpp#L3516-L3533
davidwrighton commentedon Oct 29, 2019
I think that @EgorBo is referring to the idea that the application may have different typical pathways through code than the training data. While this is a serious concern, historically we've had this problem for the binaries we shipped to customers for many years on the desktop framework, and the performance impact was not a large problem for the scenarios where our optimizations have kicked in in unfortunate ways.
I believe (but do not have strong evidence for my belief) that this is due to the fairly limited sets of optimizations that take advantage of this profile data. I also believe this to be a higher risk if we start to take a heavier dependence on profile data for optimizations such as devirtualization. Since our training scenarios are quite limited in CoreCLR, I expect that when we implement this feature, we will have a good opportunity to observe potential positive/negative effects on our performance results and make a judgement of regressions at that time.
sergiy-k commentedon Nov 12, 2019
/cc: @kouvel
davidwrighton commentedon Aug 10, 2020
This work won't make .NET 5.
davidwrighton commentedon Jul 8, 2022
EgorBo is working on this with #70941
mangod9 commentedon Aug 5, 2022
@EgorBo do we expect this to make it into 7?
davidwrighton commentedon Aug 8, 2022
We implemented this particular feature with
--embed-pgo-datawhich we use only for System.Private.CoreLib. @EgorBo's work provides the ability to get live runtime based pgo data, which is even better.