2-runtime/prime_sieve bench：解释执行每操作 KV 往返 → 计算密集慢 Python ~138,500×（关联 #116 寻址开销）

[miaobyte]

结论先行

同一份试除法（trial division，嵌套 while，求 ≤200 的质数）在三种实现上的耗时：

实现	用时	相对 Rust
Rust (rustc -O)	24.2 µs	1×
Python 3	240.8 µs	~9.9×
kvlang（shm 后端）	33.37 s	~1,378,000×

kvlang 比 Python 慢约 138,500×，比 Rust 慢约 138 万×。这不是 bug，是当前解释执行模型的架构本质，记录在此以便量化性能定位、并与 #116 的寻址开销一并跟踪。

度量方法

• kvlang 版：tutorial/06-algo/prime_sieve.kv，用其内置 time·now/time·sub/duration·as_nanos 计时 prime_sieve(200) 计算+打印段（不含 stdlib boot）。后端 KVSPACE=shm://…（比 redis 快，redis 版更慢）。二进制取 /usr/bin/kvlang（当前安装态）。
• Python：time.perf_counter_ns() 包 prime_sieve(200)。
• Rust：std::time::Instant，rustc -O。
• 三版逻辑逐行等价（while + % + == + break + 计数），都包含循环内 print（与 kv 计时区间一致）。脚本：/tmp/psbench/{ps.py,ps.rs}。

原始数据（ns）：kvlang 33368371941；Python 240817；Rust 24213。

根因

kvlang 是把 PC 和全部状态都存在 KV 树里的明文解释执行 VM：每一个 %、==、+、while 判定、-> 写槽都是一次 kvspace 读/写 + rwir 派发往返。prime_sieve(200) 试除法 O(n²) ≈ 上万次内层迭代，每次迭代数次 KV 往返，累积几万次操作 × 每次数百 µs 往返 ≈ 33 s。shm 单进程内存 KV 已远快于 redis，但每操作往返开销仍数量级高于寄存器/栈机。

与 #116 的关系

#116 分析的正是这条链路的另一维成本：随调用深度 D，PC/帧 key 长度 O(D)、活跃 key 总量 O(D²)。prime_sieve 的慢与 #116 同源——都出自「PC/帧/局部全部落 KV 树、每步往返」的 runtime 设计。#116 优化 key 形态（三维地址 [ctlflow,irseq,params]）可减小单次往返的 key 体积，但不改变每操作一次往返的数量级；本 issue 记录的是往返次数×单次延迟这一正交维度。

定位取舍（非待修 bug）

这是 kvlang 定位的自觉取舍：代码即数据、PC 可崩溃恢复、软链接即调用——用极致可观测/可恢复性换执行速度。计算密集部分本应下沉扩展世界（tensor → op-gpu/numpy 扩展一次性算），kvlang 只做编排、不做热循环。

可选后续方向（待讨论，不在本 issue 承诺）

• 帧局部/纯值临时变量的进程内缓存：热循环内的 d/rem/is_prime 等纯局部标量不必每次穿透 kvspace，可在 vthread 执行器内存内维护、仅在 yield/崩溃点回写（与崩溃恢复语义需对齐）。
• 基础算子批处理：连续纯 native rwir（算术/比较）已在 runtime-rs 侧批处理，评估把 in-proc 批的粒度扩到整个内层 while。
• 明确文档化 kvlang「不做热循环」的定位，tutorial 层给出「计算下沉扩展」的对照例。

[miaobyte]

三维地址版本复测（#116 已并入 feat/flat-goto）

在 #116 的 flat [d] 调用帧 + 三维地址 [irseq,params] 落地后（commit 19d00bf，/usr/bin/kvlang，KVSPACE=shm://…，同一 tutorial/06-algo/prime_sieve.kv 的 prime_sieve(200) 计算+打印段），重跑本 issue 的三语言对照。

结果

实现	用时（本次）	相对 Rust
Rust (rustc -O)	22.6 µs	1×
Python 3	241.6 µs	~10.7×
kvlang（shm，三维地址）	27.32 s	~1,210,000×

• kvlang 比 Python 慢约 113,000×，比 Rust 慢约 121 万×。
• kvlang 三次：27346547413 / 27335071662 / 27282368206 ns（均值 27.321 s，抖动 <0.3%）。Python 241208/241934 ns，Rust 22934/22193 ns，与本 issue 原基线（Python 240.8 µs、Rust 24.2 µs）一致。

与原始记录（33.37 s）对比

版本	用时	vs Python
记录时 /usr/bin/kvlang（#116 前）	33.37 s	~138,500×
#116 三维地址	27.32 s	~113,000×

同一后端、同一算法、同一二进制路径下，三维地址把 prime_sieve(200) 从 33.37 s 降到 27.32 s，提速约 18%（1.22×）。

结论

数据印证本 issue 的判断：三维地址 [irseq,params] 减小了单次往返的 key 体积，带来约 18% 的常数因子改善，但未改变「每操作一次 KV 往返」的数量级——相对 Python 仍是 ~10⁵ 量级（138,500× → 113,000×）。往返次数×单次延迟这一正交维度不受 key 形态影响，仍需靠「热循环下沉扩展世界、kvlang 只做编排」的定位取舍来消除，而非继续压 key 体积。