OpenBLAS在RISC-V平台上的DGEMM与NRM2实现问题分析

问题背景

OpenBLAS作为一个高性能线性代数计算库，在RISC-V架构上的适配工作一直备受关注。近期在Sophgo sg2042处理器（基于RISC-V rv64imafdc架构，支持RVV 0.71向量扩展）上发现了一些计算精度问题，这些问题主要涉及DGEMM（双精度通用矩阵乘法）和NRM2（向量2-范数）两个核心运算的实现。

问题现象

在RevyOS系统上使用特定版本的THead GCC 10.4编译器编译OpenBLAS 0.3.26版本时，测试套件中出现了两个关键问题：

1. DGEMM测试失败：kernel_regress测试中的skx_avx测试项（实际测试的是DGEMM功能）出现数值精度不匹配，预期值为0但实际得到2.719e+04的大误差。

2. NRM2实现问题：在kernel/riscv64/nrm2_vector.c文件中发现的实现问题，导致计算结果不准确。

技术分析

DGEMM问题

DGEMM作为BLAS中最核心的矩阵运算之一，其实现质量直接影响整个线性代数计算的准确性。在RISC-V平台上，这个问题可能源于：

1. 编译器优化问题：不同版本的GCC编译器（如10.2与10.4）可能对向量指令的生成策略不同，导致数值计算结果的差异。

2. 硬件特性差异：实际硬件与QEMU模拟器在浮点运算处理上可能存在细微差别，特别是在涉及非规格化数或舍入模式时。

3. 向量扩展实现：RVV 0.71向量扩展在不同实现中可能存在行为差异，影响SIMD加速的DGEMM计算结果。

NRM2问题

NRM2计算向量的欧几里得范数，其实现需要考虑：

1. 数值稳定性：避免大数吃小数的问题，通常需要使用缩放技术。

2. 向量化实现：如何高效利用RVV向量指令进行平方和累加。

3. 特殊值处理：对NaN、Inf等特殊值的正确处理。

解决方案

对于DGEMM问题，已在后续版本中得到修复。而NRM2问题的解决可能需要：

1. 算法优化：重新设计数值稳定的实现方案，可能采用Kahan求和或pairwise summation等技术。

2. 编译器适配：针对特定版本的GCC编译器进行调整，确保生成的向量指令符合预期。

3. 硬件特性适配：充分考虑实际硬件的浮点运算特性，进行针对性优化。

经验总结

RISC-V生态的发展带来了新的机遇和挑战：

1. 编译器版本敏感性：不同版本的RISC-V工具链可能导致数值计算结果差异，需要充分测试。

2. 硬件实现多样性：不同厂商的RISC-V处理器在浮点单元和向量扩展实现上可能存在差异。

3. 测试覆盖必要性：除了QEMU模拟测试外，真实硬件测试不可或缺。

这些问题提醒我们，在将高性能数值计算库移植到新兴架构时，需要特别关注数值稳定性、编译器兼容性和硬件特性适配等关键因素。