# PPT 补充 · D5 · 三个补充基线

> 实验机 `ubuntu@cuda-ke`。D5 为"加深、非必需"项。已做 ②③;① 见文末说明。

---

## D5② · 单个 SymCC 进程吞吐(无 master/worker 的干净基线,回答 #7.2)✅

**做法**:直接跑 SymCC 插桩二进制 `google-fts/xml_read_fuzzer`(libsymcc-rt.so),
逐个种子喂入、`SYMCC_OUTPUT_DIR` 收集本次 concolic 生成的测试用例,计时。**无 MPI、无 master、
无 worker 协调、无 showmap 去重**——纯"水龙头"生成速率。

| 种子 | 单次 concolic 生成 | 耗时 |
|---|---|---|
| seed_01.xml | 225 | 0.18s |
| seed_02.xml | 524 | 1.13s |
| seed_04_dtd.xml | 941 | **22.3s**(DTD 深解析,重) |
| seed_05_ns.xml | 396 | 0.47s |
| seed_06_deep.xml | 361 | 0.37s |
| …(共 12 个种子) | | |
| **合计** | **4,729 outputs** | **26.5s** |

- **单进程原始生成率 ≈ 178 tc/s**;**每次 concolic ≈ 350–400 个测试用例**(中位数)。
- **强烈右偏**:`seed_04_dtd`(DTD 解析)一个就吃了 22.3s / 941 输出——**少数"难种子"主导**总时间,
  多数种子 <0.5s。这解释了为何 MPI 里 worker 之间负载极不均(见 D5③:少数 worker 长期忙、其余空转)。

**与 MPI 对照(回答"MPI 交互开销有多大"):**
| 配置 | tc/s | 说明 |
|---|---|---|
| **单进程(纯生成)** | **~178** | 只算 concolic 生成,无去重/协调 |
| MPI np=2(1 master + 1 worker) | 128 | 端到端:含 showmap 去重 + master 协调 |

→ **单进程"水龙头"~178 tc/s;套上 MPI 流水(去重+协调)后单 worker 有效吞吐降到 ~128**,
差值就是**协调/去重开销**。而这 178 tc/s 里 **~80% 是冗余**(见 #10),真正入语料的更少——
**这正是"纯 concolic 生成快、但有效贡献低"、必须靠 hybrid 把 AFL 拉进来的根据。**

数据文件:`13_D5_single_process.dat`。

---

## D5③ · 各 np 下 worker 六阶段耗时(np=8 / np=32)✅

非自适应 hybrid(固定切分,SymCC worker 数随 np 增长→争用真实上升),lava-base64,120s,
`SYMCC_WORKER_PROFILE=1` 量六阶段。**np=8 实际 3 个 worker、np=32 实际 12 个 worker**(各处理 1 个 item)。

**六阶段占比(占 worker 总耗时):**

| 阶段 | np=8 | np=32 | 变化 |
|---|---:|---:|---|
| **exec**(Z3 求解 + concolic 生成) | **59.3%** | **46.3%** | ↓ |
| **showmap_dedup**(逐输出 afl-showmap 去重) | **40.4%** | **53.2%** | ↑ |
| wait(等 master 派活) | 0.3% | 0.5% | ≈0 |
| bmsync + import + send(协调/传输) | 0.0% | 0.0% | ≈0 |

**三个结论(都能直接进 deck):**

1. **MPI 协调开销 ≈ 0.3–0.5%,可忽略——master 不是瓶颈。**
   wait+bmsync+import+send 合计 <0.5%,worker 时间几乎 100% 花在真实工作(exec + showmap)上。
   坐实"节点/master 同步开销可忽略,吞吐上不去是 worker 侧的事,不是通信"。

2. **np 越大,showmap 去重越吃时间(exec 反而占比降):59/40 → 46/53,showmap 反超 exec。**
   机制:showmap 对每个生成输出都 fork 一个 `afl-showmap` 短进程;np=32 下 CPU 争用加剧,
   **大量短进程比单个长 Z3 进程更受调度争用之害**,故 showmap 占比升。→ **真正卡吞吐的是"去重后处理",
   不是 Z3 求解本身**(与慢目标 05b 的 showmap 99.7% 同向)。

3. **负载极不均,且随 np 急剧恶化——这是"过并行无益"的机理根因:**
   - np=8:3 个 worker 耗时 6.4 / 14.2 / **39.7** s → 最忙/最闲 **≈6×**。
   - np=32:12 个 worker 从 **0.27s 到 36.9s** → **≈137×**;其中 **4 个 worker(ranks 3/4/11/12)
     ≤1s 就干完了它那 1 个 item——几乎空转**(≈⅓ worker 无实质贡献)。
   → **加更多 worker,多数只领到"琐碎 item"秒退空转,少数重 item worker 还被 showmap 争用拖慢。**
     这与 D5②"少数难种子主导 22s"、D1"甜点≈64 后回落"、D4"np8≈np32 加 worker 不涨"**互为印证**:
     **有效重活就那么几份,worker 超过它就是浪费**——这正是自适应模式把 SymCC worker 封顶(~12)的依据。

数据文件:`05c_phase_timing_np8.csv` / `05c_phase_timing_np32.csv`(每 worker 一行 + TOTAL + MEAN_PCT);
另有固定-np 版 `05a`(lava,快)/`05b`(sqlite,慢:showmap 99.7%)。

---

## D5① · 长时对比(1h vs 300s)—— 未做,可按需补

1h 长跑 wall-clock 成本高,且**边覆盖对短时窗最敏感的结论已由 D1(np 扫描)与 D4(多轮方差)覆盖**。
如答辩需要"覆盖-时间曲线"(证明 300s 尚未饱和 / 已饱和),我可以后台补一组 gfts-xml 的
{60,120,300,900,3600}s 单目标曲线——**要的话说一声即可**。