SystemSimulationApp/tests/manual/fallback_profitability_report.md

Context fallback：盈利条件与下一步决策

日期：2026-09-17。范围：既有八路模型 0–10 s、896 个 Jacobian 的历史诊断数据。本轮只做数据归并和预算分析，没有构建新 worker、修改求解器、扩展 semantic replay 或重跑性能实验。

结论

停止按单个 operation 推进 semantic replay。下一次只值得先测 position379 / PNVO001_1 中 state_valve 数值尾部的 kernel memo。 原 context 查询、物性写入、valid 演变和 native 调用仍照常发生；这与跳过整个 operation 是不同实验。

• 当前 343 个 fallback operation 的跨组单次均值最高只有 1.315 µs；即使拆到 5,157 个 (group, position) 组合，最高均值也只有 1.642 µs。没有一个能承担当前 7.109 µs 的单 operation replay 开销，尚未计 baseline。
• 较贵 interval 是多个廉价 operation 的集合。不能把整个 interval 的预算发给其中每个 operation。
• whole-context guard 成功的 20,608 次继续使用原机制；失败的 139,776 次不能直接恢复 baseline 全 context，其真实出口均与 baseline context 不同。
• 不继续优化 R288，不启动 position52、R475 或其他区间的 semantic replay 实现。R490 等长区间只保留为预算上的备选，尚不具备立即实验的收益与语义证据。

1. 数据覆盖与计时口径

数据层	覆盖 / 结果	本报告用途
全量 census	115 个失败 interval；156 个 group/interval；343 个 position；5,157 个 group/position	次数、归属和摊销上限
fallback 原计算	139,776 次 interval；4,620,672 次 operation 执行	去重后的成本分母
分层 profiling，扣空标记估计	全轨迹 context fallback 613.201 ms	总量交叉检查
interval 独立计时	682.630 ms	原区间预算；含区间调度及诊断 hook，不含失败前的 guard
operation 独立计时	660.431 ms	分离 native 语句与纯代数/alias；operation 预算
function 独立计时	exclusive 合计 879.118 ms	函数排序，不能加到以上时间或视为净收益

interval、operation、function 各三轮；每轮分层抽取 112/896 个 Jacobian，按频率折算全轨迹后取三轮算术平均。这里的“µs/次”是累计折算时间除以全量次数，不是单次延迟分位数。完整表另外保留三轮值和 min/max。

这些是带插桩的预算估计。极短 operation 的计时可能明显高估；函数 exclusive 仅扣除已插桩子调用。不同模式的差值不能直接当作 dispatch 成本，更不能叠加。R288 最新实验的机器负载与旧 profiling 不同，跨批代入只用于成本量级情景，不能预测加速。

可查验的完整交付物

• 115 个 interval、156 个 group/interval 的全部成本和预算，以及 196 个纯代数连续段。按 次数 × 单次成本 排序，含 operation/native 数量、纯代数时间、主要函数、共享上限。
• 343 个 operation 的全部热点和预算。含 interval、group、原始 operation ID、原生调用、次数、时间、摊销边界与建议。
• 完整 JSON：另含全部 5,157 条 group/position 映射、原代码、逐区间函数数据、三轮折算原始数值、输入 SHA-256、预算情景和检查结果。
• 复现脚本：只读取历史产物。运行 .venv-win/Scripts/python.exe -B tests/manual/analyze_fallback_profitability.py。

原始依据：fallback 诊断、原始统计、代码及依赖计划、分层 profiling、R288 typed 实验。当前工作区其他改动未作为这份历史测量的重新验收对象。

2. 热点：大区间与廉价 operation 必须分开

累计成本最高的区间及重要对照

“纯代数 ms”来自 operation 模式，只计完全不含 native 调用的语句；不包含 native 内部的代数部分，后者尚无独立测量。

