3. 工作负载分析：典型应用场景提取、Trace采集与特征化
工作负载分析，说白了就是搞清楚你的芯片到底要跑什么活儿。
很多团队一上来就急着搭性能模型，结果模型搭好了，发现跑的场景根本不是用户实际用的。嗯，我见过太多次这种事了。所以今天咱们聊聊，怎么把工作负载分析这件事做扎实。
3.1 典型应用场景提取
我个人习惯，第一步不是看数据，而是先跟产品经理和系统工程师聊。问三个问题：
- 这个芯片最终用在什么设备上？
- 用户最常做的操作是什么？
- 哪些场景下用户会抱怨“卡”或“慢”？
举个例子。我之前做一款AIoT芯片，产品经理说“主要做视频分析”。但深入聊才发现，真正让用户头疼的是设备启动时的模型加载——那个阶段CPU跑满，内存带宽吃紧，用户体验极差。这就是典型场景。
提取场景时，我建议按这个优先级排序：
- 关键路径场景：用户能直接感知到的延迟，比如触控响应、应用启动
- 高负载场景：多任务并发、数据吞吐量最大的情况
- 边界场景：缓存命中率极低、内存带宽打满、温度升高等
- 休眠/唤醒场景：功耗敏感场景，往往被忽略
核心原则：宁可少选几个场景，也要把每个场景的细节挖透。3-5个典型场景，比20个模糊场景更有价值。
3.2 Trace采集：怎么拿到真实数据
场景定好了，接下来就是采集Trace。这里分两种情况：
3.2.1 已有硬件平台
如果你手头有开发板或者上一代芯片，那直接上硬件Trace工具。我个人常用的是：
- ARM CoreSight：抓CPU指令流和ETM trace
- Perfetto：Android/Linux平台的全系统trace
- 自定义硬件探针：在总线或DDR接口上挂逻辑分析仪
采集时要注意几个坑：
我曾经在采集视频解码的trace时，发现数据量太大，trace buffer直接爆了。后来才意识到，应该只抓关键事件（比如帧开始/结束、buffer满/空），而不是全量数据。嗯，这个教训挺深刻的。
3.2.2 无硬件平台（早期阶段）
这时候只能用软件模拟或仿真。我建议的做法是：
- 用开源benchmark（如SPEC CPU、CoreMark、MLPerf）跑出指令混合比
- 用系统级模拟器（如QEMU、Gem5）生成memory trace
- 如果连模拟器都没有，那就手动构建典型行为模式
举个例子，一个典型的视频解码工作负载，它的行为模式可以简化为：
// 伪代码：视频解码工作负载特征
while (frame_count < total_frames) {
// 阶段1：读取压缩数据（DMA密集型）
dma_read(bitstream_buffer, size_8KB);
// 阶段2：熵解码（CPU密集型，分支多）
cpu_decode_entropy();
// 阶段3：运动补偿（内存访问密集，随机访问）
for (each_macroblock) {
dma_read(reference_frame, size_4KB);
compute_motion_compensation();
}
// 阶段4：环路滤波（计算密集，数据局部性好）
deblocking_filter();
frame_count++;
}
你看，这样一拆解，每个阶段的资源需求就清楚了。CPU、DMA、内存带宽，各自在什么时间点吃紧，一目了然。
3.3 特征化：把Trace变成数字
Trace采集完了，原始数据往往几GB甚至几十GB。你不能直接拿这些数据去建模型，得先做特征化。
特征化，说白了就是提取关键指标。我一般关注这几个维度：
| 维度 | 关键指标 | 说明 |
|---|---|---|
| 指令级 | IPC、分支预测率、L1 I-cache miss率 | 反映CPU微架构压力 |
| 内存级 | L2/L3 miss率、带宽利用率、平均访问延迟 | 反映存储子系统的瓶颈 |
| I/O级 | DMA传输大小、中断频率、外设等待时间 | 反映系统级交互开销 |
| 并行度 | 线程数、任务依赖深度、同步开销占比 | 反映多核扩展性 |
一个小技巧：特征化时，别只看平均值。峰值和P99值往往更能暴露问题。我记得有一次，平均带宽利用率只有40%，但P99值达到了95%——这说明大部分时间很闲，但偶尔会突然打满，导致卡顿。
3.4 知识体系：一张图看懂工作负载分析
下面这张图，是我自己总结的工作负载分析流程。每次做新项目，我都会先走一遍这个流程。
3.5 避坑指南
做工作负载分析这几年，我踩过的坑不少。挑几个典型的说说：
坑1：Trace数据太干净
我曾经用仿真器生成的trace建模型，结果模型跑出来性能特别好。一上真实硬件，直接打脸。为什么？因为仿真器没有模拟cache一致性开销、没有模拟中断延迟、没有模拟DDR刷新周期。所以，能用真实硬件trace就别用仿真trace，实在不行也要在模型里加上这些“脏”因素。
坑2：只关注一个场景
有个项目，我们只优化了视频播放场景，结果用户反馈说“切后台时卡死了”。因为切后台涉及进程切换、cache冲刷、DMA重新配置——这些在视频播放场景里根本不会出现。所以，场景一定要覆盖全面，尤其是边界场景。
坑3：特征化指标选太多
刚开始做特征化时，我恨不得把所有能统计的指标都列出来。结果数据量太大，反而找不到重点。后来我学乖了：先选3-5个核心指标，如果模型精度不够，再逐步增加。你想想看，指标多了，分析起来也费劲，对吧？
3.6 小结
工作负载分析，说白了就是回答三个问题：
- 芯片要跑什么？——场景提取
- 跑的时候发生了什么？——Trace采集
- 哪些指标最关键？——特征化
这三个问题搞清楚了，后面的性能建模才有意义。否则，模型再精确，也是空中楼阁。
我个人习惯，每次做完工作负载分析，都会把结果整理成一个“场景卡片”。卡片上写清楚场景名称、关键指标、典型trace片段、以及可能存在的瓶颈点。这样后续做架构设计时，随时可以翻出来对照。
嗯，今天就聊到这儿。下一章咱们会把这些分析结果，真正用到性能模型里去。