Why .NET will does not support SSE in 32bit (while ryujit 64bit can) while Mono supports both 32bit and 64bit?

Question

Ryujit will will support SSE instructions, however Ryujit is only for 64bit.

Most of customer stick to Windows 32 bit OS because of company policy and budget (due to testing cost).

My understanding is Ryujit is new "JIT scheme optimized for 64bit".

However, as you know, SSE instructions set exits on 32 bit and 64 bit.

Mono.Simd works x86 or Arm 32 bit processor.

(Java SIMD call seems to work on x86 and 64bit).

Our project is for any CPU, so it is very difficult for me to tell customer that "Please use Mono, because they have SSE support, or change CPU and OS."

Why MS .NET Framework for x86 does not provide with SSE command support while Ryujit can?

(I am not CPU specialist, but I hope if .NET have an options to choose "force SSE on this command(if possible)")

Answer 1

By thinking about it, for me the reason are:

A) Ryujit is a new JIT compiler, built from scratch, so it can do new and wonderful things. They probably restricted it to 64 bits to make it easier to build it, and because the "current" JIT on 64 bits sometimes was slower than the 32 bits version, so it was "more necessary" on 64 bits

B) Being new and shiny, it is easier to include new functions/extension points (SIMD functions for example)

C) Microsoft doesn't seem want to thinker too with the "old" .NET compiler (I don't consider what they did in .NET 4.5, where they moved some work to a background thread, to be "thinker too much"). If you look closely, you'll see they haven't ever added new OpCodes to the CIL (Common Intermediate Language), the assembly language of .NET (they did changes to the GC and to the .NET libraries, but these are different "things"), and clearly to add SIMD functions they would need to do changes

D) The Mono JIT is "newer" than the .NET JIT "current" compiler (because Mono was "born" later). This can justify why it does support SIMD.

Answer 2

RyuJIT is based off of the same codebase as the x86 JIT. While it’s only for x64 right now, it’s a modern compiler that will be the basis of all our JIT compilers in the future: x86, ARM, MDIL and whatever else comes along. Having a single codebase means that .NET programs are more consistent between architectures—put another way, you generally get bug-for-bug compatibility. But having a single codebase also means we can innovate faster and bring you more code generation features more quickly.

• RyuJIT: The next-generation JIT compiler for .NET

Basically they built four separate implementations of the JIT compiler, for x86, x64, Itanium and ARM. Itanium is basically dead but that still gives them three implementations to maintain which have very little in common.

I believe the intent is to replace the .NET Framework JIT with RyuJIT once it's sufficiently stable. Indeed the .NET Framework 4.6 includes RyuJIT as the x64 compiler.

Answer 3

With the advent of .Net Core 2.0, RyuJit is now the used jit for x86 code generation, and so enables x86 to take advantage of SSE2 for general floating point and SSE2/AVX2 SIMD instructions for Vector.

In the about-to-be released .Net Core 2.1 you can find a preview of hardware intrinsics that provide access to (nearly) the full range of new instructions on both x86 and x64 CPUs.

At the present time it seems unlikely that we will change .Net Framework over to using RyuJit for x86 code generation.