interval / 范围	group	次数	原区间累计 ms	原区间 µs/次	ops / native ops	纯代数 ms
R490 [49,184)	24,25	1,792	33.807	18.865	135 / 15	4.139
R485 [50,181)	22,23	1,792	31.667	17.671	131 / 14	4.072
R480 [51,178)	20,21	1,792	30.269	16.891	127 / 13	3.954
R475 [52,175)	18,19	1,792	27.257	15.211	123 / 12	3.841
R470 [53,172)	16,17	1,792	25.381	14.164	119 / 11	见完整表
R465 [54,169)	14,15	1,792	22.936	12.799	115 / 10	见完整表
R460 [55,166)	12,13	1,792	22.117	12.342	111 / 9	见完整表
R3 [30,48)	0	896	21.393	23.876	18 / 17	0.033
R455 [56,161)	10,11	1,792	20.735	11.571	105 / 8	见完整表
R457 [297,444)	10,11	1,792	15.880	8.862	147 / 4	5.653
R49 [373,444)	0	896	15.782	17.614	71 / 4	1.814
R288 [16,17)	6	896	0.918	1.024	1 / 1	0

R490–R455 前半区域主要是 native_pipe_flow_cached_context，包含 PH context 获取和 state_valve 等链路；R457/R49 的四个 native 是 native_medium_orifice_context。R3 的 17 个 native 集中在管路/节流流量，因而短区间也可能更贵。

R49 暂不作首选：区间模式是 17.614 µs/次，operation 模式总和却只有 7.283 µs/次。三轮区间值都偏高，说明不是简单挑掉一轮就能解决；尚未分离具体原因。不能把两者差额承诺为可消除的调度成本。R3 也存在 23.876 vs 20.471 µs 的模式差异，预算应同时参考两种口径。

group 0–9 合计 361.823 ms，group 10–25 合计 320.807 ms，group26 为 0。大区间并未占据全部 fallback。

累计最贵的几个 operation

position / 原ID	operation	失败执行次数	原计算累计 ms	µs/次	每 Jacobian 结构复用上限
379 / 24	PNVO001_1.port_2	19,712	25.926	1.315	22
405 / 28	PNVO001_3.port_2	19,712	24.907	1.264	22
392 / 26	PNVO001_2.port_2	19,712	24.721	1.254	22
80 / 88	PNL00R_4.port_1	19,712	24.410	1.238	22
82 / 90	PNL00R_5.port_1	19,712	23.721	1.203	22
418 / 30	PNVO001_4.port_2	19,712	23.021	1.168	22

重复 22 次让 baseline 有更好的摊销机会，不能让每次 1.315 µs 的计算承担 7 µs 的 probe 成本。同一 position 的 baseline 可以在结构上被这些组引用，但查询分支、消费字段、kernel 参数是否相同，仍须单独验证。现有“显式 operation 输入/输出相同”不是这种证明。

3. Break-even：必须给 baseline 与 probe 共用一个预算

令 C 为每次可省的原计算，P 为 validation + patch + commit + 新增调度等 probe 开销，H 为每个 Jacobian 新增 baseline 捕获成本，m 为这份记录可成功服务的 probe 数。单位均为 µs：

net_per_J = m × (C − P) − H
P < C − H/m
H < m × (C − P)

不能同时把 C 分别全部分配给 H 和 P。表中 H 上限以 P=0 或指定值计算；只有严格低于上限才盈利。暂用全部成功、无新增失败成本的乐观条件。

若仅有 k 次成功、其余尝试付出失败 guard 成本 F：

net_per_J = k × (C_success − P_success) − H − (attempts − k) × F

同一区间跨组最多共享一次 baseline 的结构上限通常是 1 或 2；operation 跨重叠区间可达到 22。不能把同一 group/position 在多个 interval 中重复计价，本分析按 census 的唯一归属去重。若动态 schema 无法共享，m 必须减小；如果要按组捕获 H，则不能继续除以全部组数。

用当前 R288 typed 成本作量级筛选

同批实测中位数：原 operation 1.775 µs，typed 三阶段 7.109 µs，完整路径 7.575 µs，baseline 新增 18.258 µs/J。计入 baseline 的配对净收益为 −20.415 ms/896 次；所有轮次均为负。旧批的 1.143/22.521 µs 不能和最新批混为一组对照。

以下把 H=18.258 仅作为预算情景；P 也必须覆盖新增调度/统计等成本，使用三阶段 7.109 已比完整路径更乐观。

