JIT: don't set edge weights to zero for inconsistent profiles #87947
Conversation
With the advent of scalable profile counters (or even with the old racing counters) counts might be approximate or inconsistent. When we run across a negative count during reconstruction, set the afflicted count to a small positive value instead of to zero, since zero has special meaning to the JIT. The aim is to reduce some of the benchmark instability we are seeing in dotnet#87324. Depending on exact counter values, we can see different sets of edge weights (and hence block weights) from run to run.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsWith the advent of scalable profile counters (or even with the old racing counters) counts might be approximate or inconsistent. When we run across a negative count during reconstruction, set the afflicted count to a small positive value instead of to zero, since zero has special meaning to the JIT. The aim is to reduce some of the benchmark instability we are seeing in #87324. Depending on exact counter values, we can see different sets of edge weights (and hence block weights) from run to run.
|
|
@EgorBo PTAL Small number of diffs/missed contexts expected. |
src/coreclr/jit/fgprofile.cpp
Outdated
| // If we end up with negative edge weights because of inconsistent counts, we use this factor to | ||
| // substitute a small positive one. | ||
| // | ||
| weight_t const smallFactor = 0.001; |
There was a problem hiding this comment.
there is ProfileSynthesis.epsilon that probably can be used here?
There was a problem hiding this comment.
Yea, good idea. Updated.
With the advent of scalable profile counters (or even with the old racing counters) counts might be approximate or inconsistent. When we run across a negative count during reconstruction, set the afflicted count to a small positive value instead of to zero, since zero has special meaning to the JIT.
The aim is to reduce some of the benchmark instability we are seeing in #87324. Depending on exact counter values, we can see different sets of edge weights (and hence block weights) from run to run.