Makepad 发布 Rust JIT 编译器 Relax，边运行边编译以减少构建等待

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

无需等待的 Rust。

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

Relax 是一个用 Rust 编写的实时编译器与 JIT 运行时，专为 Rust 打造。它直接从源码运行 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/relax 中的代码缓存在 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 的 std，因此请将 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/relax 中（relax clean 会将其删除），因此每个新包都从冷启动开始。

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

代价：一套新的 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 倍。这些数据是暂定的，直到热缓存 tier-up 缺陷修复为止：在热 JIT 缓存下，一些热点函数永远不会 tier up 到 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 以其默认模式计时，处于 tier-up 后的稳态。在 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 会重新检查变更内容，重新编译并发布新代码；旧代码仍然有效，下一次调用会运行新函数。

设计规则。 永不陈旧： 每个缓存结果都以其输入的哈希为键。代码只增不减： 已发布的机器码只要还可能位于栈上，就绝不会被释放或重写，因此这里的替换是安全的，而原生热重载的取巧做法则不然。默认惰性： 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 及其旁边的许可证文件。

一个用 Rust 编写的、面向 Rust 的实时编译器和 JIT 运行时

Rust 无需 等待。

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

Relax 直接从源码运行 Cargo 包，全程无需 rustc、LLVM 或链接器。它在函数首次被调用时编译它，在程序运行时优化热点函数，并将你的编辑补丁进正在运行的进程。

记分板

Relax 对比 rustc

Relax

rustc + Cargo

权衡取舍

JIT 让你付出什么。

收益

JIT 给你什么。

保存即构建

运行中的程序

自启动以来的帧数

补丁

重启

试一试

构建它，运行一个包。

它经历了什么

一条新的 Rust 工具链，从源码字节到机器码。

这项工作 · 在常规工具链中 · 在 Relax 中

Makepad 如何使用 Relax

makepad run 中的 Relax

为 AI 智能体而构建

持续保持热度的循环

Makepad

实践之中

速度

Relax 与 rustc，在真实工作负载上。

展示数字

诚实的数字

LLVM 仍然胜出之处。

分层与实时补丁

一个函数的一生。