perf: UniSim 1.4.0→1.5.1 后 MuJoCo collector 吞吐下降 36%–43%，定位并优化状态更新开销

[TATP-233]

问题与目标

在相同 UniLab 代码、任务和依赖环境下，将 unisim-core 从 1.4.0 切换到 1.5.1，本机 Linux/Ryzen 的 MuJoCo collector 活跃窗口吞吐在三个任务均下降：Go2 36.47%–42.57%、G1 平地 18.84%–21.60%、G1 motion tracking 18.93%–20.56%。主要耗时增量出现在状态更新阶段；需要定位具体调用、重复工作及串行成本，并在保留新版状态正确性的前提下优化。

本 issue 跟踪性能回退的归因与修复。依赖更新和初始 Go2 测量由 #1601 提供；M2 下游消费另见 #1599。这里没有混入 M2 消费代码，也没有使用 1.5.0 作为性能基线。

本机三任务合并实测（Linux / Ryzen）

参考 macOS / Apple M5 Max 三任务独立复测，现补充本机 flashsac/g1_walk_flat/mujoco 和 sac/g1_motion_tracking/mujoco，与原 Go2 合并成六行表。本表全部是本机 Linux 数据，不混入 Mac 数值。 Mac 与 Linux 的绝对吞吐不能直接横比；只有各自同机 A/B 的相对变化有效。

测量使用同一 UniLab 84a00d049eeac9292bbd58c25fcd06a4b64cd712 的既有 scripts/benchmark/rl/benchmark_offpolicy_collector_active.py。两版只切换 UniSim，逐次核对其余 133 个包版本完全一致；原 Go2 与补测 G1 的 benchmark 文件 hash 也一致。原 Go2 12 次与本轮 G1 24 次分批执行，合计 36 次，并非同一连续测量会话。

吞吐

单位为 环境 transition/s，每格是三次独立进程运行的中位数及最小—最大范围；不是 physics substep/s 或训练端到端吞吐。

任务	环境数	UniSim 1.4.0	UniSim 1.5.1	中位数变化
go2_joystick_flat (flashsac)	1024	138,780（131,699–141,773）	88,167（82,537–89,607）	-36.47%
go2_joystick_flat (flashsac)	4096	209,773（206,357–209,957）	120,476（117,284–120,949）	-42.57%
g1_walk_flat (flashsac)	1024	42,775（42,736–43,039）	34,715（34,260–34,738）	-18.84%
g1_walk_flat (flashsac)	4096	50,655（50,534–50,934）	39,716（39,661–39,957）	-21.60%
g1_motion_tracking (sac)	1024	41,053（40,906–41,306）	33,282（32,692–33,612）	-18.93%
g1_motion_tracking (sac)	4096	47,819（47,754–48,112）	37,987（37,978–38,086）	-20.56%

三个任务的全部 18 组配对均下降，无丢弃计时样本；本轮两个 G1 任务的 12 组配对也全部下降。

分项

每次运行的 vector-step 阶段均值再取三次运行中位数，单位 ms/vector step；各列独立取中位数，不保证可直接相加。

任务	环境数	Physics，旧→新	Update state，旧→新	Replay，旧→新
go2_joystick_flat	1024	5.743 → 6.306	1.012 → 4.443	0.524 → 0.581
go2_joystick_flat	4096	16.344 → 16.811	2.482 → 15.994	0.465 → 0.941
g1_walk_flat	1024	20.568 → 20.646	1.015 → 6.378	0.412 → 0.405
g1_walk_flat	4096	72.713 → 73.232	2.675 → 24.114	1.100 → 1.084
g1_motion_tracking	1024	20.740 → 20.852	2.124 → 7.591	0.591 → 0.577
g1_motion_tracking	4096	73.607 → 73.915	7.219 → 28.697	1.244 → 1.310

Reset 计数与语义边界

下表是每次计量窗口内 reset 的环境行数总和；同任务、同规模、同版本的三次运行计数完全一致，因此只列一个数。不是 reset API 调用次数。

任务	环境数	UniSim 1.4.0	UniSim 1.5.1
go2_joystick_flat	1024	0	0
go2_joystick_flat	4096	0	0
g1_walk_flat	1024	6,158	6,163
g1_walk_flat	4096	24,496	24,672
g1_motion_tracking	1024	9,652	9,947
g1_motion_tracking	4096	39,143	40,039

