两组对照实验：

第一组，选一个已经有人工适配过 RISC-V 的项目，把代码回退到适配前的状态，让 AI 重新做一遍，再和人工版本对比；市面上已有不少项目经过了移植，相关数据可查，因此不是本次实验重点关注的方向。

第二组，选一个完全没做过 RISC-V 适配的开源项目，直接把整个任务丢给 AI——我们这次实验的主角是 libwebp 库，就属于第二类。

为什么选 libwebp？

因为它是互联网上应用最广的图片编解码库之一，网页里大量图片（如 WebP 格式）就是由它处理的。这个库自带一套 x86 的 SSE2 向量优化代码——就是专门榨干 CPU 性能的那部分代码。把它搬到新架构上，既有代表性，又有挑战。

怎么判断“搬得好不好”？

我们搭了三种环境，分步测试：①原生 x86 平台、②QEMU 仿真的 RISC-V、③真实 RISC-V 硬件。

所有性能数据，统一用 CPU 周期数（cycles）来比，而不是墙上的毫秒。两块芯片主频差得很多，直接比“跑了多少毫秒”并不公平；周期数回答的是“完成同一件事，CPU 转了多少步”，用比值把频率差异剔除掉。前提列清楚了，实验结果才站得住脚。

第一轮，我们让 AI 完成 libwebp 解码路径里 7 个 SSE2 源文件到 RISC-V 向量指令（RVV）的迁移。这一步的目标只有一个：功能上完全等价。

覆盖范围如下：色度上采样、无损格式转换、Alpha 处理三个模块全量覆盖；反滤波、输出缩放、帧内预测等模块按实测收益分发，负收益的函数主动保留标量——这里没有为了“全向量化”而硬上向量处理。

这里多提一句 QEMU 的用途：它只是用来验证软件代码在不同向量位宽（VLEN）下都能正常跑，验证的是“兼容性”，不含性能评估；因为真实的性能，还是得上真机测试。

功能部分全对了，我们当时还挺高兴 —— 然而随后一测性能，我们又高兴不起来了：慢，而且慢很多！

第一轮跑通了，但性能却远低于预期。

我们把问题原样抛回给 AI：帮我看看，时间都花在哪里了？AI Agent 接下来做了一件工程师们最熟悉的事 —— 逐函数剖析，把整条解码链路拆开，看每一段到底消耗多少周期。然后给出诊断：哪些函数适合向量化、哪些向量化反而更慢；该向量化的向量化，该保留标量的保留标量。

经过一轮一轮迭代，性能开始往上走。

期间我们发现了一个反常识的小细节：编译器也会帮倒忙。连编译器自己的自动向量化，AI 也单独查了一遍——在 rv64gcv 参数下，GCC 15 的自动向量化默认是开着的，它会把迁移范围外的标量代码也“顺手”向量化：有些函数经过它这一“优化”，反而比纯标量还要慢（实测只有 0.92×、0.83×）；显式关掉后，才回到 1.09×、1.13×。

追查下去，原因也很反直觉：被自动向量化的主要是熵解码这类分支密集的标量路径——指令数确实少了 10.5%，周期数反而涨了 20.8%。因为在这类核上，向量指令并非“免费”：每条都有固定的启动拍数、短依赖链还要叠加延迟，而编译器的成本模型没有按这个真实开销校准，把自动向量化当成了“免费提速”，结果适得其反。三种构建输出 MD5 一致，说明这是纯性能问题，不是正确性问题。

处理方式其实简单：手写 RVV 在全部 7 张图上都是正收益，拖后腿的只是编译器的自动向量化——交付构建显式关掉它（-fno-tree-vectorize）即可。这件事也让我们看得更清楚：AI 不是无脑“开向量”，它会逐函数判断哪一步有正收益、哪一步帮倒忙；同时，RISC-V 的生态差距不只是硬件——工具链（比如编译器成本模型）同样需要时间，针对这类新核去校准。

但测试的故事还没完：我们拿它和 x86 平台的向量化效果对比，发现还是有一段距离。而 AI Agent 给了一个出乎意料的结论——这不是代码本身的问题。原因见 04 节。

把 7 张测试图的结果放在一起，每一行回答同一个问题：同一台机器上，向量化比纯标量快了多少？

在同等周期数下，RISC-V 平台向量化后的表现，和 x86 平台之间仍有 1.4~2.6 倍的周期差距。为什么？

AI Agent一路追查下去，把根因定位到了微架构层面——也就是说，问题出在芯片硬件本身的固有架构设计上，而不是代码写得不好。

AI 先把差距拆开看了一遍——同样的周期数，差距到底花在哪？拆完是两块：一块是天生串行的环节。比如熵解码（VP8 的算术解码、VP8L 的 Huffman 解码），每一步都要等前一步的结果，任何向量指令都插不上手，是“任何向量扩展都动不了”的部分——向量化之后，它仍然占整帧周期的 21%（实拍有损）到 73%（实拍无损），成了最大的 Amdahl 分母；而且 x86 平台上它同样没有 SIMD 实现（占 40%/80%），这不是 RISC-V 独有的短板。

