性能回归：低线程数/老平台 CPU 吞吐严重倒退（i3-10105 复现）

[unknowbug]

复现环境与数据（来自轩某Rikka，2026-08-06，B 站对话记录）

• CPU: i3-10105（4C8T，无大小核）/ GPU: 1660s / 内存分配: 8G
• coreswap-1.0.7 + starlight-1.1.2；对照 c2me-fabric-0.2.0+alpha.11.18 + starlight + zfastnoise
• Chunky-1.3.146，半径 650 区块生成，总用时：

方案	总用时
vanilla	0:02:42
c2me	0:02:10
coreswap	0:06:59

初步分析（待验证）

默认线程数 = hardware_concurrency() = 8（逻辑线程），在 4 物理核（SMT）上存在过分配嫌疑：

1. SMT 执行单元争抢：8 线程抢 4 个物理核的 ALU/FPU 端口，计算密集负载下 SMT 收益通常仅 1.1-1.3x，有时为负
2. thread_local 缓存翻倍：每线程一份缓存，8 份挤进 6MB L3，命中率崩
3. 内存带宽短板：双通道 DDR4-2666，带宽约为 Zen4/DDR5 平台一半，噪声采样密集访存先饱和

另：Intel 混合架构（12 代+，如 14650HX）的 E 核拖累可能是同一机制的另一表现（E 核无超线程、性能约为 P 核 60-70%）。

验证实验（进行中）

• -Dcoreswap.threads=4 重测
• -Dcoreswap.threads=2 重测

修复方向

• 默认线程数改为 min(物理核数, 任务数)（而非逻辑线程数）
• 或启动时微基准自适应定线程数
• 对混合架构：仅统计 P 核（GetLogicalProcessorInformationEx 可区分 P/E 核）

---

关联：#6（原报告，因骚扰关闭）；B 站实测：视频 BV1fmuJ65EUq

[unknowbug]

验证结果（2026-08-06，轩某Rikka，i3-10105）

• -Dcoreswap.threads=4 重测：平均 CPS 17.3（默认 8 线程时约 4 CPS）→ 约 4x 提升
• 对照（同机）：vanilla 约 10.4 CPS（2:42），c2me 约 13 CPS（2:10）
  → threads=4 时 CoreSwap = 1.66x vanilla、1.33x c2me
• 轩某Rikka 阅读源码补充：额外开销来自 wg_fill_blocks_multi 每批次创建-销毁线程池

结论

SMT 过分配假设验证成立（线程数 > 物理核数时计算密集负载负收益），且线程池生命周期是第二开销源。

修复方向（更新）

1. 默认线程数改为 min(物理核数, 任务数)（而非逻辑线程数）——已验证方向正确
2. 线程池常驻/复用（消除每批次创建-销毁开销，轩某Rikka 指出）
3. 混合架构（12 代+，如 14650HX）仅统计 P 核（GetLogicalProcessorInformationEx）
4. （可选）启动微基准自适应定线程数

待办：-Dcoreswap.threads=2 重测（确认曲线）；修复版本发布后默认配置回归验证。

[unknowbug]

补充：分场景线程策略（指挥官洞察，2026-08-06）

修复不应是"一个默认线程数"，而是按运行场景分叉：

场景	线程策略	依据案例
客户端 (EnvType.CLIENT)	min(物理核数 - 预留核(1~2), 任务数) —— 留核给渲染管线	G4560 (2C4T, DDR4-2133)：coreswap 71fps vs c2me 58fps（生成加速直接变帧率；弱机尤其需留核，避免生成抢渲染）
服务端 (EnvType.SERVER)	min(物理核数, 任务数) —— 无渲染，全核生成	i3-10105 (4C8T)：Chunky 650 半径，默认 8 线程 6:59（约 4 CPS）→ threads=4 时 17.3 CPS（1.66x vanilla / 1.33x c2me）；纯生成负载下过分配伤害最大

• 检测：FMLEnvironment.dist（Fabric EnvType.CLIENT / SERVER）
• 进阶可选：生成线程 affinity 钉在非渲染核（SetThreadAffinityMask），彻底隔离渲染与生成
• 结论：客户端保守（留核给渲染）、服务端吃满（物理核数）——两个"矛盾"案例（G4560 正反馈 vs i3-10105 负反馈）正是该分叉策略的两个证据面

[unknowbug]

1.0.9 已发布，修复了你分析的线程过分配问题。

根因确认

默认线程数 = \hardware_concurrency()\ = 8（逻辑线程）——4C8T 上 SMT 过分配：执行单元争抢 + thread_local 缓存翻倍 + 内存带宽饱和 → 6:59（比 vanilla 还慢 2.5x）。

修复

1. 默认线程数改为物理核数（Windows GetLogicalProcessorInformationEx 数物理核，SMT 不重复计）——i3-10105 → 4 线程
2. \CORESWAP_THREADS\ 环境变量 / -Dcoreswap.threads=N\ 可配（可 A/B 验证）
3. 顺带修复 WG_B3DDUMP 诊断插桩导致的性能暴跌（getenv 每次采样调用）

主世界 100% 逐位一致保持。请用 1.0.9 重测 Chunky radius 650，预期吞吐大幅回升（c2me 2:10 附近或更好）。

[sweepikun]

真的只是线程问题吗😏