编译原理-动态类型语言不使用JIT-02
Just-in-time compilation tends to be the fastest way to implement a dynamically-typed language, but not all of them use it. What reasons are there to not JIT?
为什么有些动态类型语言选择不使用 JIT（Just-in-time，即时编译）技术??
尽管 JIT 通常被认为是实现动态类型语言最快的方式，但它并非“银弹”，在某些场景下，不使用 JIT 反而是更优或更务实的选择。主要原因可以归结为以下几点：
实现复杂性高 (High Implementation Complexity)
技术门槛高： 从零开始构建一个高效且稳定的 JIT 编译器是一项极其复杂的系统工程。它需要深厚的编译器理论知识、对特定硬件架构（如 x86-64, ARM）的深入理解，以及处理内存管理、线程安全和代码生成等复杂问题的能力。这对于一个项目（尤其是开源项目）的早期或资源有限的团队来说，是一个巨大的挑战。
维护成本高： JIT 编译器一旦建成，就需要持续的维护和优化。随着新的 CPU 架构和指令集的出现，JIT 编译器也需要跟进更新才能保证最佳性能。这无疑增加了项目的长期维护负担。
启动速度和预热时间 (Startup Speed & Warm-up Time)
冷启动延迟： JIT 的核心思想是在运行时分析和编译热点代码（hotspot）。这意味着程序启动初期，代码是解释执行的，速度较慢。JIT 编译器需要花费一定时间来监测代码、识别热点、进行编译。这个过程会导致程序的启动速度变慢，对于需要快速启动和响应的短时任务（如命令行工具、脚本）来说，这可能是个明显的缺点。用户可能会感觉到“一顿一顿”的，直到 JIT 完成预热，程序才达到峰值性能。
内存消耗： JIT 编译器本身会消耗内存。它需要存储代码的中间表示、性能分析数据以及最终生成的机器码。对于内存受限的环境（如嵌入式设备、小型服务器实例），这部分额外的内存开销可能是不可接受的。
可移植性 (Portability)
平台相关性： JIT 编译器的后端（代码生成器）是高度依赖于特定 CPU 架构的。如果要让语言支持多种硬件平台（如 x86, ARM, RISC-V 等），就需要为每个平台单独开发或适配代码生成器。相比之下，一个纯粹的解释器（Interpreter）只需要用标准 C 语言编写，就可以在任何支持 C 编译器的平台上编译和运行，可移植性要好得多。
CPython 的例子： Python 的官方实现 CPython 就是一个很好的例子。它的首要目标之一就是极佳的可移植性。CPython 几乎可以在任何你听说过的操作系统和硬件上运行，这在很大程度上得益于其相对简单的、基于字节码的解释器模型。虽然像 PyPy 这样的 JIT 实现速度快得多，但它的平台支持范围就不如 CPython 广泛。
机器码：底层硬件执行
字节码：虚拟机执行
安全性和确定性 (Security & Determinism)
安全风险： JIT 编译器在运行时动态生成可执行代码，这在某些高度安全敏感的环境中可能是一个风险点。动态生成的代码可能会增加攻击面，例如，通过 JIT 喷射（JIT Spraying）等技术进行恶意攻击。因此，一些操作系统或环境会限制或禁止在运行时生成和执行代码的权限（例如，iOS 的早期版本对 JIT 就有严格限制）。
可预测性差： JIT 的性能表现不是线性的。它的“预热”过程意味着程序的性能在运行时会发生变化。对于需要恒定、可预测性能的场景（如硬实时系统），这种不确定性是不可接受的。解释器虽然慢，但其性能通常是稳定且可预测的。
生态系统和 C 语言扩展 (Ecosystem & C Extensions)
与 C 的交互： 许多动态语言（如 Python 和 Ruby）拥有庞大的、用 C 语言编写的扩展库生态系统。这些扩展库通常深度依赖于语言的内部实现细节（ABI - Application Binary Interface）。引入一个复杂的 JIT 编译器可能会彻底改变这些内部接口，导致大量现有的 C 扩展库失效或需要大规模重写。这对于社区来说是一个巨大的迁移成本和阻碍。CPython 在这方面就是一个典型的例子，其庞大的科学计算（NumPy, SciPy）和数据科学生态系统深度绑定了 CPython 的 C API。
简单来说，不使用 JIT 的决策是一个在 峰值性能 (Peak Performance) 与 实现/维护成本 (Cost)、启动速度 (Startup Speed)、可移植性 (Portability) 和生态兼容性 (Ecosystem Compatibility) 之间的权衡。
因此，如果一个语言的设计目标更看重 跨平台能力、快速启动、简单的实现和对现有 C 扩展生态的兼容性，那么选择一个更简单的解释器模型，而不是 JIT，就是一个完全合理且明智的工程决策。
但是最近的GPU 并行计算技术，例如：快速发展的triton技术为什么拥有巨大威力？
这个问题非常好，它完美地展示了技术决策中的“权衡”（trade-off）思想。Triton 的成功，恰恰说明了 JIT 技术在特定领域（Domain-Specific）应用时的巨大威力，也让我们能更深刻地理解为什么通用语言（如 CPython）不默认使用 JIT。
什么是 Triton？
Triton 是由 OpenAI 开发的一种开源编程语言和编译器，专门用于编写高效的 GPU 计算核心（Kernel）。在 PyTorch 2.0、DeepMind 等项目中被广泛采用。
它的工作流程是：
用户使用一种类似 Python 的语法编写 GPU 计算逻辑。
Triton 的 JIT 编译器在运行时（当你的 Python 代码调用这个 Triton 函数时）将这段代码编译成高度优化的 GPU 机器码（PTX 或 SASS）。
这段机器码随后在 GPU 上执行。
Triton 如何“规避”了传统 JIT 的缺点？
Triton 的成功，正因为它所处的领域（GPU 并行计算）使得传统 JIT 的缺点不再是问题，反而其优点被无限放大。我们来逐一对比之前提到的“不使用 JIT 的理由”：
实现复杂性 (High Implementation Complexity)：
传统 JIT 的问题： 为通用语言（如 Python）写一个能处理各种代码模式的 JIT 非常复杂。
Triton 的情况： Triton 的目标非常专注。它不处理文件 IO、字符串操作或复杂的类继承，它只专注于一件事：大规模并行的数据计算（特别是张量操作）。这种专注性大大降低了实现的相对难度。更重要的是，这个复杂性由 OpenAI 的顶尖专家团队承担了，普通用户（AI 研究员、工程师）享受到的则是简单性——他们不再需要手写复杂的 CUDA C++ 代码，而是用更简单的 Python 风格来完成，极大地提高了生产力。
启动速度和预热时间 (Startup Speed & Warm-up Time)
传统 JIT 的问题： 对于短时任务，JIT 的编译延迟和预热开销是致命的。
Triton 的情况： 在 GPU 计算（尤其是深度学习训练）的场景下，这个问题几乎可以忽略不计。一个模型训练动辄数小时甚至数天。一个 GPU Kernel 的编译时间可能只有几十或几百毫秒。为了换取接下来亿万次计算中 1.5 倍甚至 2 倍的性能提升，这笔“启动开销”实在是太划算了。这里的场景是“一次编译，百万次运行”，JIT 的优势发挥得淋漓尽致。
可移植性 (Portability)
传统 JIT 的问题： 需要为不同 CPU 架构编写后端，可移植性差。
Triton 的情况： Triton 的目标平台本来就是高度特化的，主要是 NVIDIA GPU，现在也在扩展到 AMD GPU 等。它不需要考虑在 MIPS 架构的路由器或者古老的 SPARC 服务器上运行。它的“可移植性”目标是在 AI 加速器这个生态内。对于它的用户来说，只要能在主流的 AI 硬件上运行就足够了，这是一个完全可以接受的权衡。
生态系统和 C 语言扩展 (Ecosystem & C Extensions)
传统 JIT 的问题： 破坏了 CPython 等语言的 C API 兼容性。
Triton 的情况： Triton 建立了一个新的、独立的生态。它不试图兼容 CPython 的 C 扩展。相反，它通过与 PyTorch、JAX 等上层框架集成，为这些框架提供了一种比 CUDA C++ 更友好、更高效的底层 Kernel 编写方式。它是在现有生态上做“加法”，而不是“修改”。
Triton 的崛起，并非否定了“不使用 JIT 的理由”，而是为这些理由提供了一个完美的“反例”。它告诉我们，当应用场景的特征（长时运行、计算密集、平台集中）与 JIT 技术的优势（运行时优化、榨取硬件性能）高度契合时，JIT 将会是无与伦比的强大工具。而对于通用语言来说，由于需要兼顾各种无法预测的应用场景，采用更保守、更通用的解释器模型依然是其合理的设计选择。
浙公网安备 33010602011771号