Go2 的 12 次计量窗口 reset 全为零，原结论不变；两个 G1 任务存在 reset，所以 G1 吞吐不隔离 reset 路径。跨版本同 seed 下 reset 总数不同，说明轨迹/终止发生分叉，不能把旧版较高吞吐当作完全等价正确语义的上限。

G1 仍以 update state 为主要增量：4096 环境下平地从 2.675 → 24.114 ms，motion tracking 从 7.219 → 28.697 ms；对应 physics 仅为 72.713 → 73.232 ms 和 73.607 → 73.915 ms。reset_done 阶段均值中位数分别为平地 3.798 → 4.068 ms、tracking 2.742 → 2.967 ms，不足以解释主要增量。此为分项观察，尚非具体函数的因果消融。

复现条件

• Linux；AMD Ryzen 9 9950X3D2，固定进程及 MuJoCo worker 使用 CPU 0–7，共 8 个不同物理核；Torch、OpenMP、BLAS、Numba 线程均为 8。
• Python 3.13.14、MuJoCo 3.11.0、mjbatch-uni 0.2.1、NumPy 2.4.4、Torch 2.8.0+cu128、unilab-rl 1.2.1。仿真及 replay 均在 CPU；本轮只测 MuJoCo。
• algo.seed=1、env.seed=1；全零动作；预热 30、计量 300 个 vector steps；replay 容量为 64 个 vector steps。
• 每个任务、每个规模、每个版本三次全新进程串行执行。1024 顺序 A/B、B/A、A/B；4096 顺序 B/A、A/B、B/A，A=1.4.0、B=1.5.1。G1 两任务分别启动进程，无共享运行中的 env。
• 指标为 N × 300 / Σ(env_step + replay + bookkeeping)，包括环境、奖励/终止处理和 replay 写入；不含策略推理、learner 等待、跨进程 IPC、初始化或完整进程墙钟时间。
• CPU affinity 不等于独占 CPU，后台负载、频率和温度未隔离。结论限于这些任务、规模和机器，不推广为所有任务的训练吞吐。

任务	Actor obs	Critic obs	Action
go2_joystick_flat	49	52	12
g1_walk_flat	98	101	29
g1_motion_tracking	160	289	29

G1 资产准备及此前失败的更新

此前在本机 1.4.0 预检发生过 G1 sensor XML 物化的 mesh 路径错误，原正文因此未列 G1。本次使用新的 detached 84a00d04 worktree 和独立 venv，经官方 asset hub 完成 G1 mesh/texture 与 motion 文件准备后，两任务的原版 1.4.0 均正常构造并完成全部正式运行。未修改 UniSim 包、任务 XML、physics 参数或热路径代码。

此前失败在本轮未复现，故以本轮实测补齐表格；尚未对先前失败原因做独立因果验证，不能据此宣称修复了 importer。Motion 文件为 motions/g1/dance1_subject2_part.npz，测量前后逐次核对资产 hash。

在隔离 checkout/venv 中使用上述 UniLab 提交与锁定的其余依赖，分别设置版本、任务、环境数及不同输出文件，按上述顺序重复：

uv sync --locked --extra mujoco
uv run unilab-pull-assets --robot g1
uv run python -c "from unilab.assets.hub import resolve_motion_files; print(resolve_motion_files('motions/g1/dance1_subject2_part.npz'))"
UNISIM_BENCH_VERSION=1.4.0
uv pip install --python .venv/bin/python --no-deps "unisim-core==$UNISIM_BENCH_VERSION"
taskset -c 0-7 env \
  UNILAB_COLLECTOR_TORCH_THREADS=8 OMP_NUM_THREADS=8 \
  OPENBLAS_NUM_THREADS=8 MKL_NUM_THREADS=8 NUMBA_NUM_THREADS=8 \
  CUDA_VISIBLE_DEVICES= MUJOCO_GL=disable \
  uv run --no-sync python scripts/benchmark/rl/benchmark_offpolicy_collector_active.py \
  --cases flashsac/g1_walk_flat/mujoco --num-envs 1024 \
  --warmup-steps 30 --measure-steps 300 --replay-capacity-steps 64 \
  --override algo.seed=1 --override '++env.seed=1' \
  --override '++env.cpu_ids=[0,1,2,3,4,5,6,7]' \
  --out-json /tmp/g1-walk-140-n1024-r1.json
