Repository navigation
Potential perf improvements for Mono AOT #76318
Description
#73768 has brought a lot of improvements for CLR, but regressed Mono. It was "reverted" in #75917 to fix Mono.
When looking at the WASM and Mono data in the Reporting System I've noticed that Mono AOT (regular one, not WASM) was actually benefiting from #73768
Example:
I am not 100% sure that it applies to all architectures, as Mono AOT arm64 has not received any new data inputs in the last few weeks (cc @naricc @DrewScoggins).
It does not apply to Mono Interpeter:
@vargaz @jkotas should we modify the #if defs introduced in #75917 to not be applied to Mono AOT? I think that doing this for main branch should be relatively safe (as long as we benchmark the change before merging).
Activity
adamsitnik commentedon Sep 28, 2022
We could also apply it to WASM AOT config (#75801)
jkotas commentedon Sep 28, 2022
We do not build separate libraries for Mono AOT vs. non-AOT config. We have one set of managed libraries per architecture, for all codegen strategies. You would not be able to do this using
#ifdef. It would need to be some sort of new intrinsic and the check done dynamically.Also, there are mixed partially AOTed configs where the AOT vs. non-AOT is difference is per method. It makes the switch even harder.
naricc commentedon Sep 28, 2022
I don't think there is a way to distinguish aot/non-aot in an
#ifdef, is there?@lewing
jkotas commentedon Sep 28, 2022
I think this can be closed.
We need to fix the Mono limitations that lead to the bad perf regressions, and delete the forked implementation that was added as a workaround for .NET 7. It is ok to take small perf regressions in some scenarios.
jeffhandley commentedon Sep 28, 2022
Great; thanks for the clarification that we cannot distinguish aot/non-aot in that manner. @adamsitnik and I wanted to confirm we weren't overlooking a different way to dial this for 7.0.
lewing commentedon Sep 28, 2022
#76033 will likely fix the (most of) the wasm AOT case were we to revert but we don't yet have a solution for the interpreter
adamsitnik commentedon Sep 28, 2022
@lewing do we have an issue for tracking this? #76033 has closed #75801 and I can't find interpreter issue