RISC-V 数据移动模型：核心数何时失去意义

模型使用：

$$I_{\text{ridge}} = \frac{\text{Peak FLOP/s}}{\text{Effective Bandwidth}}$$

以及工作负载的算术强度 $I$。$I<I_{\text{ridge}}$ 时，数据移动是主约束。

默认实验

设置 0.5 TFLOPS、24 GB/s、算术强度 12 ops/byte。拐点约为：

$$0.5 \times 10^{12} / (24 \times 10^9) \approx 20.8$$

工作点低于拐点，说明继续增加核心或峰值算力收益有限，应优先提高片上复用和 DMA 效率。

为什么核心数会误导

如果每个核心都从同一共享内存取数，核心数增加会线性提高带宽需求。理想情况下，数据先在片上复用，再分发给核心；否则“更多小核”只是更快的排队。

打开 RISC-V Roofline 实验 调整模型工作集和算力利用率。把结果写入报告时，附上数据布局、缓存层级和 DMA 配置。

从单核到多核

单核模型的拐点是峰值算力除以有效带宽。多核时，若所有核心共享同一个内存控制器，总带宽不会随核心数线性增长。设核心数为 $N$、每核每个周期的数据需求为 $D$，则共享带宽需求近似为 $N \cdot D$。当需求超过可用带宽，增加核心只是让等待队列更长。

一个缓解办法是提高数据复用。矩阵乘的分块会让同一块权重服务于多个激活、同一块激活服务于多个输出。若复用因子为 $r$，从主存取回的字节可以近似减少到原来的 $1/r$。但分块会增加片上缓冲、边界处理和调度复杂度，复用因子不可能无限增长。

计算示例

假设有效带宽 24 GB/s、峰值算力 0.5 TFLOPS、工作负载算术强度 12 ops/byte。拐点为：

$$0.5 \times 10^{12} / (24 \times 10^9) \approx 20.8 \text{ ops/byte}$$

工作点低于拐点，说明该负载在理想峰值下也只能达到约一半的计算上限。若再考虑 55% 的算力利用率和 DMA 启动开销，实际吞吐会更低。这个结论不依赖某个具体板卡，而是由“每字节能做多少运算”决定。

如果把算术强度提高到 30 ops/byte，工作点越过拐点，瓶颈开始从带宽转向计算。此时增加向量宽度或提升 clock 才可能带来收益。要注意，算术强度不是模型固有的常数，它会随 tile 大小、batch、权重驻留和编译器融合而变化。

DMA 与流水线

DMA 的价值不是“比 CPU 搬得快”这么简单，而是让搬运与计算重叠。一个稳定的流水线需要：

1. 双缓冲或环形缓冲，避免计算等待下一块数据；
2. 明确的 cache 维护策略，防止 DMA 与 CPU 看到不同副本；
3. 中断或轮询的延迟上界；
4. 对总线仲裁和多个 DMA 通道的共享带宽建模；
5. 在最后一块数据到来前完成归约。

如果 DMA 只在前一块计算结束后启动，通信时间仍会串行叠加。若预取过深，缓冲区会挤占总 SRAM；若 cache line 与 DMA 传输粒度不对齐，还会出现额外读写。

如何报告结果

模型结果只是方向性估计，不能直接写“某芯片达到多少 TOPS”。报告至少应列出：

• 工作负载和形状；
• 峰值算力来源、频率与电压；
• 有效带宽测量方法；
• 算术强度的计算口径；
• 核心数、向量长度与缓存层级；
• 是否使用 DMA、双缓冲和融合；
• 模拟、仿真或实板证据等级。

同一模型在 batch=1、batch=16 和长上下文下可能有完全不同的瓶颈。端侧实时任务更关注尾延迟，而离线批处理更关注总吞吐；不能用同一个平均值同时证明两者。

设计结论

RISC-V 数据流优化的优先级通常是：先消除重复主存访问，再提高计算单元利用率，最后才增加核心或峰值。若工作集无法放入片上存储，先考虑模型分块、权重流式加载或量化；若同步开销超过计算，先减少全局归约和核间通信。

实验中的滑动参数可以帮助建立直觉，但最终决策必须来自目标工具链和板卡。把 Roofline、DMA trace、cache miss 和功耗曲线放在一起，才能解释“为什么快了”或“为什么没有快”。

复用因子与片上容量

若每个输出元素需要 $k$ 个输入元素，而片上只能容纳 $m$ 个，分块大小会影响复用。更大的 tile 减少主存访问，却增加 SRAM 压力和边界处理。设计者需要找到一个区间，使计算单元接近满载，同时避免 tile 溢出。

一个简单的二维卷积例子中，输入 tile 可能被多个输出通道复用，权重 tile 被多个空间位置复用。复用因子取决于循环顺序。把 batch、通道和空间维度放进不同循环层级，会产生不同的缓存命中模式。编译器是否自动选择正确顺序，取决于目标后端与模型形状。

多核同步的代价

归约和 softmax 需要跨核同步。同步不仅是 barrier 指令，还包括缓存刷新、消息传递和负载不平衡。若每个核心完成时间不同，最快核心会等待最慢核心。一个长尾任务可能把并行收益抵消。

在 many-tiny-core 平台，可以采用分层归约：先在簇内 SRAM 合并，再跨簇合并。这样减少全局通信，但增加中间缓冲和路由复杂度。实现时需要验证最坏同步延迟，而不只是平均吞吐。

从模型到可复现报告

一个可复现的 Roofline 报告应保存输入 JSON、公式版本、硬件参数和输出快照。若只保留截图，日后更换编译器或模型就无法重现结论。项目应把实验脚本、依赖版本和失败样例一起归档。

结论

核心数和峰值算力是配置项，不是结论。真正的结论是：“在给定算力、带宽、复用因子和同步成本下，哪个资源先饱和；提高哪一项能带来可测收益。”没有这条因果链，所谓优化只是参数堆砌。