# 第二任务改为 --cases sac/g1_motion_tracking/mujoco；另测 --num-envs 4096。
# 每版本每规模重复三次，使用不同输出文件。
uv sync --locked --extra mujoco

历史 1.4.0 不满足当前 manifest，故实验显式使用 --no-sync，结束后恢复隔离环境依赖；原有开发工作树及其环境未改变。

原始证据

原 Go2 12 次结果固定在 #1601 的提交 a9b8244e842ccdee63a7053ccaf8fc46429288af：

• 原 Go2 报告（历史 G1 未纳入说明已由本次正文更新）
• 原 Go2 汇总 JSON
• 原 Go2 完整原始结果

本轮 G1 的 24 个 JSON、日志、精确命令、完整包版本和资产 hash 保存在本机 /home/user/ws/unilabsim/UniLab-1602-retest/scripts/benchmark/outputs/issue1602_g1_retest/，runs.json 包含全部原始 payload，summary.json 为三任务合并统计。独立子代理核对了逐文件 SHA256、每次 300 个样本、样本均值和吞吐公式；所有检查通过。以下内嵌逐次吞吐和 reset 可直接复核正文的中位数/范围，不要求访问本机文件。

完整 G1 原始归档 g1_retest.raw.json.gz SHA256：b498fbcc74e1fd6895a2ccf524e7ce61e6d68fea7bb2af16328a805cfd7be817。Benchmark SHA256：317c91948a834cbd38795d9513c220334ef9b342432576b53cebdd331ae89d20。

G1 24 次逐次吞吐、reset 与原始 JSON 校验值

任务	N	版本	重复	transition/s	Reset 行数	JSON SHA256
g1_walk_flat	1024	1.4.0	1	42736.005277	6158	076fa4dac80389416e64f4c1a20031320eb284d96e7338c80d7f48550352d2b3
g1_walk_flat	1024	1.5.1	1	34714.837695	6163	4a241f0e24e956db952318d3badc3fbb6dce0163c765e9eb5d705e5371cc0c36
g1_walk_flat	1024	1.5.1	2	34259.803138	6163	621922c13ba7f489cc37e2a3379d459855e253f3fcd703a09d3bbb1e332fdd0b
g1_walk_flat	1024	1.4.0	2	43039.439821	6158	97806a64f34cb35fb1cc914f6a1e954d27dc96276bb5be965df56d8dc139eaff
g1_walk_flat	1024	1.4.0	3	42775.416628	6158	dd3c9c1bca730f2e3bc3a767e40cfd7d84ec8f97e6601371be6c78d09758c17f
g1_walk_flat	1024	1.5.1	3	34738.152077	6163	a15bfe94e9be8a2db9bcf70e1a81306b7150ec6dc5f24e2bbed4ff758cad98df
g1_walk_flat	4096	1.5.1	1	39956.962896	24672	6d1cfb3ebe83ec2c38294075685d321b9703b70dac7c3a08d47e4836387966d8
g1_walk_flat	4096	1.4.0	1	50655.150825	24496	1699de55b7fc65ad069127699941ce049a7f4f0f94d7049578afa0f7076d21b4
g1_walk_flat	4096	1.4.0	2	50934.410032	24496	db74f2d080ab2cec6ae812e0670fbc2642920ea3e474d333e7432a47e7d2b442
g1_walk_flat	4096	1.5.1	2	39715.998574	24672	de5af6ecc8107dff4c692c32c92b86374a7e8c3aa9c16d880bbde91efc139181
g1_walk_flat	4096	1.5.1	3	39661.126147	24672	833ef169fca783557c621fd96c4c8ae6d72cda2882503f2df2b380316806ee57
g1_walk_flat	4096	1.4.0	3	50533.818397	24496	686ba1720158d7713bb973d97ed39aa81f44c02cd153bcfee537b95e6495f097
g1_motion_tracking	1024	1.4.0	1	41053.237145	9652	aeb8cde2db4f8179b9027d37820cf6439171d84189a791fb153a161e6ca62174
g1_motion_tracking	1024	1.5.1	1	33281.549946	9947	c641f8e9ea3b7e2423cb1633f57422266b3b795962c667a7925f973e71a3dc68
g1_motion_tracking	1024	1.5.1	2	32691.520157	9947	b11efc0879f58ba88b4f434b987ed37d54e31f0d4d3ae7450dfca4ef972e6650
g1_motion_tracking	1024	1.4.0	2	41305.833860	9652	d7dd9c989897a205e51f1b6ec746deb381b263019cf14dbc2bd8c442c82d72c0
g1_motion_tracking	1024	1.4.0	3	40906.178672	9652	88d4cbb3aaa46300f3462259d494e1ad052385b7d1d06ebb61194aaa0f07a5f4
g1_motion_tracking	1024	1.5.1	3	33612.121268	9947	815a12622987ca12fe6924da4fb0e24d998a75561be460783c4397ffba32c197
g1_motion_tracking	4096	1.5.1	1	37977.540066	40039	302204095f5f43c587dd938c1fb475aa47e77e6e3464ad3b49e0ccaa0bd45a78
g1_motion_tracking	4096	1.4.0	1	47753.849639	39143	4c33717b6048eaf9c3e150c89f4c8587efd6002d9e692e23d9d5c2a63754c45c
g1_motion_tracking	4096	1.4.0	2	47819.411941	39143	72f0a67b9791e9073e2c88dcad22496824d3f808f48fa5a97794c1b28a74aa0e
g1_motion_tracking	4096	1.5.1	2	37987.164840	40039	c9f5b205831e69526bdef05f0c13c2eae7105e37983ef63d607bd223fa17d4fb
g1_motion_tracking	4096	1.5.1	3	38086.119789	40039	7d16ec93cb13bf0520da2cd9ea49f76b1230939333afceb3bf0ccb0936256de6
g1_motion_tracking	4096	1.4.0	3	48111.642216	39143	55a4bf87e09c117c35fcf695874e532bc55bf7009e4b1a93904ce5f99e29179c