候选	C µs	m 上限	Hmax，P=0	Hmax，P=5	Pmax，H=18.258	P≈7.109 的判断
R288，最新同批 native	1.775	1	1.775	−3.225	−16.483	即使H=0也不行；停止
position379，原 operation	1.315	22	28.935	−81.065	0.485	单operation replay不行
R490，整个区间	18.865	2	37.731	27.731	9.736	一次融合replay账面可行；未验证
R485，整个区间	17.671	2	35.342	25.342	8.542	同上
R480，整个区间	16.891	2	33.783	23.783	7.763	余量很小
R475，整个区间	15.211	2	30.421	20.421	6.082	当前量级不行；不扩展
R3，整个区间	23.876	1	23.876	18.876	5.619	需低于约5µs；op口径仅允许2.213µs
R457，整个区间	8.862	2	17.724	7.724	−0.267	baseline本身已超预算

R490 包含 15 个 native operation，若逐个使用 7.109 µs replay，单 probe 仅 replay 就要约 106.636 µs，远超整个区间 18.865 µs。表中可行性只适用于整个区间一次融合处理。不能假设 15 个 operation 的查询、字段保护与副作用能以一个 R288 的成本处理。

若要求每个长区间 P<2/5/10 µs，各自允许的 baseline 成本已在完整表逐项列出；并非只给一个统一的 7 µs 门槛。所有单 operation 的原测量均值都低于 2 µs，甚至 <2 µs 本身也不足以证明它们盈利。

4. 按真正的函数成本选择方法

以下 exclusive 时间来自函数模式，只作排名，不与 operation 模式相加。state_valve exclusive 包括未插桩的数学函数和包装等，不是已经单独测出的纯数值尾部成本。

函数 / 工作	调用数	exclusive ms	平均 exclusive µs	建议
state_valve	495,790	388.070	0.783	E：先测数值尾部；保留所有context访问
property_pt	1,225,458	114.822	0.094	F：若未来优化查找，必须保持有序first-match；不能承担µs级额外guard
local_isentropic	989,704	92.872	0.094	现有valid命中已跳过部分计算；需先分开hit与真实重算，不能整体memo掉observe/valid写入
native_jacobian_scalar_get	1,439,304	62.124	0.043	既有memo查询成本；避免再叠通用查表/完整key解释器
property_density	1,399,544	52.772	0.038	主要是cache/memo路径，保持原机制
native_pipe_flow_context	379,904	50.607	0.133	inclusive约601.523ms包含下游；不能再加到state_valve
native_temperature_ph_context	320,836	43.470	0.135	查询/包装仍发生，实际PH反算为0
native_viscosity	307,709	25.702	0.084	A；单独加memo通常预算太小，尚无盈利证据
native_medium_orifice_context	125,440	17.183	0.137	包装本身廉价，关注其state_valve数学部分
native_pipe_flow_cached_context	379,904	16.638	0.044	保留pipe语义；不要为省wrapper引入replay

native_temperature_ph、native_density、native_pipe_resistance 在这批 fallback 中实际执行次数都为 0。它们的昂贵求解已被 Jacobian memo 覆盖，不能再次把这些计算算成新优化的可省部分。

源码依据：归档 properties.c 中 state_valve 先执行 isentropic 与 property_density，之后才进行 pow/sqrt/log/tanh 等数学计算；orifice.c 的 PNVO 调用链还会获取 PH/PT、更新context并进行有限性返回检查。整个 state_valve 并不是无副作用的纯函数。

A–F 明确决策

类型	适用对象	决策
A 直接原计算	R288/position16；所有当前需要约7µs replay的单operation；廉价lookup/viscosity/alias	停止逐operation semantic replay；默认重算
B 原whole-context restore	现有guard成功的20,608次context复用	保留原guard与restore；不扩大到guard失败路径
C 切分interval	196个完全不含native的连续段；例R457 [297,379)	只考虑批量段和低成本输出恢复；不逐alias加guard
D 局部context replay	R490/R485/R480的融合区间是假设候选	仅预算保留；没有全区间读写契约，也无足够实测收益，暂不实施
E 昂贵纯数值kernel memo	首选position379中的state_valve数值尾部	下一次唯一建议实验；先测小于µs的真实成本与key复用
F 更便宜方案	property_pt有序查询、现有memo定位、静态代数段恢复	先证明确有热点且额外成本在几十至数百ns预算内；不作为本次扩展任务

