# WAsmC 0.0.21：tpc08 功能与性能评估

日期：2026-10-09。仓库：cbgroom/wasmcrelease。
固定提交：`c888af39c11640644591ff42aeaf8b09f632f651`。
所有性能数值来自通过 awmcp 在 tpc08 执行的测量，而非模型运行容器或历史 CI。

## 结论

WAsmC 已经形成可运行的 Core Wasm 编译、托管库、库发现与原生执行体系。最清楚的优势是常驻小程序编译延迟低、有效标量程序输出紧凑，以及库制品身份与分发元数据较完整。

这不等于全部功能已经成熟。三个自编计算内核在 V8 中与优化 JavaScript 基本持平；独立 AOT 程序与同批 C 进程对照接近，但默认 Wasmi CLI 执行这些长循环明显较慢。JSON 等库也没有呈现普遍超过宿主内置实现的性能优势。

本次独立验证发现两个重要问题：Core 编译接口及 Native build 会对某些类型错误程序报告成功，实际生成无效 Wasm；Std Base64 在特定字节缓冲输入上发生 `unreachable` trap。后者尚未定位根因，不能误写成已经查明的大小上限或 UTF-8 问题。

## 1. 环境与测量边界

| 项目 | 本次对象 |
|---|---|
| 处理器 | Intel Core i7-13700，24 个逻辑 CPU |
| 系统 | Linux x86_64，6.18.33.2-microsoft-standard-WSL2 |
| 主测引擎 | Node 24.21.0 / V8 13.6.233.17-node.53 |
| 旧引擎对照 | 系统 Node 18.19.1 |
| C 对照 | Clang 18.1.3，`-O3 -ffp-contract=off -std=c11` |
| 编译器制品 | 1,510,219 字节；零 Host imports |
| 编译器 SHA-256 | `42c27913120d4ecf8a05ed990287767296aba9ae3b5af0a4e7ede182d5ad998c` |

未固定 CPU 亲和性或频率，未取得独占机器，未清空操作系统页缓存。因此这是该主机上的可复核观察，不是硬实时 SLA、跨平台验收或数学意义上的性能极限。热编译使用 Node/V8 内的常驻编译器，未单独测量 Rust Resident Compiler SDK 的纯热吞吐。

## 2. 功能与覆盖程度

本次选择执行了 40 个仓库测试/示例命令，其中 24 个返回成功，另外 16 个受维护者精确 refresh-receipt 前置条件或缺失 wasm-tools 等开发工具限制，未完成其预定测试。这不能解释为“产品失败率 40%”。之后对当前发布 Root 另写直接验证程序，不伪造 refresh receipt，也不将这些独立验证冒充原维护者脚本通过。

| 领域 | 观察 |
|---|---|
| 编译器回归 | 一组 35 个固定输出、7 个执行 oracle、25 个 CLI 输出通过；另一组 30 个固定输出、23 个表达式案例通过 |
| 普通托管源程序 | 768 次集合调用、1,536 次布尔条件调用、6 个数值/布尔负向用例通过；另有 192 次托管重复调用 |
| Std 1.4.1 | 三类消费者合计 7,680 次调用通过；73 是 API 清单数，不是 73 个操作完整语义覆盖的证明 |
| u64 | 独立 304 项对照通过，覆盖 2^53 以上、2^63、2^64−1，以及加法、比较、无符号右移、除法和余数 |
| 库目录与搜索 | 42 个 Root、236 条 API 路由、278 个索引条目闭包验证通过 |
| 安装 | 摘要、锁定、no-clobber、并发目的地保护等测试通过；这不等于验证所有网络安装环境 |
| JSON | 25 项独立验证通过，含语法、压缩输出语义、JSON Pointer 及边界 |
| gzip | 13 项独立验证通过，含与 Node zlib 互解、非法流和输入/输出上限 |
| 动态运行机制 | 本地替换、回滚、快照/状态迁移等测试通过；不外推为跨节点 exactly-once 或生产级网关保证 |

不同脚本的计数存在覆盖交叠，不能累加成独立测试总量或覆盖率。

对 42 个当前 Root 的制品逐项清点，得到 22 个 Core Wasm 制品、6 个其他原生适配器制品、14 个仅源码条目。22 个 Core 制品摘要匹配且通过当前 V8 的 Wasm 验证。其他适配器没有在本次逐项执行；14 个源码条目不能当成已验证的 Android/iOS 设备能力。HTTP、TLS 和多个 Data 库的制品可验证，也不能因此宣称其全部 API 已执行。

## 3. 编译性能

### 常驻热编译与进程级 CLI 成本

单位为毫秒。常驻编译器每档预热 10 次，随后采样 31 批；小语料每批 50 次，中档每批 10 次，大档每批 1 次。P50/P95 是批次内折算到每次编译的统计，不是严格的单请求尾延迟。

