第1章：硬件平台选型与评估
做嵌入式Linux回测性能优化，第一步就是选硬件。这事儿我踩过不少坑，今天跟你聊聊我的经验。
1.1 CPU架构对比：ARM vs RISC-V
先说说CPU架构。ARM和RISC-V，是目前嵌入式Linux回测领域的两大主力。
ARM架构，说白了就是成熟、稳定。我在项目中用过Cortex-A72、A76这些核心，生态非常完善。你想想看，Linux内核、GCC工具链、各种驱动，基本都优先支持ARM。我个人的习惯是，如果项目周期紧、团队经验不足，优先选ARM。
RISC-V架构，这几年火得不行。它最大的优势是开源、灵活。你可以自己定制指令集，去掉不需要的模块。我在一个AI推理项目中试过RISC-V，功耗控制确实比同级别的ARM好。但要注意，RISC-V的生态还在成长，有些外设驱动得自己写。
核心对比点：
- 性能密度：ARM在同等功耗下，单核性能通常高10%-15%
- 定制灵活性：RISC-V可以裁剪指令集，去掉浮点单元能省30%面积
- 工具链成熟度：ARM的DS-5、ARMCC很完善；RISC-V的GCC还在迭代
- 成本：ARM要交授权费，RISC-V完全免费
我曾经在一个回测项目中，因为选了RISC-V，结果发现某个数学库没有优化版本，性能差了40%。嗯，这里要注意：如果你的算法依赖特定指令集优化，先确认好生态支持情况。
1.2 内存子系统分析
内存子系统，是回测性能的命门。我见过太多项目，CPU算力很强，但内存带宽不够，结果性能被卡死。
内存层次结构：
- L1 Cache：通常32KB-64KB，访问延迟1-2个时钟周期
- L2 Cache：256KB-1MB，延迟10-20个时钟周期
- L3 Cache：2MB-8MB，延迟30-50个时钟周期
- DDR内存：几GB，延迟100-200个时钟周期
你看这个差距，L1和DDR差了100倍。所以优化内存访问模式，比优化CPU指令更有效。
我的经验：回测数据通常很大，建议用perf stat -e cache-misses先看看缓存命中率。如果低于90%，说明内存访问模式有问题。
举个例子，我优化过一个回测算法，原始代码是随机访问一个大数组：
// 不好的写法：随机访问
for (int i = 0; i < N; i++) {
int idx = random_index[i];
result += data[idx];
}改成顺序访问后，性能提升了3倍：
// 好的写法：顺序访问
for (int i = 0; i < N; i++) {
result += data[i];
}为什么会这样？因为顺序访问能充分利用Cache Line预取机制。说白了，CPU会猜你下一步要读哪里，提前把数据拉到缓存里。
1.3 I/O瓶颈识别
I/O瓶颈，是嵌入式回测系统里最容易被忽视的问题。我刚开始做优化时，总盯着CPU和内存，结果发现瓶颈在磁盘读写上。
常见的I/O瓶颈点：
- 磁盘读写速度：机械硬盘的随机读写只有几百KB/s，SSD能到几百MB/s
- 文件系统开销：ext4在大量小文件场景下性能下降明显
- 网络I/O：如果回测数据从网络加载，延迟和带宽都是瓶颈
- DMA传输：没有启用DMA时，CPU要参与每次数据传输
避坑指南：我曾经在一个项目中，用fread逐字节读取回测数据，结果I/O占用了80%的CPU时间。后来改用mmap内存映射，性能直接翻倍。
识别I/O瓶颈，我一般用这几个工具：
| 工具 | 用途 | 常用命令 |
|---|---|---|
| iostat | 查看磁盘I/O负载 | iostat -x 1 |
| iotop | 查看进程I/O使用 | iotop -o |
| strace | 跟踪系统调用 | strace -c -p PID |
| perf | 分析I/O事件 | perf stat -e block:* |
你想想看，如果iostat显示磁盘利用率超过80%，但CPU利用率只有20%，那基本可以断定是I/O瓶颈了。
1.4 知识体系总览
下面这张图，是我自己总结的硬件平台选型与评估的核心逻辑。你看一眼，心里就有数了。
这张图把三个核心模块串起来了。你从CPU架构开始选，然后评估内存子系统，最后排查I/O瓶颈。顺序很重要，我建议先做I/O分析，因为很多性能问题其实出在这里。
小技巧：选型时，可以先用lmbench跑一遍内存延迟测试，再用dd测磁盘吞吐。这两个数据拿到手，平台性能基本心里有数了。
好了，这一章就聊到这里。硬件选型是基础，基础打好了，后面的优化才能事半功倍。
公众号:蓝海资料掘金营，微信deep3321