Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Regressions from switching corelib to R2R #22128
We have enough perf history now that we can call out a few regressions from #21497, where corelib prejitting was changed from fragile ngen to R2R.
Crypto regressed ~4% on windows (505 -> 525) and ~6% on linux (515 -> 545)
Csc/Dataflow regressed ~5% on windows (413 -> 432) and ~5% on linux (450 -> 470, noisy)
PerfLab / GetMethod20 regressed ~7% (3.52 -> 3.72). The other GetMethod tests regressed as well.
There may be some other cases that turn up -- will add them here.
I would primarily interested in cases where switch to R2R regressed perf and tiered JITing does not recover the regression. Do we have any cases like that? Those would be P1 to look into.
The regressions in compute intensive benchmarks with R2R and tiered JITing disable are P2. We can look at them to see whether it is something easy to fix, but we know that the R2R is not perfect by design. We expect tiered JIT to recover the loss and in places to generate even better code than what fragile NGen for CoreLib ever had.
@jkotas essentially, micro benchmarks run multiple iterations within a loop, and discard the warmup iteration. Thus, most of them do not report tiering information. For tier jitting we use real-world scenarios such as JitBench/MusicStore.