另一块是小尺寸计算：反变换（IDCT）和帧内预测都是 4×4、16×16 的小块，向量指令有固定开销，硬上向量化反而更慢——这类函数 AI 主动保留标量实现，性能反而提升了。有损图里真正缩得多的是环路滤波（也只有垂直方向被向量化，水平方向实测负收益、保留标量）和上采样，向量化把该拿的收益都拿到了。

上图是实测报告第 2 页的原图：同一颗 RISC-V 芯片上，7 张测试图向量化前后的整帧时间构成——每组两根条，上为纯标量构建、下为手写 RVV 构建，条长=每帧周期数（Mcyc），颜色段=各解码模块占比。读图只需要看一件事：哪一段缩了，哪一段没缩。有损图里，环路滤波（橙）和上采样（粉）明显变短，向量化拿到的主要收益都在这里；而蓝色“熵解码/码流解析”段几乎纹丝不动——实拍 4K 有损那张，整帧从 408 Mcyc 降到 215 Mcyc，缩掉的部分主要来自橙色和粉色段。无损图更直观：深绿“逆预测”段缩到底之后，整帧剩下的几乎全是蓝色熵解码。

换句话说，向量化把能拿的收益都拿了；剩下拿不动的，正是熵解码这类天生串行的环节。但“动不了”到底是软件问题还是硬件问题？—— 不能靠猜。

AI Agent 做了一件更“较真”的事：自己写了一个微架构探针（valu_probe.c），把每一条候选向量指令放进 200 万次迭代的循环里，实测它在真实芯片上“一条指令要花几个周期”，数据按“实测规律 / 有证据推断 / 未验证”分级，板上一分钟就能复现。经过几轮实测结果，把疑问一个个确定了：

不过，看懂之后不是认命——有些差距，软件是可以“绕”过去的。比如水平方向滤波的跨步访存，代价按 VLMAX 槽位数走，我们就用分数 LMUL（让一条向量指令只占寄存器的几分之一）把 VLMAX 压到刚好等于要取的元素数，每字节代价直接减半——微基准上 5 个水平滤波函数已有 4 个转正（0.94×~1.28×），端到端收益正在真机上做最终确认。读懂了微架构，软件侧是能定向缩小差距的。

所以迁移不能照搬 x86 的优化套路：x86 上有效的向量写法，换一颗 RISC-V 芯片未必成立。正确的做法，是针对每款芯片的微架构特性定制优化策略，并把这些经验沉淀成为芯片的专属知识库；同时，软件的功能跑通只是第一步，迁移全部完成，还必须加上“性能达标”这一关。

有意思的是，这个结论反过来帮了我们：它让我们更清楚地“看懂”了 RISC-V 的芯片内部微架构——哪些瓶颈是软件能解决的，哪些该由芯片微架构设计去改进。一次迁移实验，意外地变成了我们CPU硬件设计的前期输入。

同样地，这些实验得到的真实数据，也为云帆迁移产品 YiMig 提供了可信的原始数据验证，可以引导我们如何去优化 YiMig 的性能。

这次实验里，AI Agent 覆盖了功能迁移、性能分析、瓶颈定位的全流程。和传统方式相比，最大的变化是：工程师从“逐行改代码”，变成了“定义问题、验收结果”，繁琐的体力活全部交给 AI Agent 去跑。

分工上，常规迁移以 AI 为主，绝大部分工作由 AI 独立完成；真正费劲的深度调优，也要由人和 AI 协同完成。还要强调一点：功能跑通不等于迁移完成——代码能在新架构上运行只是起点，后续仍要结合具体硬件的微架构做针对性调优，才算真正交付。

目前，云帆已经在持续迁移了一批常用软件，并把每次踩坑的经验沉淀进自进化知识库，越用越聪明。而且我们已经开始与国内几家云服务巨头进行紧密合作，帮助他们将那些非常常用的基线软件迁移到 RISC-V 平台服务器上。

RISC-V 生态的成熟，不只需要芯片算力突破，更需要应用软件的规模化迁移。当软件“搬家”从人肉翻译变成 AI 流水线，迁移门槛就被显著降下来了，RISC-V 软件生态的飞轮才能够真正转得起来。

说到底，芯片性能没达到，生态是建立不起来的；而软件迁移，正是让每一分硬件性能真正落到应用上的那座桥。这，就是我们做这次实验的意义。

如果您对 RISC‑V 软件迁移系统感兴趣，欢迎提交试用申请。

点击文末【阅读原文】或扫描文末二维码填写信息，我们将对申请进行评估，后续与您对接沟通。期待与运营商、政企、软件研发伙伴共同推进 RISC‑V 软件生态落地。