| 语料 | 源码 B | 输出 Wasm B | 热编译 P50 | 热编译 P95 | Native CLI build P50 |
|---|---:|---:|---:|---:|---:|
| small_scalar | 126 | 44 | 0.0153 | 0.0344 | 7.097 |
| structured_variant | 697 | 208 | 0.0640 | 0.0881 | 8.514 |
| policy_small | 2,562 | 733 | 0.1384 | 0.2277 | 9.337 |
| policy_large | 30,995 | 9,454 | 1.5971 | 2.5952 | 13.681 |
| std_mix_large | 112,300 | 31,242 | 5.1410 | 6.1624 | 20.691 |

五档输出均与发布基准的字节摘要匹配。除最小标量程序外，其他四档分别含 1、7、14、36 个 imports；这些输出大小不是完整库依赖打包后的大小，它们也不是四个无依赖可直接运行的程序。

最小程序热编译中位数约 15.3 微秒，最佳批次均值约 8.9 微秒。这是观察，不是已经证明的极限。另有 101 个修改常量的源码分别编译和执行校验，避免只验证完全相同的输入。

### 新 Node 进程

11 个新进程运行同一最小编译测试。操作系统缓存未清空：

| 阶段 | P50 ms |
|---|---:|
| 导入自包含 ESM facade | 15.130 |
| 创建编译器实例 | 2.155 |
| 首次源程序编译 | 6.339 |
| 编译输出 Wasm Module | 0.0737 |
| 实例化输出 Module | 0.0215 |
| 整个测试进程 | 58.450 |

各阶段中位数不能相加后冒充测得的总中位数；整个进程还包含 Node 和测试程序启动、文件读取等。不能将 58 ms 冷测试进程开销当作 15 微秒热编译，也不能反过来用热编译数字承诺全新进程启动延迟。

### Native AOT 与缓存

官方流程实测的小标量 AOT 构建：cache miss P50 28.200 ms，cache hit 65.529 ms。另用 15 次命中、15 次未命中交替复测，命中为 43.640 ms，未命中为 35.945 ms，命中没有显示端到端收益。波动明显，根因未隔离。

112,300 B 语料的官方流程则测到 AOT miss 130.482 ms、hit 52.350 ms。结论应限定为：缓存收益依赖工作负载，不能将“命中”事件等同于“所有程序更快”。

最小独立 AOT 可执行文件约 12.39 MB，最小 Core 程序 44 B。两者封装层级不同：前者带原生执行基础设施，不是后者的直接等价体积对照。

## 4. 运行性能

三种独立编写的算法均为零 imports，分别以 100 组小输入对照验证，再执行 2,000 万次迭代。JS/Wasm 顺序交替、种子变化，每组 11 次。C/AOT 在后续单独阶段测量，不将跨阶段的几个百分点解释成稳定优势。

### 同一 V8 内的计算主体，P50 ms

| 内核 | WAsmC→Core Wasm | JavaScript | 观察 |
|---|---:|---:|---|
| xorshift32 | 24.415 | 24.549 | 基本持平 |
| 分支与 u32 混合运算 | 17.526 | 17.897 | 约 2% 差异，不足以泛化 |
| f64 递推 | 29.873 | 29.945 | 基本持平 |

### 独立进程对照，P50 ms

| 内核 | Clang C 进程 | WAsmC AOT 进程 | 默认 Wasmi CLI |
|---|---:|---:|---:|
| xorshift32 | 29.368 | 29.896 | 131.513 |
| 分支与 u32 混合运算 | 20.667 | 20.722 | 141.041 |
| f64 递推 | 31.345 | 31.926 | 59.807 |

C/AOT 均包含进程启动；Wasmi CLI 还包含源程序编译。其样本数为 5，其余为 11。标量长循环的 AOT 路径与本机 C 对照接近，默认 Wasmi 路径约为 AOT 的 1.9–6.8 倍耗时。不能据此外推 SIMD、内存密集工作负载、线程、网络或端到端服务。

最小标量程序的单次进程运行，默认 Wasmi CLI P50 7.955 ms，独立 AOT P50 1.971 ms。官方 Native CLI 使用 Wasmi 2.0.0，显式 AOT 使用 Wasmtime 49.0.2；两条路径不能混称同一种运行性能。

## 5. 库性能与跨边界成本

| 操作与输入 | Wasm 路径 P50 ms | 宿主基线 P50 ms |
|---|---:|---:|
| JSON compact，695 B | 0.0161 | 0.00528 |
| JSON compact，11,727 B | 0.2133 | 0.07877 |
| JSON compact，37,114 B | 0.7597 | 0.31999 |
| gzip，4,096 B | 0.02818 | 0.02823 |
| gzip，65,536 B | 0.23045 | 0.19850 |

JSON 宿主基线为 `JSON.stringify(JSON.parse(text))`，数据键顺序一致；Wasm 包含输入 UTF-8 拷贝、处理、输出解码与清理，但不含最初 TextEncoder。它是在测一个具体 JSON 文本处理集成，不是所有 JSON 操作的优劣。