B 的全部成功区间为 R0、R135、R378、R454、R459、R464、R469、R474、R479、R484、R489、R494。只沿用已经满足原 guard 的 group/interval 对，不由区间ID推导新的复用范围。

5. 候选排序：只推荐启动一个

第一名：position379 / PNVO001_1 的 state_valve 数值尾部

• 当前完整 operation 为 1.315 µs/次，19,712 次，累计 25.926 ms。三轮累计 25.631–26.268 ms。组为 0–5、10–25，共22组。完整 group→interval 映射在JSON中。
• 主要工作是 native_medium_orifice_context → medium_valve → state_valve。保留 PH/PT、等熵字段计算/valid写入、density读取及所有context副作用，只考虑在这些步骤之后复用数学尾部的 cm/velocity。
• 为什么优于 R288 replay：不是因为单次 operation 更贵，而是换成只比较少量最终数值输入的 kernel 机制，避免有序条目重放；baseline 在结构上最多可摊到22组，而 R288 的目标只有1组。候选还是累计最贵的单个 operation，且数值尾部边界可明确核对。
• 可省上界：25.926 ms 是整个 operation 零成本消失的宽松上界；数值尾部只占其中一部分，实际可省必须更小。没有该position的尾部独立计时，不能把全局0.783µs当作它的实测尾部成本，更不能承诺25.926ms收益。
• 令尾部实测每次成本为 K、memo probe成本为 G、baseline新增为 H，全部22组可命中时必须满足 G + H/22 < K < 1.315 µs。一轮净收益是 19712×(K−G)−896×H µs；命中不足时另扣miss开销。
• 初始工程目标可设 G≤0.25 µs、H≤1 µs/J，其成本门槛约 0.295 µs/命中；这是待测目标，不是已有实现速度。若尾部K≤该值或实际开销不达标，则停止。若仍沿用18.258µs的baseline新增，则仅H/22就要0.830µs，很可能再次失败。

下一次实验的边界：仍用独立 worker，只选这个 position；先采集数学尾部的实际输入位与成本，确认同一Jacobian跨组key重复比例，再实现可拒绝的最小kernel memo。候选key应依据尾部真实使用的 p/T/pd/g/rho 等值确定，不拿operation显式输入相同代替。必须核对分支、非有限值、errno/浮点状态、memo生命周期；数学库也可能有副作用，不能默认忽略。

数值尾部不再触碰property context有利于验证，但不是免验。要求所有矩阵、求解输出、context/pipe/memo、warning和计数逐位一致；成本版无shadow。测量命中/拒绝、尾部原成本、key检查、命中返回和baseline新增成本，只有完整机制净收益为正才考虑其他position。本轮没有实施这个实验。

第二名（备选，不立即启动）：R457 的纯代数连续段

R457/group10,11 整体 8.862µs、15.880ms；主要native仍是4个节流口。真正切分对象为 [297,379) 的82个纯代数operation，平均段成本 1.846µs，1,792次合计 3.308ms。这里不省任何native物理计算，保留全部context操作，可验证性较高。

选择C而非D：每段额外guard/restore加baseline摊销必须 <1.846µs，实际应显著低于1µs以留下余量。由于82个短语句分别计时，3.308ms可能含明显marker成本，先用段级低扰动测量核实；不能把该数字当作可兑现收益。全部代数段都低于2µs，逐条加机制会失败。它比R288 replay更简单，但单点总上界较小，排在kernel之后。

第三名（预算备选，暂不做）：R490 的融合局部context机制

R490/group24,25 整体 18.865µs，1,792次 33.807ms；其中15个native语句，主要是pipe flow、state_valve及查询。两个组可结构共享一次baseline，预算明显比R288宽。

