Hi, I'm working on some optimizations of our software and use the packages System.Memory and System.Numerics.Vector. Both are relying on optimizations in RyuJIT. Our software runs mainly on .NET Framework (not CoreCLR) and most of these optimizations are not available at the moment (please correct me if I'm wrong here).
I would like to know if there are any plans to port these jitter optimizations to .NET
Thanks
AFAIK Some optimizations are backported to .Net, you have to force using the latter versions like 4.7.
If you run a benchmark in benchmarkdotnet (it's a nuget and a github project), it outputs the version of JIT in use, so presumably there's a programmatic way of determining the JIT version (and that code is in the git repo somewhere).
In recent tests I've been doing I've noticed that the .NET 4.7 framework is using the same (latest) RyuJIT version as dotnet core 2.0. And FYI if you're on Windows 10 you get .Net 4.7 as part of one of the big updates (one the recent 'creator' editions), - I don't think you can install it via other means, not officially anyway.
I've also been working with System.Numerics.Vectors and can tell you that it all works in .NET framework 4.7 - i.e. it is generating SIMD CPU instructions and you'll also see Vector.IsHardwareAccelerated return true - but only if the build is set to have optimizations enabled (usually this means a release build).
The relevant file in bencharkdotnet is:
But it appears the JIT version is inferred from several things, one of which is the absence/presence of a specific bug in the legacy jitter. Anyways bottom line is that the optimizations you seek are in .NET 4.7 to the best of my knowledge.
Also see:
@JosephTremoulet, can you shed some light on this?
RyuJIT sources are shared between .NET Core and .NET Framework, so any RyuJIT changes that go into .NET Core will make their way into .NET Framework in a point release or two. A few things muddy the waters, though:
1) The release cycles are somewhat independent, so there's no guarantee that the RyuJIT bits in version X of .NET Framework neatly line up with the RyuJIT bits in some version Y of .NET Core. That said, I do believe that .NET Core 2.0 and .NET Framework 4.7.1 line up pretty well.
2) Some things that are largely JIT optimizations have runtime components, and the porting of runtime changes happens more manually because it's so important to maintain backwards compatibility in .NET Framework. For example, the .NET Framework VM type system code doesn't have the new functionality that the .NET Core one does to support devirtualization, so this doesn't fire on .NET Framework yet, despite having the JIT bits.
/cc @dotnet/jit-contrib
Actually most of devirtualization is enabled on desktop and will appear in 4.7.1 which is going to be released soon. There are preview bits available now for many Windows versions..
Thank you for the great answers.
It would be nice to have some kind of documentation about these optimizations for a given .NET version. I couldn't find anything in the 4.7.1 release notes.
I put a question in the Microsoft/dotnet repo
Optimizations is a moving target and docs will easily become outdated. The best thing you can do is follow the "tenet-performance" and "optimization" tags on issues on both CoreFX and CoreCLR. That way you can also learn the tricks used to make sure those optimization hit.
@redknightlois I do. But that is all about Core. I stick on desktop
Roughly speaking we have the following correspondence between CoreClr and Desktop for x64 RyuJit. It is not exact, but for optimizations, it should be fairly reliable:
| CoreCLR | Desktop |
| ----- | -----|
| 1.0 | 4.6.2 |
| 1.1 | 4.7.0 |
| 2.0 | 4.7.1 |
I believe we're working on a summary of the jit optimizations that are new in 4.7.1 (and hence, new in 2.0) so we can add this information to the release notes. @briansull may know more.
FYI, there were roughly 800 non-merge commits in the jit subtree between 1.1 and 2.0. Not all of these were optimization related, but a fair number were.
Think this is clear now. Thank you.
Most helpful comment
RyuJIT sources are shared between .NET Core and .NET Framework, so any RyuJIT changes that go into .NET Core will make their way into .NET Framework in a point release or two. A few things muddy the waters, though:
1) The release cycles are somewhat independent, so there's no guarantee that the RyuJIT bits in version X of .NET Framework neatly line up with the RyuJIT bits in some version Y of .NET Core. That said, I do believe that .NET Core 2.0 and .NET Framework 4.7.1 line up pretty well.
2) Some things that are largely JIT optimizations have runtime components, and the porting of runtime changes happens more manually because it's so important to maintain backwards compatibility in .NET Framework. For example, the .NET Framework VM type system code doesn't have the new functionality that the .NET Core one does to support devirtualization, so this doesn't fire on .NET Framework yet, despite having the JIT bits.
/cc @dotnet/jit-contrib