初步定位：候选解释，尚非因果结论

已有后续评论将路径级 profile 与优化方案提交至上游 unilabsim/unisim#142。该归因证据与本轮三任务吞吐补测分开记录；本次没有运行该 cProfile，也没有实现性能修复。

UniSim v1.4.0…v1.5.1 差异包含状态正确性修复。新版 MuJoCo adapter 的 _sync_tracked_body_state() 在 step 后首次 body 查询时，对 dirty environment 执行最终运动学、速度及 tracking sensor 同步；旧版直接读取已有缓存。UniLab 的 body-state 消费路径会触发这些查询。

三个任务都观察到“Physics 变化较小、update state 增量较大”，与上述新增工作一致，但当前阶段计时不能独立证明某个函数是根因。需要测量调用次数、刷新行数、覆盖的 body/sensor、复制量与串行/原生执行成本，区分必要刷新和重复工作。1.5.1 修复了旧版可能滞后的读数，不能把 1.4.0 的较高吞吐直接当作等价正确语义的性能上限。

Owner、范围与实施边界

• UniLab：collector benchmark、Manager-Based observation/reward 的公共状态消费，以及避免上层重复读取/复制。不得在 env 或训练代码中调用 backend 私有接口。
• UniSim MuJoCo adapter：状态新鲜度、dirty/cache 生命周期、按需刷新与批量查询。若瓶颈需要原生并行或融合实现，由 mjbatch 的原生 owner 承担，不在 UniLab 重建 executor。
• UniLab 的预期 PR base 为 main；依赖 build: pin UniSim 1.5.1 and compare MuJoCo collector throughput #1601，或在明确记录的隔离环境中固定正式 1.5.1 验证。上游修复各自向其仓库 main 提 PR，并在本 issue 关联。
• 遵守 ADR-0007 包边界及父级 AGENTS.md：资产解析留在冷路径，后端行为位于 SimBackend 后；不引入第二 DR 生命周期、learner/collector 协议改造或新的常规性能 CI。

本 issue 不扩大到其他物理后端、GPU collector、大规模训练调参或 G1 历史资产导入修复。若需要新公共能力、生命周期或持久 benchmark 服务，先单独记录范围决定。

验收

