为啥 .NET 不支持 32 位的 SSE（而 ryujit 64 位可以）而 Mono 支持 32 位和 64 位？

Posted 2023-02-16

【中文标题】为啥 .NET 不支持 32 位的 SSE（而 ryujit 64 位可以）而 Mono 支持 32 位和 64 位？

【英文标题】：Why .NET will does not support SSE in 32bit (while ryujit 64bit can) while Mono supports both 32bit and 64bit?为什么 .NET 不支持 32 位的 SSE（而 ryujit 64 位可以）而 Mono 支持 32 位和 64 位？

【发布时间】：2015-03-21 17:50:25

【问题描述】：

Ryujit 将支持 SSE 指令，但 Ryujit 仅适用于 64 位。

由于公司政策和预算（由于测试成本），大多数客户坚持使用 Windows 32 位操作系统。

我的理解是 Ryujit 是新的“针对 64 位优化的 JIT 方案”。

但是，如您所知，SSE 指令集在 32 位和 64 位上退出。

Mono.Simd 适用于 x86 或 Arm 32 位处理器。

（Java SIMD 调用似乎适用于 x86 和 64 位）。

我们的项目是针对任何 CPU 的，所以我很难告诉客户“请使用 Mono，因为他们有 SSE 支持，或者更换 CPU 和操作系统。”

为什么 MS .NET Framework for x86 不提供 SSE 命令支持而 Ryujit 可以？

（我不是 CPU 专家，但我希望 .NET 可以选择“在此命令上强制 SSE（如果可能）”）

【问题讨论】：

这很简单，旧的 JIT 是旧的和遗留的...... Mono 和 RyuJIT 是新的并且支持更多。

许多移动笔记本电脑仍配备 32 位操作系统和 32 位 .net（包括我的）。 “Legacy”一词应该用于旧产品，例如“IE6”、“Clipart”或“Vista”。我认为微软在未来 20 年内不会放弃 32 位操作系统版本。

“丢弃”和“维护”是有区别的。他们正在维护 32 位编译器，而不是为它进行新的开发。就像他们发布 Windows 7 时，他们仍然“支持”了一段时间的 XP，但他们并没有为其开发新功能。如今，大多数移动设备都有 64 位 CPU，而且可能不久之后 MS 就会正式宣布 32 位已死（最多可能再过 2 或 3 年）。

Mono simd 只是一些内在函数，它的恕我直言很差，还有 JIT。在理想主义应用程序中对其进行基准测试，例如泛型/接口并进行比较。它是一个很棒的库，平均运行时间和 Java 相比还有很长的路要走。 32 位 CLR 上的 1.3 gig 内存对于体面的应用程序来说是一个严重的问题。

【参考方案1】：

RyuJIT 基于与 x86 JIT 相同的代码库。虽然它现在仅适用于 x64，但它是一个现代编译器，将成为我们未来所有 JIT 编译器的基础：x86、ARM、MDIL 以及其他任何出现的东西。拥有单一代码库意味着 .NET 程序在体系结构之间更加一致 — 换句话说，您通常会获得 bug 对 bug 的兼容性。但拥有单一代码库也意味着我们可以更快地进行创新并更快地为您带来更多代码生成功能。

RyuJIT: The next-generation JIT compiler for .NET

基本上，他们为 x86、x64、Itanium 和 ARM 构建了 JIT 编译器的四个独立实现。 Itanium 基本上已经死了，但这仍然给了他们三个需要维护的实现，它们几乎没有共同点。

我相信其目的是在 .NET Framework JIT 足够稳定后将其替换为 RyuJIT。事实上，.NET Framework 4.6 包含 RyuJIT 作为 x64 编译器。

【讨论】：

我同意。 RyuJit SIMD 似乎比 MONO.SIMD 更好。我希望 .NET 基金会宣布开发人员（或他们）未来的发展方向。

“RyuJIT 会取代 JIT32 和 JIT64 代码库吗？x86 和 ARM 架构呢？是的，RyuJIT 是我们未来的新 JIT 编译器代码库。我们专注于完成第一个架构，即 X64 . 之后，我们需要与客户（包括内部客户）进行交流，以确定其他架构的顺序。我们知道 x86 在每个人的名单上都名列前茅。”

我想知道完全相同的事情：某些程序（大多数？）需要独立于平台并且适用于 x86 或 x64。上述声明表明，一旦 RyuJIT 足够稳定，最终将应用于所有平台；这似乎是一个合乎逻辑的步骤。有这方面的更新吗？

您现在可以浏览正在开发 .NET Core 的 CoreCLR 存储库 github.com/dotnet/coreclr。问题列表表明 RyuJIT/x86/Windows 主要由 Microsoft 员工 github.com/dotnet/coreclr/issues/6927 开发，而非 MS 开发人员正在 RyuJIT/ARM32/Linux github.com/dotnet/coreclr/issues/3977 开发。

【参考方案2】：

仔细想想，对我来说原因是：

A) Ryujit 是一个新的 JIT 编译器，从头开始构建，所以它可以做一些新奇的事情。他们可能将其限制为 64 位以使其更易于构建，并且由于 64 位上的“当前”JIT 有时比 32 位版本慢，因此在 64 位上“更必要”

B) 作为新的和闪亮的，它更容易包含新的功能/扩展点（例如 SIMD 功能）

C）微软似乎也不想用“旧”的 .NET 编译器来思考（我不认为他们在 .NET 4.5 中做了什么，他们将一些工作转移到后台线程，成为“思考者”太多了”）。如果您仔细观察，您会发现他们从未向 CIL（通用中间语言）、.NET 的汇编语言（他们对 GC 和 .NET 库进行了更改，但它们是不同的）添加了新的操作码“事物”），并且显然要添加他们需要进行更改的 SIMD 功能

D) Mono JIT 比 .NET JIT 的“当前”编译器“更新”（因为 Mono 是后来“诞生”的）。这可以证明它为什么支持 SIMD。

【讨论】：

可能是 1) .NET 32 位可能太旧，MS 无法实现 SSE 支持。 （有许多笔记本电脑仍然使用 32 位操作系统，包括我的……） 2) Microsoft .NET 通常设计为将早期绑定绑定到方法。但是，.NET 也朝着支持 64 位或 128 位的类 J​​ava 方法后期绑定的方向发展。此时，我可以说“如果你想要 32 位 SIMD 支持，请使用 Mono。否则，请将 CPU 和操作系统升级到 64 位以使用 RyuJit 的官方 SSE。”。对于 32 位，它似乎是 Mono。SIMD 可能是更好的选择，只要整个 GUI 组件基于 Mono 库。

【参考方案3】：

随着 .Net Core 2.0 的出现，RyuJit 现在是用于 x86 代码生成的 jit，因此 x86 可以利用 SSE2 来生成通用浮点数和 SSE2/AVX2 SIMD 指令来生成向量。

在即将发布的 .Net Core 2.1 中，您可以找到硬件内部函数的预览，这些内部函数提供对（几乎）x86 和 x64 CPU 上的全部新指令的访问。

目前，我们似乎不太可能将 .Net Framework 改为使用 RyuJit 生成 x86 代码。