CoreRT slower then regular .NET

[kant2002]

CoreRT slower then regular .NET

[MichalStrehovsky]

For compute heavy workloads that don't use things like HW intrinsics, I would expect both to be pretty much on par, since codegen is the same.

I would run both under PerfView and check:

• GC Stats - does the GC do more work in one of them?
• Look at CPU samples - are the same methods hot? Is there something that stands out? If so, I would check disassembly on both and compare if we got worse codegen somewhere.

[jkotas]

It is not unusual that performance of CPU-bound microbenchmarks is sensitive to memory alignment, code alignment or other factors that results into trends like this: dotnet/runtime#39031 (comment) . This can be one of these bi-modal cases and you may be just hitting the lucky/unlucky spots on the spectrum.

Another potential source of the difference is that RyuJIT in dotnet/corert is several months old at this point. It is possible that the RyuJIT shipping in .NET 5 has bug fixes that make a difference for this micro-benchmark. This will get fixed once we migrate the project to dotnet/runtimelab and pick up up-to-date RyuJIT.

What can I do to look more closely on this particular case.

Michal's advice in #8354 (comment) is spot on.

[kant2002]

@jkotas Thanks for explanation about potential root causes. I thought that this maybe related to fact that this is micro-benchmark, but do not though that this maybe due to changes in the runtime.

@MichalStrehovsky I would try to look. Since my priority was to have interesting use-case for CoreRT would be better then regular .NET I have to scratch my head a bit to find it.

@RUSshy you can see my benchmarks here https://github.com/kant2002/TurboWavelets.Net/tree/kant/benchmarks this is pretty trivial microbenchmarks, This is not actual project where maybe I will have some gains.