• 在相同任务、核数、seed 和依赖条件下复现 1.5.1 的开销，增加可审查的路径级 profile/A-B，证明具体瓶颈；额外插桩与正式吞吐测量分开，记录其开销。
• 修复已确认的重复读取/复制/刷新或串行瓶颈，行为放在正确 owner；不通过关闭最终状态刷新、减少应有物理子步、丢弃终止/replay 工作或改变任务物理语义提高分数。
• 以修复前的 1.5.1 正确语义为回归参考，覆盖连续 step 后 pose/velocity、按需/重复查询、partial reset 隔离，以及 callback 前和 step 后的新鲜度边界。接触/force sensor 的求解时刻不得被重算或覆盖成另一种语义。
• 对上述三个任务同口径复测 N=1024、4096，至少各三次独立进程并交替顺序；报告吞吐中位数/范围、配对变化、physics/update/replay 分项和 reset 数量，给出可重复的改善。若仍未达到旧版数值，保留剩余差距与必要正确性成本的解释，不声称完全消除回退。
• 更新报告、原始数据和修复 PR 链接；UniLab 最终 head 通过 make check、make test-all 及 main PR 远程 CI，上游改动通过各自仓库门禁。仅测量 MuJoCo，不用 mock/skip 代替必需的真实运行结果。

[TATP-233]

独立复测（macOS / Apple M5 Max）：Go2、g1_walk_flat、g1_motion_tracking 三任务均复现回归，update state 为唯一显著增量

在与 issue 环境完全不同的机器上按相同方法复测，三个任务全部确认回归。分项特征与 issue 一致：增量几乎全部落在 update state，physics 变化小，replay 不变。

环境与偏差

• UniLab 84a00d04 隔离 worktree + 独立 venv，uv sync --locked --extra mujoco 后仅切换 unisim-core（--no-deps，A=1.4.0 / B=1.5.1）。
• macOS 26.6.2 arm64，Apple M5 Max（18 核），128 GB；Python 3.13.12、MuJoCo 3.11.0、mjbatch-uni 0.2.1、NumPy 2.4.4、Torch 2.8.0、unilab-rl 1.2.1。
• 偏差 1：macOS 无 taskset/sched_setaffinity，进程与线程均未做 CPU 绑定；频率动态（Apple Silicon）。
• 偏差 2：++env.cpu_ids=[0..7] 在本机不可用——MuJoCo backend 的 cpu_ids pinning 仅支持 Linux（实测 materialize 阶段直接报错 cpu_ids pinning is only supported on Linux），故省略该 override；以 UNILAB_COLLECTOR_TORCH_THREADS=8、OMP/OPENBLAS/MKL/NUMBA_NUM_THREADS=8 对齐线程数。
• 其余条件与 issue 一致：algo.seed=1、env.seed=1、全零动作、预热 30 / 计量 300 vector steps、replay 容量 64 steps；每个任务、每个规模三次独立进程串行执行，顺序为 1024：A/B、B/A、A/B；4096：B/A、A/B、B/A。共 36 次运行。
• 因硬件与平台不同，绝对吞吐不可与 issue 数据比较，仅同机 A/B 相对变化有效。
• issue 中记录的"G1 平地在 1.4.0 sensor XML 物化阶段 mesh 路径解析错误"在本机未出现——g1_walk_flat 在 1.4.0 下正常构造并进入计时，因此这里补充了 issue 缺失的 G1 平地完整 A/B。

吞吐（环境 transition/s，三次独立进程的中位数及最小—最大）

任务	环境数	UniSim 1.4.0	UniSim 1.5.1	中位数变化
go2_joystick_flat (flashsac)	1024	368,611（354,137–369,209）	147,990（147,569–149,728）	−59.85%
go2_joystick_flat (flashsac)	4096	412,978（400,374–416,396）	165,884（164,969–167,720）	−59.83%
g1_walk_flat (flashsac)	1024	80,762（79,427–81,498）	57,696（55,948–57,963）	−28.56%
g1_walk_flat (flashsac)	4096	81,064（72,729–81,400）	57,813（52,938–57,911）	−28.68%
g1_motion_tracking (sac)	1024	70,771（69,981–70,964）	51,663（50,681–52,292）	−27.00%
g1_motion_tracking (sac)	4096	71,578（67,679–71,748）	55,236（54,406–55,565）	−22.83%

