ARM架构Mac下C语言Double/Float/_Float16运算速度不符预期问题

原测试的核心缺陷 #

你得到的测试结果和预期不符，本质是测试方法存在多处问题，和硬件实际性能无关：

• 运算规模严重不足：100次循环的总运算量只有纳秒级，远低于clock()函数的统计精度阈值，最终得到的数值基本是函数调用、进程调度的随机误差，完全无法反映浮点运算本身的速度。
• 编译器优化完全抵消了测试逻辑：在常规发布优化等级（-O2/-O3）下，固定次数、固定输入的整数累加转浮点的逻辑会被编译器直接计算出最终结果，整个循环不会生成任何实际运行的运算指令，测到的耗时和浮点性能没有关联。
• 对ARM架构半精度运算的实现存在认知偏差：Apple Silicon所属的AArch64架构中，标量浮点运算单元原生支持float、double的硬件运算，但_Float16标量运算默认需要先转换为float完成计算，再截断回半精度存储，额外的格式转换开销会导致标量场景下_Float16运算比float更慢。半精度的性能优势仅存在于NEON向量并行运算场景——单条向量指令可以同时处理8个半精度值、4个单精度值、2个双精度值，此时才会出现半精度吞吐高于单精度、单精度高于双精度的情况。
• 不符合硬件实际性能表现：Apple Silicon的FPU对标量float和double的运算吞吐做了同等优化，小运算量下二者速度几乎没有差异是正常现象。

正确的性能测试方案 #

按照以下规则调整测试逻辑，才能得到可信的性能数据：

• 放大运算规模：将循环次数提升至1亿次以上，让总运算耗时达到秒级，抵消时钟统计、系统调度带来的误差。
• 规避无效优化：使用volatile修饰累加变量，或者在循环结束后将累加结果输出到标准IO，避免编译器将整个循环常量折叠；测试时使用常规发布优化等级（-O2），不要使用-O0（无优化等级会加入大量冗余指令，无法反映真实运行性能）。
• 替换高精度计时接口：macOS下使用clock_gettime(CLOCK_MONOTONIC, ...)替代clock()，可以获得纳秒级计时精度，减少统计误差。
• 区分测试场景：
  • 标量运算场景：直接使用基础类型逐元素计算，此时半精度没有性能优势、甚至更慢，float和double速度接近，都是符合硬件设计的正常结果。
  • 向量运算场景：引入<arm_neon.h>头文件，使用NEON向量intrinsics编写并行运算逻辑，此时才能观测到半精度的吞吐率优势。

修正后的标量测试参考代码 #

#include <stdio.h>
#include <time.h>
#include <stdint.h>

// 切换待测试的浮点类型
// typedef double FP;
// typedef float FP;
typedef _Float16 FP;

#define LOOP_CNT 100000000LL

int main(int argc, const char * argv[]) {
    struct timespec start, end;
    clock_gettime(CLOCK_MONOTONIC, &start);

    volatile FP acc = 0;
    for (int64_t i = 0; i < LOOP_CNT; i++) {
        acc += (FP)i;
    }

    clock_gettime(CLOCK_MONOTONIC, &end);
    double cost = (end.tv_sec - start.tv_sec) + (end.tv_nsec - start.tv_nsec) / 1e9;
    // 打印累加结果，避免循环被编译器优化删除
    printf("Accumulate result: %f, Time cost: %.6f s\n", (float)acc, cost);
    return 0;
}

如果要验证半精度的性能优势，可以基于NEON指令编写向量累加逻辑，此时单指令并行处理的元素数差异会直接体现在运算耗时上。

内容的提问来源于stack exchange，提问作者YUNBLACK