gzip 对照为 Node zlib 默认选项。64 KiB 输入，Wasm 输出 1,197 B、Node 输出 1,344 B；4 KiB 输入则为 389 B、382 B。压缩结果大小不同，不能把耗时差直接当作完全相同压缩级别的引擎效率差。

64 B Base64：驻留输入、输出分配及清理为 1.88 微秒；按示例逐字节 Host/资源调用搬入搬出为 9.78 微秒；Node Buffer 为 0.24 微秒。后者逐字节路径含检查和 BigInt 处理，不是最优批量 ABI 的上限。更大的该类测试未得到可靠吞吐结果，因为触发了下面的库失败。

这些库中部分由 Rust 构建，库性能不等于 WAsmC 编译器生成代码的性能。三个自编标量内核才是独立代码生成/执行观察。

## 6. 独立发现的失败

### F1：成功状态不保证输出是合法 Wasm

```wasmc
package independent:bool_f64;
interface api {
  run: func() -> bool { return 1.5; }
}
world app { export api; }
```

本次 `compileDetailed` 返回 `ok: true, status: 0`，输出 43 B；`WebAssembly.validate` 为 false，实例化报 `expected i32, got f64`。Native CLI `build` 同样返回 0，输出也无效。将返回类型改为 s32 亦复现。

带真实托管 List 根的 `instantiateLib` 对应程序能正确拒绝这些浮点/目标类型不匹配；这显示两条路径的类型验证行为不一致，而不是全部路径都没有检查。

Raw Core 对声明 bool 却返回 2 或 −1 的源程序也接受并原样返回，托管路径拒绝。这里只陈述实际语义差异，不将其误写为沙箱逃逸。无效字节仍被 Wasm 引擎拦截。

### F2：Std Base64 对特定合法字节缓冲输入发生 trap

Provider 4.9.0、Std 1.4.1，使用与公开 Base64 示例相同的 Core 调用模式。每个长度都重新实例化 Provider/Std，输入第 i 个字节为 `i & 255`，逐字节 push 都成功。

64 B 输入完成并与 Node Base64 输出一致；256、512、1,024、2,048、3,072、4,096、8,192、65,536 B 输入均在 `std_base64_try_encode_standard` 阶段报 `RuntimeError: unreachable`。

最小失败观察是由 0..255 全部字节组成的 256 B 输入。不能仅因长度增长就声称查明了大小上限：这些测试的内容也在变化。未定位具体实现根因，未验证其他 SDK/Component 路径是否复现。

小输入反复运行表现不同：10,000 次三字节编码、20,000 次显式 drop，Provider 线性内存一直为 3,670,016 B。因此不能用“小输入一万次通过”替代输入域正确性验证。

## 7. 内存、兼容性与成熟度

连续 10,000 次最小源码编译，编译器线性内存保持 1,310,720 B。Provider 的小输入压力测试保持约 3.5 MiB。两者只是线性内存观察，不是总 RSS、JavaScript 堆、JIT 内存或长期无泄漏证明。

系统 Node 18.19.1 对当前 Std 明确报 `engine.feature_unsupported`，缺 function-references 与 tail-call；Node 24.21.0 通过。应将其认定为该制品的引擎特性要求，而不是把所有 Core Wasm 都描述成需要这些特性。

WAsmC 的合理评估对象是 WIT-shaped 声明、有限表达式、Core 输出、Lib 与显式 Host 能力的组合，不是完整 Rust/Cargo 替代品。固定宽度数值、控制流、结构化 Core lanes、托管集合各有对应入口。普通源程序的 char、一般 async 与直接公开 Map 结果不属于 README 承诺的当前普通路径；内部诊断提及某个有限 async 子集，也不等于完整 async 已经公开验收。

Agent 入门的正面证据是五个教学例程、搜索与锁定、当前入口和结构化诊断。不能据此量化首次成功率或学习时间。文档仍有小漂移：LANGUAGE.md 开头要求使用 current，而一个 JS 入门示例仍导入 dist。纯 Core、托管源程序与 Host SDK 的 API/所有权差异也需要认真区分。

编译器实现源码不公开，本次无法进行实现级审计或独立重建。公开摘要链能证明制品身份，却不能单独证明行为正确。项目声明仅非商业研究许可，商业及生产使用需另行书面许可；发布阶段命名不改变授权边界。

## 最终判断

它已是有实测支撑的 Core-first 编译与库运行体系：热编译延迟低，标量代码在合适引擎上执行有效率，制品身份管理有实际内容。

尚不能称为所有库及错误路径均成熟的通用运行底座。当前最关键的限制不是“默认不输出 Component”，而是具体的类型验证缺口、特定库输入失败、宿主边界成本、运行引擎差异，以及仍未完成的全 API/设备/长期服务验证。

### 原始文档归属

文档事实来自固定提交的 README.md、LANGUAGE.md、LIB.md，以及当前 Root 元数据和 Native 发行包说明；完整远程工作区、报告名和复现命令见 README.md。数值汇总见 measurements.json。