Relax 发布 Rust JIT 编译器 构建提速至 11 秒

这是该页面的完整纯 HTML 文本，供没有 JavaScript 的读者阅读。相同文本也出现在 README 和纯 HTML 页面中。

Relax

无需等待的 Rust。

rustc 先构建你的程序，然后你再运行它。Relax 则在构建程序的同时运行它。

Relax 是一个用 Rust 编写的 Rust 实时编译器和 JIT 运行时。它直接从源码运行 Cargo 包，整个流程中不需要 rustc、LLVM 或链接器：它在每个函数首次被调用时编译该函数，在程序运行期间优化热点函数，并将你的编辑补丁应用到正在运行的进程中。

Relax 与 cargo 和 rustc 的对比

针对 x86-64 和 AArch64 的代码生成；从全新克隆的仓库出发，它能在 Linux x86-64 和 macOS arm64 上完成构建并通过测试。Windows 未经验证。

权衡取舍

• 优化后的代码更慢。 总体而言，Relax 运行的代码比 rustc 的 --release 更慢：在 x64 上耗时是 1.12 倍，在 arm64 上是 1.24 倍（21 个工作负载的几何平均值），对比原生 CPU 构建则分别是 1.22 倍和 1.25 倍。它只在少数工作负载上更快：参见 LLVM 仍然胜出的地方。
• 内存占用更多。 编译器、它的缓存以及它发布的每个代码版本都与你程序的进程共享内存，而且 JIT 代码是只追加的。relax inspect <pid> memory 显示内存分布，code 显示增长情况。包的 target/makepad-run 中的代码缓存对于 hello 会占用 120 到 190 MB。
• relax check 目前还不比 cargo check 快。 在大型包上，冷检查比 cargo check 耗时更长、占用内存更多，而且一次编辑可能触发超出必要的重新检查。我们正在改进这一点。
• 并非每个 crate 都能运行。 libs/relax/KNOWN_GAPS.md 列出了尚未解决的缺口，每个都附有复现步骤。
• 并非每次编辑都能实时打补丁。 函数体可以。结构体布局、导入、trait 或 impl 头部、或宏的变更需要重启，Relax 提供了这一功能：relax inspect <pid> session relaunch。
• 借用检查器与程序并行运行。 运行时会在每个函数执行前对其进行类型检查，并在后台进行借用检查；relax run --check-first 则会等待借用检查完成。
• 不是发布构建。 Relax 用于编辑-运行循环。发布时请使用 cargo build --release 构建的产物。

JIT 能带来什么

relax run 会打印一行 relax-remote: pid <pid>。下面除 run 和 test 之外的每条命令都是 relax inspect <pid> <command>，即运行中的程序在运行时回答的一个问题。

relax inspect <pid> help 列出了其余命令，其中包括 asm <fn> vs=rustc（将 JIT 生成的机器码与 rustc 的机器码并排显示）、count <fn>（精确调用次数）和 counters（硬件计数器）。

试一试

从全新克隆开始，构建 relax 并通过 JIT 运行一个新包：

git clone https://github.com/makepad/relax
cargo build --release --manifest-path relax/Cargo.toml -p relax-runner --bin relax

cargo new hello
cd hello
../relax/target/release/relax run --quiet hello    # run main under the JIT
../relax/target/release/relax test hello           # run its #[test] fns
../relax/target/release/relax check hello          # type- and borrow-check only

在包的文件夹中运行 relax，并传入包名而非路径。它会从构建时所在的检出目录读取 Relax 的标准库，因此请将 relax 文件夹保留在原位。

从全新克隆实测：在 16 核 x86-64 Linux 机器上构建 relax 耗时 53 秒，在 10 核 arm64 Mac 上（cargo 限制为 4 个任务）耗时 78 秒。hello 的首次 relax run 分别耗时 0.24 秒和 0.97 秒，后续运行耗时 0.01 至 0.07 秒。Relax 会将编译结果保存在包的 target/makepad-run 中（relax clean 会将其删除），因此每个新包都从冷启动开始。

网络。 像 hello 这样没有依赖的包不需要网络。对于 crates.io 依赖，如果 ~/.cargo 的注册表中已有该包，Relax 会直接取用；否则会自行从 crates.io 下载，并对照索引中的 SHA-256 进行校验。设置 MAKEPAD_RUN_OFFLINE=1 或 cargo 的 CARGO_NET_OFFLINE 后，它绝不会下载。relax fetch <git-url>（tools/run/runner/src/fetch.rs）会将 git 仓库作为单个文件存储在 ~/.makepad-run 下。

代价：一套全新的 Rust 工具链

Relax 不是 rustc 的封装，也不是 LLVM 的插件。它用一个 Rust 库取代了这两者，以及介于其间的 Cargo 和链接器的相关部分。

Makepad 如何使用 Relax

Relax 源自 Makepad 项目。makepad run 及其工具链位于 Makepad 的代码仓库中，而非本仓库；本节介绍 Makepad 如何使用 Relax。

makepad 是 Relax 的运行器，外加一个 Makepad 宿主。使用 makepad run <package> 启动的 UI 应用会获得：

除 makepad run 之外的命令都归入 makepad inspect <app>。在 Makepad 的 agent 通道中，经过一整天的运行，一次编辑在到达机器后 3.6 秒（中位数）即被修补，而在冷 JIT 或缓存情况下，p90 为 86 秒。