若H仍为18.258µs，全部验证、所有patch和commit合计必须低于9.736µs/整个interval；要有可靠余量，目标至少应低于5µs。若P=7.109、100%成功且两组共享记录，账面仅剩约 4.708ms，尚未扣完整路径额外开销。未知读写覆盖、15个native的effects以及guard扩张很容易用完预算，因此不建议现在开始完整semantic实现。

相比之下，先把state_valve里的数学部分分离，能检验是否存在更低成本方法，再决定是否需要复杂的融合局部context。R485/R480也是同类预算备选，不扩展实现。

6. 还剩多少空间：条件上界，不是加速承诺

以完整interval只付一次开销的乐观情景

每行只统计满足预算的interval，并扣除该行假设的P/H；各行是不同情景，不能相加。H每个Jacobian捕获一次并跨所有失败组共享，100%接受，无新增失败开销。跨批typed数字只用作量级参照。

假设每interval的P / baseline H，µs	过预算interval数	涉及原fallback ms	占原区间fallback	情景剩余净空间 ms
2 / 0	72	613.980	89.94%	438.364
5 / 0	35	496.359	72.71%	249.959
7.109 / 0	24	415.138	60.81%	160.350
10 / 0	13	284.669	41.70%	96.509
2 / 18.258	9	235.564	34.51%	57.870
5 / 18.258	6	169.775	24.87%	22.341
7.109 / 18.258	3	95.742	14.03%	8.448
10 / 18.258	0	0	0%	0

因此，“高成本interval占60.81%”只对应零baseline、整个interval固定7.109µs的理想条件。计入当前baseline量级后缩到14.03%，而这14.03%也只是原计算覆盖量，扣成本后仅8.448ms。三个区间在独立operation模式下也过相同账面门槛，但仍未证明融合实现可以达到该成本。

若每个group都要独立捕获，H不能被2组摊薄；在P=7.109/H=18.258情景下，所有interval都不再盈利。当前没有任何一个新interval被证明具有实际semantic replay净收益。

换方法后的空间

• 单operation semantic replay，维持当前成本量级：可盈利覆盖为0%。 这不是证明所有更便宜的semantic方法都不可能，只是否定当前这条逐operation路径。
• native语句工作池：577.486ms，占operation模式87.44%。 这是55个pipe/orifice语句全部计算的宽松上界，里面有必须保留的context访问和现有memo开销，不能全部归给kernel优化。
• 四个PNVO候选position379/392/405/418：98.575ms的整个operation上界。 下一次只测379，其25.926ms上界之外不先承诺扩展。kernel尾部占比和实际命中率尚未测出，所以不能给出“已值得优化的kernel占fallback百分比”。
• 纯代数/alias：82.944ms，占operation模式12.56%。 分布在196个连续段，最大段均值也只有1.846µs。只能考虑少数长段的廉价批量恢复；全量消除的82.944ms是含短语句插桩的宽松上界。
• 全部fallback原工作约 0.61–0.68s/轨迹 只是所有相关工作免费消失的极宽上界，不能当成可实现的净节省，也不能由此推算最终solver加速比例。其余Jacobian/积分成本仍然存在。

方向调整：R288负收益证明的是低成本operation不适合当前这种replay机制，不是semantic replay原理不可行。眼下数据并未发现单次昂贵的fallback operation；发现的是大量重复的小计算，以及由它们组成的大interval。下一步应验证低成本的kernel复用能否赚回自己的开销，而不是继续扩大context重放范围。

7. 本轮验证与未确定项

分析脚本重新从三轮原始ticks/frequency/采样数还原interval和operation时间，与原analysis逐项核对；检查全部计数、唯一group/position归属、native分类一致性、代数段和各层汇总守恒。生成的JSON保留输入哈希和检查清单。没有用容差修改仿真结果，也没有新增数值正确性声明。

仍未测量：候选379的数学尾部专属成本与key命中率、长区间融合metadata成本、跨组动态契约共享率、切分后低扰动段成本，以及R49跨模式计时差异的成因。这些缺口决定了目前可以提出可证伪的性能实验，不能宣布新的优化已经盈利。

最终选择：保留whole-context机制和廉价原计算；停止R288 replay；下一次只做position379的state_valve数值尾部kernel memo成本/正确性实验。