Open kotlarmilos opened 1 year ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
@kotlarmilos if this affected Mono iOS sample size it probably regressed MAUI iOS sizes as well. Do you know if this is being tracked already?
Good point, https://github.com/dotnet/runtime/pull/78182 is not backported to .net7
so the regression is not present in MAUI iOS size measurements. I haven't found an issue related to the regression in MAUI iOS.
/cc @jonathanpeppers
So the extra methods look to be Vector/Scalar method instances, these were previously shared, but now we generate specialized instances for them, leading to the size increase.
Most of these methods appear to be the fallback methods in case SIMD is not found. If SIMD is enabled on ios, then this code will not be called, if it's not enabled, then the app should not call it since the performance is not good. So there should be a way to avoid generating code for them.
Most of these methods appear to be the fallback methods in case SIMD is not found. If SIMD is enabled on ios, then this code will not be called, if it's not enabled, then the app should not call it since the performance is not good. So there should be a way to avoid generating code for them.
@vargaz just to clarify, are you suggesting that:
If SIMD is enabled, then these methods are never going to be called. So putting a
if (!SIMDIsEnabled)
If I am understanding this correctly, something similar was attempted here: https://github.com/dotnet/runtime/issues/71430#issuecomment-1185618983 where in my experimentation I tried to exclude Scalar fallbacks, which turned out to be impossible -> ie software fallbacks are needed even on arm64 architectures. Am I missing the point?
Was just an idea, not sure whenever it will work.
I guess this comment: https://github.com/dotnet/perf-autofiling-issues/issues/9599#issuecomment-1310570220 goes along with what Zoltan said. If I understand correctly, before going further, we would need to have SIMD work completed on the Mono side.
All the SIMD support that we added so far should be fully enabled for full AOT mode, which is what iOS is using. @vargaz Are the size increase here caused by code patterns involving generics, which used to be generated into a gsharedvt function, now generated into concrete type instances to facilitate the previous performance regression?
Previously, we were emitting shared methods, now we emit the same shared methods (to handle all cases) and concrete instances as well (for better performance).
Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar See info in area-owners.md if you want to be subscribed.
Author: | kotlarmilos |
---|---|
Assignees: | vargaz, kotlarmilos |
Labels: | `tenet-performance`, `area-Codegen-AOT-mono`, `size-reduction` |
Milestone: | 8.0.0 |
Description
Microbenchmark improvement https://github.com/dotnet/runtime/pull/78182 introduced concrete instances in addition to the gshared methods in AOT mode to optimize https://github.com/dotnet/runtime/issues/78163.
For Mono iOS sample app, binary disk size (SOD) has increased by 8%.
Number of symbols has increased by 5k.
At the same time https://github.com/dotnet/runtime/commit/80208e61520ac6dce0acf543d5e25d4599faa7b7 excluded dynamic libraries from the bundle as static linking is used.
For Mono iOS sample app, SOD has decreased by 5%.
cc @ivanpovazan
Configuration
OS: iOS Architecture: arm64 .NET version: 7.0.100-rc.1.22431.12