cinderx-parallel-pyperformance

CinderX Parallel Pyperformance

定位

把 CinderX pyperformance 全量或子集从单进程长跑改成可审计的并行验证流程。这个 skill 关注执行效率和环境正确性，不把繁忙机器上的数据自动解释成正式性能结论。

与 pyperformance-suite-run 的关系：

• 需要普通单条正式 python -m pyperformance run 时，优先用 pyperformance-suite-run。
• 需要在大核机器上拆队列并行跑多个 benchmark、避免 NUMA/L3/SMT 踩踏时，用本 skill。
• 调试单个 benchmark worker 环境时，回到 pyperformance-worker-run。

必读资源

运行真实任务前读取：

• references/runbook.md：8/16 模式策略、blue-server-53 拓扑、代理、venv/JIT proof、稳定性判读。

脚本资源：

• scripts/parallel_pyperformance.py：NUMA/L3-aware benchmark scheduler，可 --dry-run。
• scripts/setup_and_run_cinderx_parallel_pyperf.sh：在远端 Linux 上创建独立 opt-venv、安装 CinderX wheel、注入 pyperformance worker，并调用调度器。

核心约束

只支持两种正式并行模式：8 lane 和 16 lane。

• --mode auto：优先 16 lane；如果无法在有本地内存的 NUMA node 上分配出 16 个互不共享 L3 的 lane，则降到 8 lane。
• --mode 8：使用 8 个主 lane。
• --mode 16：必须真的满足 16 个主 lane；如果会使用无本地内存 NUMA、SMT sibling 或跨 lane L3 重叠，停止并报告原因。

不要为了凑核数使用没有本地内存的 NUMA CPU。不要把 L3 重叠当成默认可接受的正式口径；只有用户明确要求探索性超分时，才另写或修改调度参数，并在结论里标成非正式。

标准流程

1. 确认环境和输入。

   • 远端主机、目标 Python、CinderX wheel、runroot、benchmark subset 或 full。
   • 目标是否只是 dry-run、稳定性两跑、还是正式 baseline/candidate。
   • 机器是否正在被其他任务占用；占用时只输出趋势或验证观察。

2. 证明 CinderX 进了 manager 和 worker。

   • 使用独立 opt-venv。
   • opt-venv 安装 pyperformance 和目标 CinderX wheel。
   • pyperformance worker venv 也安装同一个 CinderX wheel，且 benchmark 过程中通过 PYTHONPATH + sitecustomize.py 让派生 worker venv 也能导入 _cinderx_auto。
   • 记录 manager/worker probe：frame_evaluator=True、compile_after=2、toy function compiled。

3. 先 dry-run 调度计划。

   • 打印每个 lane 的 CPU、membind node、benchmark 队列、尾部轨道、峰值活跃物理核。
   • 如果 53 自动选择 8 lane，这是预期行为：node1/node3 没有本地内存，不能拿来凑 16。

4. 再运行真实测试。

   • 从独立 pyperf-work 目录运行，避免误用当前工作目录下旧 worker venv。
   • 继承 CINDERX_PLUGIN_ENABLE,PYTHONJITAUTO,AUTO_JIT,PYTHONJITLIGHTWEIGHTFRAME,PYTHONPATH,LD_LIBRARY_PATH。
   • 保持 PYTHONJITAUTO=2、AUTO_JIT=2、--warmup 3，除非用户给出不同口径。

5. 输出结论。

   • 给出 runroot、result JSON、compare log、模式、CPU/lane 证据、JIT proof 摘要。
   • 对繁忙机器上的波动保持保守：优先说“稳定性观察/环境验证”，不要说“正式回归结论”。