为 AI agent 而构建

AI agent 感受不到构建缓慢，但每一次构建都要以 token、实际耗时和丢失的上下文为代价。Makepad 依靠众多 AI agent 并行工作来构建其应用，而其开发中枢 devhub 则在热机器上通过 Relax 让每个 agent 的应用或测试运行保持存活。

在实践中，九条 agent 通道并行运行，devhub 每小时处理 300 多个构建和测试任务，每天有数十项变更落地，每一项在合并前都要经过 Relax 的检查。

LLVM 仍然胜出的地方

Relax 的稳态代码比 LLVM 慢。同一工作负载在 Relax 下的耗时与其在 rustc 下的耗时之比（越低越好，1.00× = rustc）。

总体而言，Relax 运行的代码比 rustc 构建的代码更慢：在 21 个工作负载上的几何平均耗时是 x64 上标准 --release 的 1.12 倍、arm64 上的 1.24 倍，是原生 CPU 构建的 1.22 倍和 1.25 倍。Relax 仅在少数工作负载上更快。与标准构建相比，它在 x64 上于刚体物理（0.43×）、游戏模拟 tick（0.60×）和关卡行走（0.87×）上更快，在 arm64 上于 LLM 解码主机路径（0.87×）和关卡行走（0.91×）上更快。x64 上的两项显著优势在与原生构建对比时消失（刚体物理 1.38×，游戏模拟 tick 1.26×）：这两项优势是针对通用 CPU 基线取得的。最差的工作负载是 3D 模型构建，耗时约为 rustc 的两倍。

内核微基准测试（30 项）：在 x64 上稳态几何平均为标准构建的 1.14 倍、原生构建的 1.24 倍，在 arm64 上约为 1.23 倍。这些数据是暂定的，直到一个热缓存分层升级 bug 被修复：在热 JIT 缓存下，一些热点函数始终不会升级到 O3，因此内核数据可能显得偏慢，属于上界。上述 21 个工作负载的表格不受影响。

x64：8 核桌面 CPU，Linux；arm64：Apple M4 笔记本，macOS。rustc 1.99.1，LLVM 23.1.1。每个数字是 3 轮的中位数，测量于 2026-11-12。标准构建是面向通用 CPU 的 cargo build --release；原生构建是带 -C target-cpu=native 的 --release。Relax 以其默认模式计时，处于分层升级后的稳态。在 x64 上，标准构建和原生构建两列来自同一台机器和同一批二进制文件上的独立运行。在 arm64 上，通用 CPU 已经是 M 系列基线，因此两列仅因噪声而不同。

哪个 --release？ 两者都进行了测量：标准构建（cargo build --release，通用 CPU）和原生构建（-C target-cpu=native）。Relax 始终针对其运行的 CPU 进行编译，因此原生构建才是同类对比的列。

差距的来源，来自同一次 3D 打印切片器运行中相同函数的指令级比较：多出的指令而非停顿（1.26 倍的指令数带来 1.15 倍的周期数）。

内联并不是原因：Relax 的内联比 rustc 更多。每一行都是一个工作项。

Relax 用于开发迭代：发布构建使用 rustc。

架构

Relax 在单个进程中掌控从源码字节到可执行内存的整个流水线。它由一系列分层组成，每一层都是独立的 crate，只构建在下方各层之上；各层并行编译，上层的变化永远不会重新构建下方各层。

函数的生命周期。 在 main 之前，程序自身的 crate 会进行类型检查。函数的首次调用会编译它（解释器或 O1）；当它变热时，会在后台以 O3 重新编译并替换。当你保存对它的修改时，Relax 会重新检查变更内容，重新编译并发布新代码；旧代码仍然有效，下一次调用会运行新函数。

设计规则。 永不陈旧： 每个缓存结果都以其输入的哈希为键。代码只增不减： 已发布的机器码在仍可能位于栈上时绝不会被释放或重写，因此交换是安全的，而原生热重载 hack 则不然。默认惰性： Relax 只编译你调用的内容，而非你可能调用的所有内容。可检查： 每个阶段都会报告它正在做什么，因此停滞可以从其记录中得到解释。

仓库布局

Cargo.toml                              the workspace
libs/relax/
  lex/ base/ session/ front/ types/     front end and type system
  codegen/ backend/                     middle end and machine code
  compiler/                             runtime, std (compiler/std), 96 end-to-end test packages
  attr/ native_macros/                  #[relax(..)] and native proc macros
  KNOWN_GAPS.md                         what isn't supported yet
libs/relax_api/                         #[relax_api] and per-thread heap routing
tools/run/runner/                       relax, the command-line runner
libs/ platform/ tools/ widgets/         the small support crates Relax links: token model,
                                        serialisation, remote inspection, profiling, and the
                                        native proc macros it checks against their source

编译器是 relax_compiler 库（cargo build --release -p relax-compiler）；relax（tools/run/runner）是它的命令行运行器。构建它需要稳定的 Rust 工具链，且无需来自 crates.io 的任何内容。

许可证

MIT，参见 LICENSE。Relax 编译的 std 源码带有各自的声明；参见 libs/relax/compiler/std/CREDITS.md 及其旁边的许可证文件。