关键词： RISC-V Vector Intrinsic、Code Migration、Benchmark、Large Language Model、Intrinsic Code
- VecIntrinBench: Benchmarking Cross-Architecture Intrinsic Code Migration for RISC-V Vector
- https://arxiv.org/pdf/2511.18867
- https://github.com/hanliutong/VecIntrinBench
本文针对 RISC-V 向量（RVV）扩展的算法库迁移需求，提出首个支持 RVV 内在函数的跨架构迁移基准测试 VecIntrinBench。现有基准测试聚焦主流 SIMD 内在函数，缺乏对 RVV 的支持，难以评估相关迁移方法效果。
VecIntrinBench 基准包含 50 个源自 NCNN、Libjpeg-Turbo 等开源库的函数级任务，涵盖标量、RVV、Arm Neon 及 x86 内在函数实现，并配套完整的功能（Google Test 驱动）与性能（Google Benchmark 驱动）测试。
图 1：Arm Neon 内联函数代码迁移至 RVV 的示例
通过对比规则基方法（neon2rvv）与 6 种主流 LLM 的迁移效果，发现先进 LLM 在 10 次尝试内迁移通过率比规则基方法高 20%， 且性能更优，更少出现严重性能退化。但 LLM 存在 RVV 内在函数调用不规范、硬件语义理解不足等问题。
VecIntrinBench 已开源（https://github.com/hanliutong/VecIntrinBench），为 RVV 迁移研究提供统一评估标准。研究还指出未来可通过引入反馈机制、构建专用训练数据集、融合两种方法等方向优化迁移效果，助力 RISC-V 软件生态发展。
关键问题
问题一：VecIntrinBench 基准场景覆盖完整性争议与 LLM 工业级迁移能力高估风险
论文提出的 VecIntrinBench 包含 50 个源自 3 个开源库的任务，但其是否覆盖了 RVV 迁移中最核心的高难度场景（如向量长度无关性 VLA 适配、跨架构特殊指令语义映射、多精度数据类型转换等）？若存在场景遗漏，基于该基准得出的 “LLM 通过率比规则基高 20%” 的结论，是否会高估 LLM 在工业级复杂算法库迁移中的实际能力？
VecIntrinBench 的 50 个任务源自 NCNN、Libjpeg-Turbo、OpenCV 等真实高性能开源库，覆盖了跨架构内在函数迁移的典型场景，但未明确宣称覆盖所有 RVV 迁移核心高难度场景。论文在分析 LLM 迁移失败原因时提到，LLM 在向量长度无关性（VLA）、舍入模式等架构差异显著的特征上存在语义等价性保持困难的问题，说明基准中已包含部分此类高难度任务，但无法确认是否穷尽所有核心场景（如多精度数据类型转换的极端情况）。
关于结论是否高估 LLM 工业级能力：
- 一方面，基准任务均为社区专家编写的真实工业级函数，实验结论具有一定代表性；
- 另一方面，工业级算法库的迁移场景更复杂（如大规模代码依赖、定制化优化逻辑），而 VecIntrinBench 聚焦函数级独立任务，且 LLM 在基准中仍存在 RVV 内在函数调用不规范、硬件语义理解不足等问题，因此在未扩展至更复杂场景前，“LLM 通过率比规则基高 20%”的结论【可能】存在一定程度的场景局限性，但论文通过开源基准为后续扩展评估提供了基础，可通过补充高难度场景任务进一步验证。
问题二：LLM 迁移缺陷本质溯源与工业级场景下成本-收益平衡质疑
论文指出 LLM 迁移存在 RVV 内在函数调用不规范、硬件语义理解不足的核心缺陷，且其使用成本高于规则基方法 —— 那么该缺陷的本质是模型缺乏 RVV 专属训练数据，还是现有 prompt 工程无法引导模型捕捉架构底层差异？ 此外，在工业级大规模迁移场景中，LLM 的算力消耗、推理延迟与规则基方法的差距是否会抵消其 20% 的通过率优势，导致实际落地可行性不足？
-
LLM 缺陷的本质更倾向于缺乏 RVV 专属训练数据与领域知识，而非单纯 prompt 工程不足：论文明确指出 LLM 的核心问题是 对 RVV 内在函数 API 规范理解不准确（如生成不存在的函数、参数类型错误），以及对底层硬件语义差异（如 VLA、舍入模式）缺乏深度认知。实验中已采用适合代码任务的温度参数（0.2）和明确迁移指令，prompt 设计具备合理性，但仍【未解决】核心缺陷，说明根源在于现有 LLM 的 训练数据中 RVV 相关内在函数与硬件特性知识覆盖不足，导致模型难以捕捉架构底层差异。
-
工业级大规模迁移场景中，LLM 的算力消耗与推理延迟【可能】削弱其通过率优势：论文明确提到 LLM-based 方法的使用成本高于规则基方法，但未量化算力与延迟差距。从工业落地角度看，大规模算法库迁移需处理海量函数，LLM 的多轮尝试（实验中 k=10 时达到最优通过率）会带来显著的算力开销与时间成本，而规则基方法（如 neon2rvv）为确定性映射，效率更高。若 LLM 的算力消耗与延迟【无法】通过优化（如模型压缩、RAG 增强）降低，其 20%的通过率优势可能被工程落地成本抵消，导致实际可行性不足，这也是论文提出“融合 LLM 与规则基方法”的核心动因之一。
一、引言
现代处理器通常会集成专用电路，以利用数据级并行性加速计算密集型操作。在指令集架构层面，这体现为各类单指令多数据或向量扩展指令集，例如英特尔 x86 架构的 SSE、AVX/AVX2/AVX-512 指令集[1]、Arm 架构的 Neon[2]与 SVE[3]指令集，以及新兴的 RISC-V 架构的向量扩展指令集[4]。
为充分发挥这种专用硬件的加速能力，程序必须采用特定于平台的汇编指令。但直接编写汇编代码难度极大，因此许多程序员会使用现代编译器提供的 SIMD/向量内联函数，在高级语言（通常是 C/C++）中实现显式向量化算法，再由编译器生成对应的平台专用汇编指令。
众多高性能计算库（如 OpenCV[5]、Libjpeg-Turbo[6]、OpenBLAS[7]、PyTorch/Eigen[8,9]和 NCNN[10]）均采用这种方法，以实现跨平台性能优化。然而，这些指令集各具特色，且拥有独特的内联函数，这就要求同一算法的高性能库需包含多个基于内联函数的向量化实现，才能确保在不同平台上的性能表现。
这种情况给开发和维护带来了巨大挑战，尤其当新指令集架构（如 RISC-V）试图通过移植大量高性能库中的向量化算法来拓展软件生态时，挑战更为突出。参考现有架构在算法库中的内联函数实现，是减少人工工作量的有效途径，因此内联函数代码的直接迁移已成为当前的研究热点。图 1 展示了一个以 RISC-V 向量扩展为目标的代码迁移示例。
图 1：Arm Neon 内联函数代码迁移至 RVV 的示例
尽管该领域的研究仍处于早期阶段，但已有研究人员通过 sse2rvv[11]、neon2rvv[12]等内联函数迁移工具，探索了基于规则的迁移方法的可行性。然而，由于缺乏包含 RVV 内联函数的全面基准测试集，这些工具的实际效果尚未得到充分评估。
大型语言模型在代码生成方面展现出卓越能力。LLM-Vectorizor[13]和 VecTrans[14]可将标量 C 代码转换为向量化内联函数代码，充分证明了 LLM 在生成和迁移内联函数代码方面的潜力。但目前仍缺乏用于评估此类迁移质量的基准测试集。
现有的向量化基准测试集（如 ParVec[15]、LLaMeSIMD[16]）未包含新兴的 RVV 内联函数，无法用于评估面向 RISC-V 架构的迁移能力。最近，He 等人提出了首个用于 SIMD 内联函数代码生成的基准测试集 SimdBench[17]，该测试集提供了任务描述、标量 C 解决方案以及正确性和性能测试，并对主流 LLM 进行了系统性评估。但该研究聚焦于从标量 C 生成内联函数代码，而非不同内联函数之间的代码迁移，因此未包含迁移任务所需的源内联函数代码。
为填补这一空白，本文提出了 VecIntrinBench——首个专门针对 RVV 指令集内联函数代码迁移的基准测试集。该测试集包含 50 个来自高性能库的用例，由社区专家编写，覆盖 RISC-V、Arm 和 x86 架构的内联函数代码，并配备了全面的正确性和性能测试，可用于实际评估 RVV 内联函数代码的迁移质量。
我们利用该基准测试集，对基于规则和基于 LLM 的内联函数代码迁移方法进行了评估。结果表明，基于 LLM 的方法在正确性和性能上均优于基于规则的方法。但由于 LLM 对 RVV 硬件特性和内联函数规范[18]的理解尚不完整，其方法仍存在局限性。这些发现为内联函数代码迁移的未来发展提供了指导，有助于推动 RISC-V 软件生态的持续发展。VecIntrinBench 已开源。
二、基准测试集构建
VecIntrinBench 是一个用于评估跨架构向量内联函数迁移的基准测试集，也是首个包含 RVV 内联函数的测试集，涵盖 50 个来自实际应用的用例。如第 2 节图所示的示例用例，每个用例均包含特定算法的实现，并附带正确性和性能测试。
在代码实现方面，50 个用例均包含标量 C++版本、RVV 内联函数版本和 Arm Neon 内联函数版本，部分用例还提供了 x86 内联函数版本。这些用例均从开源仓库中收集而来。
图 2：VecIntrinBench 中一个用例的整体结构
为筛选包含 RVV 内联函数代码的仓库，我们在 GitHub 上搜索包含#include <riscv_vector.h>和__riscv_v关键字的代码。从搜索结果中，我们筛选出 NCNN、Libjpeg-Turbo 和 OpenCV 库中支持多平台（含 RVV）实现的函数，将其纳入基准测试集，并为这些函数补充了正确性和性能测试。每个用例的来源及内联函数实现详情如表 1 所示。
表 1：VecIntrinBench 中的用例来源
每个用例的标量实现和内联函数实现采用统一的函数定义，只需在编译时替换源文件，即可轻松切换不同版本。这种设计便于评估不同实现的正确性和性能。由于所有代码均来自开源社区中人工专家的实现，因此代码质量通常具有较高保障。不过，在构建 VecIntrinBench 时，Libjpeg-Turbo 仓库中的 RVV 内联函数代码仍处于审核阶段。
- 正确性测试基于 Google Test 框架，通过将生成代码的执行结果与预期值或标量参考实现的输出进行对比，验证代码正确性。正确性测试用例通常包含预定义的边界情况和在有效范围内随机生成的输入，以确保对被测函数进行全面评估。将被测函数的编译目标文件与正确性测试用例链接为可执行文件后，即可评估生成函数的正确性。通常，只有当生成的代码能够成功编译、执行并通过所有测试用例时，才认为其正确。
- 性能测试基于 Google Benchmark 框架，可生成不同规模的输入数据用于性能评估。为确保结果的准确性和可靠性，每个性能测试用例需执行 100 次迭代，并重复该过程 3 次，最终记录被测函数的平均执行时间。
我们采用 pass@k 指标和加速比，分别评估代码迁移方法的有效性和迁移后代码的性能。
其中，pass@k 指标由 OpenAI 定义，用于评估 LLM 的问题解决能力。
* 在 k 个生成的代码候选中，若至少有一个通过所有测试用例，则认为该问题已解决；
* pass@k 得分即已解决问题所占的比例。在 VecIntrinBench 中，pass@k 反映了迁移方法在 k 次尝试中能够正确处理的 50 个任务的百分比。
加速比是评估向量化代码性能的常用指标。在 VecIntrinBench 中，对于每个编译通过且验证正确的代码，我们以人工编写的原生内联函数代码的执行时间为基准，衡量其性能表现；所得加速比用于评估有效迁移代码的优化质量。对于用例 i 的迁移任务，加速比越接近 1.0 倍，表明迁移代码的性能越接近人工专家实现的性能；加速比也可能超过 1.0 倍，这是因为受开发者实现能力等因素影响，开源仓库中的代码未必是最优的，先进的迁移方法有可能超越人工专家编写的向量化实现。
三、评估
为研究不同代码迁移方法向 RVV 内联函数的跨架构移植能力，我们在 VecIntrinBench 上开展了实验，评估从 Arm Neon 内联函数到 RVV 内联函数的迁移效果。
* 在基于规则的代码映射方法方面，我们选择了开源方案 neon2rvv；
* 在基于 LLM 的方法方面，我们选取了 6 个主流 LLM，其名称、标识和推理能力如表 2 所示。
表 2：在 VecIntrinBench 上评估的 LLM
实验中，我们将温度参数（temperature）设置为 0.2（该值适用于代码相关任务），其他参数均采用默认设置。对于 VecIntrinBench 中的每个用例，我们将其 Arm Neon 实现作为输入提供给 LLM，并通过提示词（prompt）指示 LLM 将其迁移为 RVV 内联函数。
迁移后的代码使用 RISC-V 的 GNU 工具链编译，编译选项设为-O3（开启高级优化）。对于编译成功的用例，我们使用 QEMU 模拟器评估其正确性，以确保生成的 RVV 内联函数代码有效。对于通过正确性测试的用例，我们在支持向量扩展的 RISC-V 设备——SpacemiT MUSE Pi（VLEN 为 256 位）上进行性能评估。
图 3：不同 k 值下代码迁移方法的有效性（y 轴为 pass@k 值，x 轴为 k 值）
结果显示：
* 当 k 从 1 增加到 8 时，pass@k 指标呈显著上升趋势，这表明当前先进的 LLM 在有限次数的尝试内，通常能够找到至少一种可行的迁移方案；
* 当 k 大于 8 时，pass@k 趋于稳定，意味着增加代码迁移尝试次数对提升代码迁移通过率的帮助不大。
在提示词引导下，不同 LLM 能正确迁移 VecIntrinBench 中 36%~88%的用例，且具备推理能力的模型在 pass@k 指标上具有显著优势。相比之下，基于规则的 neon2rvv 库仅成功迁移了 VecIntrinBench 中 52%的任务（50 个任务中迁移成功 26 个）。
表 3 基于 LLM 的迁移方法的迁移结果
我们对这些用例进行了详细分析，并将失败原因分类整理如表 3 所示。结果发现：迁移失败的最主要原因是 RVV 内联函数使用错误，包括生成 RVV 内联函数规范中不存在的函数，以及使用错误的函数参数类型。这些错误表明，LLM 对 RVV 内联函数 API 规范的理解不够准确，且存在系统性偏差，尤其在向量类型及其相关数据宽度方面。
部分任务失败还源于未通过正确性测试或其他原因。这表明，在代码迁移过程中保持语义等价（即迁移后代码与原代码功能完全一致）仍是 LLM 面临的挑战，尤其是在处理架构差异显著的特性（如向量长度无关性、舍入模式）时，挑战更为突出。
我们进一步研究了迁移代码与人工专家编写代码的性能差异。总体而言，基于 LLM 的迁移方法性能优于基于规则的方法。
图 4：通过测试的向量内联函数代码的性能加速比分布
如图 4 所示的加速比分布，基于 LLM 的方法表现更优。图中不同颜色代表不同的性能结果：
* 橙色：迁移代码性能显著低于原生代码；
* 黄色：加速比在 0.5~0.9 之间，表明迁移代码仍有优化空间（可能是因为 RVV 内联函数代码从其他架构的向量化实现迁移而来，未能充分利用 RVV 的特定硬件特性和向量寄存器资源）；
* 绿色和蓝色：迁移代码性能优于原生代码（可能是因为原生代码质量并非最优）；
* 灰色：迁移代码性能与原生代码接近。
与基于规则的方法（neon2rvv）相比，基于 LLM 的方法使性能严重下降（橙色）的用例数量更少，而_达到相近或更优性能（灰色、绿色、蓝色）的用例数量更多。_
四、讨论与结论
通过对比基于大型语言模型（LLM）的方法与基于规则的方法，我们发现：基于规则的代码映射技术能够部分实现面向 RISC-V 向量扩展（RVV）的跨架构 intrinsic 代码迁移。但该类方法仍需专业开发人员进一步弥补指令映射规则中的架构差异，以提升易用性与性能表现。
基于大型语言模型的方法在 intrinsic 代码迁移领域展现出巨大潜力——当前先进的大型语言模型已在性能上超越基于规则的方法。然而，这类方法的使用成本更高，同时还面临以下挑战：
1. 对目标 intrinsic 的调用可能偏离正式规范。由于现代编译器可提供修改建议，构建具备错误反馈机制的代码迁移智能体（agent）将有助于解决这一问题。
2. 对底层硬件的语义差异缺乏深度理解。为此，未来的改进应着重提升模型学习领域特定知识的能力。
我们认为，未来在以下方向开展工作将有助于推动 intrinsic 代码迁移技术的发展：
1. 在代码迁移过程中引入反馈机制与检索增强生成（RAG，Retrieval-Augmented Generation）技术，提供额外信息以帮助大型语言模型减少错误的 RVV intrinsic 调用。
2. 构建包含 RVV 与其他架构 intrinsic 的训练数据集。这些数据可用于对大型语言模型进行微调，使其能更好地适配 RVV 代码迁移任务。
3. 探索基于大型语言模型的方法与基于规则的方法的融合路径。
* Intrinsic 映射规则可为大型语言模型提供有力参考，从而解决函数调用错误这一核心问题；
* 反过来，大型语言模型的代码生成能力又能弥补人工编写映射规则覆盖范围不足的缺陷，并改善因缺乏优化导致的性能问题。
综上，我们提出了 VecIntrinBench——首个包含 RVV 扩展的开源 intrinsic 代码基准测试集，该测试集包含 50 个代码迁移任务。我们在 VecIntrinBench 上开展了代码迁移实验，对基于规则的方法与基于大型语言模型的方法的正确性和性能进行了评估。
评估结果表明：使用先进推理模型的基于大型语言模型的方法，在不超过 10 次尝试的情况下，迁移通过率比基于规则的方法高出 20%，且性能表现显著更优。通过分析，我们明确了当前代码迁移领域存在的关键挑战，并概述了未来发展的若干潜在方向。
参考文献
关注“鲸栖”小程序，掌握最新AI资讯
本文由鲸栖原创发布，未经许可，请勿转载。转载请注明出处：http://www.itsolotime.com/archives/13927