四级逃生舱：从 2310 毫秒到 19 毫秒

# 四级逃生舱：从 2310 毫秒到 19 毫秒

Fun 的解释器不快。纯解释跑那个曼德博分形基准，四次实测 2291 / 2348 / 2297 / 2305 毫秒，均值约 **2310 毫秒**，大致落在同一台机器上的 Perl 与 Python 之间。这是 tree-walking 解释器加 variant 动态类型应付的代价，不必辩解。

但工程上真正要紧的不是解释器多快，而是**热点能不能下沉**。Fun 给了四级通道，而且都能在 Linux 上跑通。一份独立评估在一台 Debian 13 (x86_64) 上从源码构建解释器、逐项复现，结论是 4/4 可用；同一个分形，内联汇编路径实测 **19.0 毫秒** —— 约 **120 倍**。

## 先看数字

| 项 | 结果 |
| --- | --- |
| 单文件全功能构建 | 702 KB(Regex + TCC + FFI 全启用) |
| 四级逃生舱 | 4 / 4 实证可用 |
| 内联汇编峰值加速 | 约 120×(19.0 ms 对 2310 ms) |
| 官方 test-speed | 55 / 55 全通过 |

## 四级，逐级下沉

### L1 FFI：调现成 C 库

最外面一级是 FFI。`getapi` 按类型签名拿到一个 C 导出函数，直接调：

```fun
var getpid = 'libc.so.6'.getapi('getpid', ':i');
?. getpid();

var strlen = 'libc.so.6'.getapi('strlen', 's:i');
?. strlen('hello world');   // 11
```

签名串就是参数与返回类型(`:i` 无参返回 int，`s:i` 收字符串返回 int)，不必写绑定，也不必起构建。

这一级在评估里先是全军覆没：任何签名下 `ffi_prep_cif` 一律返回 `FFI_BAD_ABI`。根因很有意思 —— FPC 3.2.2 自带的 ffi 单元把 `FFI_DEFAULT_ABI` 写死成老版 libffi 的枚举值 1(UNIX64)，而 libffi 3.4 在枚举里插入了 `FFI_SYSV`，把 UNIX64 挤到 2；传出去的 1 恰好就是 `FFI_BAD_ABI`。作者环境用的 libffi 3.0.13 是老枚举，才恰好兼容。修法是运行时探测(`cifABI()` 先试 2 再试 1，结果缓存)，同时兼容新老 libffi；该补丁已被原样采纳进主线。

### L2 运行时编 C：热点函数留在脚本里

第二级用内嵌的 TCC 在运行时编 C。`libtcc.so` 以 `rpath $ORIGIN` 随主程序分发，脚本里直接写 C、编译、调用，不需要系统编译器，也不需要预编译步骤。官方 `fractal-benchmark-c.fun` 实测 **20 毫秒**，并且覆盖了闭包回调路径。

意义在于成本：传统上「热点用 C 重写」要走装编译器、写绑定、管构建三步；这里压缩成脚本里写一个 C 函数。

### L3 内联汇编:19 毫秒

第三级是直接在可执行内存页上写机器码：`mmap` 出 RWX 页，按 SysV AMD64 约定传参，还能做 64 位双向回调。

这里踩到一个有意思的坑：官方汇编示例里的机器码是**32 位 Win32 材料**(以 `5589E5` 开头的 `push ebp; mov ebp,esp`)，在 x86_64 上跑是未定义行为。评估方用 `gen-mandel.py` 生成了一份 x86_64 SysV + SSE2 的曼德博机器码(先经 objdump 反汇编预验证，再灌进 Fun)，渲染结果正确，实测 **19.0 毫秒**。

### L4 JIT：让 C 回调 Fun

最内一级是双向回调：Fun 把闭包经 64 位回调交给 C 或汇编侧调用。C 路径下，从 C 回调 Fun 对 1 到 10^8 求和返回 5.00000005×10^15,64 位整型跨边界精确还原。

四个方向 —— Fun 调 C、C 调 Fun、Fun 写汇编、汇编回调 Fun —— 到此闭环。

## 解释器本身：不吹不黑

把两层放在一起才自洽。同一台机器上，官方 `test-speed` 的 55 项里：

| 基准项 | Fun 实测 | 备注 |
| --- | --- | --- |
| 空白循环 | 892 ms | 比 CPython 约快 3.4×(1 亿次，无迭代器协议开销) |
| 算术运算 | 102-174 ms | 约为 CPython 抗折叠对照的 1.0-2.1×，variant 装箱是主因 |
| 函数调用 | 52-130 ms | 随参数量变化 |
| 对象操作 | 234-254 ms | 含属性读写与方法派发 |

空循环赢，算术输，分形落在 Python 与 Perl 之间 —— 都由结构决定，不必惊讶。

## 这套模型意味着什么

Fun 的性能叙事是**两段式**：解释层给平缓的学习曲线和脚本灵活度，逃生舱层给原生性能出口。选择它的前提不是「解释器快」，而是接受「热点下沉」这个编程模型 —— 四级路径的实测都落在 19-20 毫秒，说明下沉是常规操作，不是特技。

## 一句话总结

解释慢不构成否决理由，只要**能下去**。Fun 把从 JSON 一直下到机器码这条路修通了，四个逃生舱的实测数据(19 毫秒、约 120 倍、55 项全过)就是这条路的通行证。