关于 Roslyn 、RyuJIT 、LLILC 、CoreRT

关于.NET 编译器相关问题的详细总结：

 在.NET 生态系统中，从代码编写到最终可执行程序的生成，涉及多个关键组件与编译阶段，它们协同工作以满足不同平台和场景的需求。

1.首先是 Roslyn，它作为.NET Compiler Platform，是编译流程的前期（第一阶段）基础。无论在.NET Framework 还是.NET Core 时代，Roslyn 都肩负着将为C#、Visual Basic等语言提供编译为中间语言 MSIL 的重任。它就像是一位严谨的质检员兼初级加工员，仔细检查 C# 代码的语法正确性，运用丰富的编译分析工具，提供了很多编译相关的API供开发者使用，将开发者书写的高级语言代码初步转化为计算机能够进一步处理的 MSIL 形式，，为后续的编译环节奠定基石。

2.进入到编译的第二阶段，也就是将 MSIL 转化为本地机器码，情况在不同平台和技术下有所差异。

       RyuJIT ，是即时编译器，在程序运行时将中间语言（MSIL）实时编译为本地机器码，能根据程序运行情况优化代码，让程序在不同硬件平台高效运行。它是.NET Framework 4.6及.NET Core中替代 旧JIT编译器（framework时代） 的新即时编译器，是.NET Core 运行时（CoreCLR）所倚重的即时编译器。想象它是一台智能高效的实时加工设备，只要程序基于 CoreCLR 运行，无论底层是 Windows 平台，还是 Linux、macOS 等非 Windows 平台，在程序运行过程中，RyuJIT 都会迅速介入，将 MSIL 即时编译成适配当前硬件环境的本地机器码，并且它能够依据程序运行时的数据和状态动态优化编译结果，确保程序流畅高效地运行。

       LLILC ，为了实现多平台的支持，.NET Core早期引入了LLILC等技术，依托强大的 LLVM（Low Level Virtual Machine）编译器基础架构，支持即时编译（JIT）和提前编译（AOT）。

        它像是一座为非 Windows 世界搭建的编译桥梁，既包含了 RyuJIT 的部分功能来实现即时编译（JIT），就好比借鉴了 RyuJIT 即时加工的一些成熟工艺，让非 Windows 平台上的.NET Core 程序也能快速将 MSIL 转化为本地码即时运行，当然它也不只针对非Windows平台；同时，LLILC 还有着宏伟的 AOT（提前编译）蓝图，计划利用 LLVM 的优化器和代码生成器独立打造一套 AOT 编译体系，旨在把 MSIL 提前编译成目标平台的本地机器码，从而大幅提升程序启动速度，减少运行时因编译带来的开销，是对RyuJIT在非Windows平台上的一种扩展和补充，为.NET Core 在非 Windows 平台（ Linux、macOS等）的广泛应用提供有力支撑。但实际上.NET Core的跨平台支持主要依赖于RyuJIT，随着RyuJIT不断的优化改进，而LLILC可能并未成为主流，维护成本和门槛较高，在2017年已停止。（历史方案）。

       CoreRT 聚焦于 AOT 编译领域，致力于为.NET 应用开辟高性能的执行路径，是个独立的编译器。它可以利用RyuJIT（一部分现有功能）作为AOT编译器将IL编译成机器码，也可以将C#代码编译成C++代码，再通过平台的C++编译器优化成机器码。CoreRT主要用于提前编译，以提高程序的启动性能和减少运行时的内存占用等，适用于对性能要求较高的场景，如移动应用、嵌入式设备等。它仿佛是一个专业的预定制工厂，目标明确地在构建时期就将 MSIL 转换成平台本地的机器码，可缩短程序启动时间、减少内存占用。虽然 CoreRT 有自己完整的 AOT 编译架构，但在生成机器码环节巧妙借助了 RyuJIT 的部分能力，把 RyuJIT 当作一个关键的代码生成引擎，整合进自身流程，结合自身对启动性能、内存管理等方面的优化策略，让最终生成的可执行程序在诸如物联网、移动应用等对性能和资源占用严苛的场景下表现卓越，并且同样能在多平台（Windows、Linux、macOS 等）大显身手。需要注意的是，LLILC和CoreRT是不同的技术方案，LLILC的AOT方式也并不是选择使用CoreRT进行AOT编译。CoreRT有自己独立的AOT编译流程，虽然它可以利用RyuJIT作为AOT编译器将IL编译成机器码，和LLILC的AOT编译计划是相互独立的，LLILC是计划发展自己基于LLVM的AOT编译能力，而不是直接使用CoreRT进行AOT编译。

       CoreRT 目前已被.NET 的 native AOT 取代。CoreRT 是微软一个长期开源项目，旨在将.NET Core 托管应用程序编译为本地单一可执行文件。但自2018年起，官方就不再积极维护。由于社区需求以及微软合作伙伴项目需要 AOT 技术，该项目以 NativeAOT 的名字转移到了runtimelab，并作为.NET 6的最高优先级实验性工作项。目前，NativeAOT 基本已经完成，剩余一些修补和完善工作，以及对新版本.NET 的跟进。.NET官方仓库中也已表明CoreRT项目已被dotnet/runtimelab仓库中的NativeAOT实验所取代，.NET 7+正式支持 Native AOT。

3.综上所述，早期 Roslyn 开启编译前端大门，RyuJIT、LLILC 和 CoreRT 在后端编译阶段各显神通，它们凭借各自独特的设计与功能，或即时编译、或提前编译，相互配合又各有侧重，共同助力.NET 代码在不同平台上绽放光彩，满足从桌面到移动端、从服务器到物联网设备等多样化的开发与运行需求。

         1.历史项目更迭：LILC（2015-2017）→ RyuJIT跨平台优化                  CoreRT（2016-2020）→ Native AOT（.NET 6+）

         2.RyuJIT（生产环境主力）

1. • 架构特点：

     • 多阶段编译管道（导入/分层编译/代码生成）

     • SIMD指令自动向量化支持

     • 基于Profile的优化（Tiered Compilation）

   • 跨平台能力：

     • Windows（x86/x64/ARM）

     • Linux/macOS（x64/ARM64）

   • 性能特征：平均提升15% vs 旧JIT

2. LLILC（历史方案）

   • 技术路线：基于LLVM的JIT实现

   • 项目状态：2017年停止开发

   • 遗产影响：推动RyuJIT跨平台改进

4.补充：编译方式相关

AOT（提前编译）：是在程序运行前将代码编译为目标平台机器码，优点是启动快、运行效率高，缺点是失去即时编译根据运行时环境优化的能力，且不同平台要分别编译。CoreRT、LLILC支持AOT编译。

- JIT（即时编译）：程序运行时才将MSIL编译为机器码，可根据运行时环境和数据动态优化，有较好跨平台性，但首次执行代码有编译延迟，可能影响启动速度。RyuJIT、LLILC支持JIT编译

 

 

 

维度	JIT编译	AOT编译
编译时机	运行时按需编译	构建期全量编译
启动速度	首次执行延迟	即时启动
内存占用	需要运行时内存	独立进程无额外开销
优化潜力	支持运行时Profile优化	依赖静态分析优化
部署单元	需附带运行时环境	单一可执行文件
调试支持	完整调试符号支持	需要独立符号文件

1. 服务端应用：

   • 推荐方案：RyuJIT默认模式

   • 优化技巧：启用TieredCompilation

2. 客户端应用：

   • 首选方案：Native AOT（.NET 8+）

   • 注意事项：反射使用需预配置