全部 18 组配对均下降，无丢弃样本。

分项（每次运行的 vector-step 阶段均值取三次运行中位数，ms/vector step）

任务	环境数	Physics，旧→新	Update state，旧→新	Replay，旧→新
go2_joystick_flat	1024	1.567 → 2.011	0.789 → 4.496	0.153 → 0.154
go2_joystick_flat	4096	6.122 → 6.288	2.393 → 17.092	0.275 → 0.262
g1_walk_flat	1024	9.999 → 9.878	0.867 → 5.932	0.238 → 0.234
g1_walk_flat	4096	43.393 → 40.854	2.986 → 25.703	0.628 → 0.627
g1_motion_tracking	1024	10.051 → 10.015	2.469 → 7.695	0.377 → 0.375
g1_motion_tracking	4096	42.797 → 39.969	10.428 → 29.474	0.848 → 0.743

Reset 计数

• Go2 全部 12 次运行计量窗口内 reset 数为零，与 issue 相同，不覆盖 reset 吞吐。
• 两个 G1 任务窗口内存在 reset（300 个 vector steps 内：walk_flat 约 6.2k（N=1024）/ 24.5k（N=4096）次，motion_tracking 约 9.7k / 39.1k 次），G1 数据不隔离 reset 路径；但 update state 增量模式与零 reset 的 Go2 相同，主归因不变。

观察

1. 回归在第二种 OS/CPU（macOS + Apple Silicon，大小核、无 affinity）上、三个任务中均复现，说明该开销不是 Linux/Ryzen 或单任务特定现象。
2. update state 是各任务唯一显著增量；绝对开销随任务身体/传感器规模增长：4096 下 Go2 为 17.1 ms，G1 达 25–29 ms，与"每次 step 后按查询触发的全量身体/tracking sensor 同步"的候选解释方向一致。
3. 值得注意：本机 Go2 在 1.5.1 的 update state 绝对值（1024：4.496 ms，4096：17.092 ms）与 issue 在 Ryzen 9950X3D 上的数值（4.443 ms / 15.994 ms）几乎相同，而两机的 physics 与整体吞吐差异很大。这暗示 1.5.1 新增的 update state 工作对 CPU 微架构/单核性能不敏感（例如由固定次数的串行调用、Python 层开销或同步原语主导），支持"重复刷新/串行成本"的候选方向；下一步路径级 profile 应重点核对调用次数与串行段，而非原生计算量。
4. 相同 algo.seed=1/env.seed=1 下，G1 任务两版的窗口内 reset 总数系统性略有差异（如 motion_tracking 4096：39,143 vs 40,039；同版本三次完全一致，跨版本不一致）。这说明同 seed 轨迹在两版之间发生分叉，与 1.5.x 状态新鲜度修复改变读数语义的预期一致——也再次提示不能按"等价语义"直接比较 1.4.0 吞吐上限。修复回归测试时建议把"同 seed 下轨迹是否允许分叉"纳入预期。

原始 36 个结果 JSON（含逐步计时样本）保留，如需可上传或提供 hash。

[TATP-233]

路径级 profile 归因与优化方案已提交至上游：unilabsim/unisim#142。

要点：_sync_tracked_body_state() 解释了约 94% 的 update state 增量（cProfile：每步对全部 env 各执行 5 次 per-env ctypes 调用，N=1024 时 4.2 ms/step，与分项计时 4.50 ms 吻合）；成本为 Python/ctypes 串行调度主导（两架构机器绝对值几乎相同）；callback 路径已有的 mjbatch 原生 substep_sensor_copyout 是现成参照，主修复建议为 mjbatch 原生批量刷新（P0），UniLab 侧无需改动。本轮仅归因与方案，未做实现。

[TATP-233]

Apple M5 Max UniLab #1602 follow-up benchmark

Environment: Apple M5 Max (18 cores, 128 GB), UniLab 84a00d049eeac9292bbd58c25fcd06a4b64cd712, this PR with mjbatch-uni==0.2.2, warmup 20 + measured 100 vector steps, algo.seed=1, and three independent processes per cell. The historical 1.4.0/1.5.1 values are the macOS medians/ranges already recorded in #1602.

Throughput (env transitions/s, median with min–max)

