▌循环对齐
内存对齐是现代计算中各种操作的共同要求 。 在 .NET 5 中 ， 我们开始在 32 字节边界对齐方法 。 在 .NET 6 中 ， 我们添加了一项执行自适应循环对齐的功能 ， 该功能在具有循环的方法中添加NOP填充指令 ， 以便循环代码从 mod(16) 或 mod(32) 内存地址开始 。 这些更改改进并稳定了 .NET 代码的性能 。
在下面的冒泡排序图中 ， 数据点 1 表示我们开始在 32 字节边界对齐方法的点 。 数据点 2 表示我们也开始对齐内部循环的点 。 如您所见 ， 基准测试的性能和稳定性都有很大提高 。

文章图片

▌硬件加速结构
结构是 CLR 类型系统的重要组成部分 。 近年来 ， 它们经常被用作整个 .NET 库中的性能原语 。 最近的例子ValueTask是ValueTuple和Span<T> 。 记录结构是一个新的例子 。 在 .NET 5 和 .NET 6 中 ， 我们一直在提高结构的性能 ， 部分原因是通过确保结构是局部变量、参数或方法的返回值时可以保存在超快速 CPU 寄存器中） 。 这对于使用向量计算的 API 特别有用 。
▌稳定性能测量
团队中有大量从未出现在博客上的工程系统工作 。 这对于您使用的任何硬件或软件产品都是如此 。 JIT 团队开展了一个项目来稳定性能测量 ， 目标是增加我们内部性能实验室自动化自动报告的回归值 。 这个项目很有趣 ， 因为需要进行深入调查和产品更改才能实现稳定性 。 它还展示了我们为保持和提高绩效而衡量的规模 。

文章图片

此图像演示了不稳定的性能测量 ， 其中性能在连续运行中在慢速和快速之间波动 。 x 轴是测试日期 ， y 轴是测试时间 ， 以纳秒为单位 。 到图表末尾（提交这些更改后） ， 您可以看到测量值稳定 ， 结果最好 。 这张图片展示了一个单一的测试 。 还有更多测试在dotnet/runtime #43227中被证明具有类似的行为 。
即用型代码/Crossgen 2
Crossgen2 是crossgen 工具的替代品 。 它旨在满足两个结果：

• 让crossgen开发更高效 。
  
• 启用一组目前无法通过 crossgen 实现的功能 。
  

这种转换有点类似于本机代码 csc.exe 到托管代码Roslyn 编译器 。 Crossgen2 是用 C# 编写的 ， 但是它没有像 Roslyn 那样公开一个花哨的 API 。
我们可能已经/已经为 .NET 6 和 7 计划了六个项目 ， 这些项目依赖于 crossgen2 。 矢量指令默认提议是我们希望为 .NET 6 但更可能是 .NET 7 进行的 crossgen2 功能和产品更改的一个很好的例子 。 版本气泡是另一个很好的例子 。
Crossgen2 支持跨操作系统和架构维度的交叉编译（因此称为“crossgen”） 。 这意味着您将能够使用单个构建机器为所有目标生成本机代码 ， 至少与准备运行的代码相关 。 但是 ， 运行和测试该代码是另一回事 ， 为此您需要合适的硬件和操作系统 。
第一步是用crossgen2编译平台本身 。 我们使用 .NET 6 完成了所有架构的任务 。 因此 ， 我们能够在此版本中淘汰旧的 crossgen 。 请注意 ， crossgen2 仅适用于 CoreCLR ， 而不适用于基于 Mono 的应用程序（它们具有一组单独的代码生成工具） 。
这个项目——至少一开始——并不以性能为导向 。 目标是启用更好的架构来托管 RyuJIT（或任何其他）编译器以离线方式生成代码（不需要或启动运行时） 。
你可能会说“嘿……如果是用 C# 编写的 ， 难道你不需要启动运行时来运行 crossgen2 吗？” 是的 ， 但这不是本文中“离线”的含义 。 当 crossgen2 运行时 ， 我们不使用运行 crossgen2 的运行时附带的 JIT 来生成准备运行 (R2R) 代码. 那是行不通的 ， 至少对于我们的目标来说是行不通的 。 想象一下 crossgen2 在 x64 机器上运行 ， 我们需要为 Arm64 生成代码 。 Crossgen2 将 Arm64 RyuJIT（针对 x64 编译）加载为原生插件 ， 然后使用它生成 Arm64 R2R 代码 。 机器指令只是保存到文件中的字节流 。 它也可以在相反的方向工作 。 在 Arm64 上 ， crossgen2 可以使用编译为 Arm64 的 x64 RyuJIT 生成 x64 代码 。 我们使用相同的方法来针对 x64 机器上的 x64 代码 。 Crossgen2 会加载一个 RyuJIT ， 它是为任何需要的配置而构建的 。 这可能看起来很复杂 ， 但如果您想启用无缝的交叉定位模型 ， 它就是您需要的那种系统 ， 而这正是我们想要的 。