Task	N	1.4.0	1.5.1	PR	PR vs 1.5.1	PR vs 1.4.0
go2_joystick_flat	1024	368,611 (354,137–369,209)	147,990 (147,569–149,728)	274,479 (267,864–276,565)	+85.5%	−25.5%
go2_joystick_flat	4096	412,978 (400,374–416,396)	165,884 (164,969–167,720)	311,306 (311,242–311,899)	+87.7%	−24.6%
g1_walk_flat	1024	80,762 (79,427–81,498)	57,696 (55,948–57,963)	78,956 (77,523–79,643)	+36.8%	−2.2%
g1_walk_flat	4096	81,064 (72,729–81,400)	57,813 (52,938–57,911)	78,721 (78,518–82,604)	+36.2%	−2.9%
g1_motion_tracking	1024	70,771 (69,964–70,964)	51,663 (50,685–52,293)	64,224 (63,507–64,249)	+24.3%	−9.3%
g1_motion_tracking	4096	71,578 (67,679–71,748)	55,236 (54,406–55,565)	69,467 (69,413–69,564)	+25.8%	−3.0%

Update-state phase (ms/vector step, median of three runs)

Task	N	1.4.0 → 1.5.1 → PR	PR reduction vs 1.5.1
go2_joystick_flat	1024	0.789 → 4.496 → 1.069	−76.2%
go2_joystick_flat	4096	2.393 → 17.092 → 3.119	−81.8%
g1_walk_flat	1024	0.867 → 5.932 → 1.255	−78.9%
g1_walk_flat	4096	2.986 → 25.703 → 4.474	−82.6%
g1_motion_tracking	1024	2.469 → 7.695 → 3.318	−56.9%
g1_motion_tracking	4096	10.428 → 29.474 → 10.939	−62.9%

The targeted Python/ctypes synchronization regression is substantially recovered. G1 throughput is within 3–9% of 1.4.0; Go2 retains a separate gap despite the update-state fix, so any remaining Go2 delta should be investigated independently rather than attributed to _sync_tracked_body_state.

[TATP-233]

Go2 follow-up attribution correction

The earlier “Go2 still retains a ~25% independent gap” statement was an artifact of comparing a 20-step warmup / 100-step measured PR run against the historical 30/300 A/B runs. Go2 physics continues to speed up through the short window; in the 4096-env run, the per-20-step step_core medians fell from about 12.6 to 7.7 ms. Repeating with the historical 30/300 protocol removes that bias.

Same-session A/B

UniLab 84a00d049eeac9292bbd58c25fcd06a4b64cd712, Apple M5 Max, mjbatch-uni==0.2.2, thread caps 8, warmup 30 / measured 300, three independent processes per cell. “Fixed” is unilabsim/unisim#146; “1.4.2” is the PyPI release.

N	Throughput 1.4.2	Throughput fixed	Change	Physics median Δ	Update-state median Δ
1024	346,286 (345,663–353,476)	317,533 (314,928–318,964)	−8.30%	+0.046 ms	+0.236 ms
4096	395,994 (392,240–401,947)	372,929 (365,703–380,816)	−5.83%	+0.090 ms	+0.560 ms

Based on total active-time delta, the residual gap is approximately 88% final-state refresh cost and 14–17% small physics variance, with action/replay differences offsetting the small excess. There is no evidence of a separate Go2 step-path regression.

Why the remaining refresh cost is not simply “copy fewer bodies”

The materialized Go2 model has 14 bodies, 116 sensors, and 328 sensor columns; injected world-frame tracking occupies columns 68:328. A direct N=4096 mjbatch microbenchmark measured:

• all-body tracking refresh: 0.623 ms median
• only the four base tracking sensor ranges: 0.611 ms median

Only about 2% is saved because refresh_sensor_ranges controls copied columns, while each selected row still runs mj_kinematics, mj_comPos, mj_comVel, mj_sensorPos, and mj_sensorVel. A materially smaller cost would require a more specialized selective-sensor computation, not merely narrowing the current range list.

The fixed Go2 backend also has _entity_layout is None, so the new entity/ctrl validation path is not involved. Its native step loop is effectively the 1.4.2 loop plus marking tracked state dirty; physics medians differ by only 0.046–0.090 ms.