定点运算为何未表现出比浮点运算更低的延迟？

你的测试结果中int、short和float的耗时差异很小，核心原因是测试场景受内存带宽瓶颈主导，而非计算单元性能，再加上编译选项和硬件架构的特性，导致定点运算的理论优势无法体现。具体分析如下：

1. 测试属于内存密集型，计算开销被内存访问掩盖 #

你的测试逻辑是对1000万元素的数组做c[i] = a[i] * b[i] + a[i]运算，每个迭代都需要从内存读取两个元素、写入一个结果。现代x86_64 CPU的计算单元（整数/浮点）速度远快于内存读取速度，所以整个测试的耗时主要由内存读写的延迟和带宽决定，而非运算本身：

• short数组体积为1000万 * 2字节 = 20MB，int和float数组为40MB，short耗时略低是因为数据量小、缓存命中率更高；int和float数据量相同，因此耗时接近。

2. -O0编译完全屏蔽了硬件优化 #

你使用-O0编译，编译器会生成无任何优化的代码：

• 不会启用SIMD指令（如SSE/AVX），这类指令可一次处理多个float或int/short元素，大幅提升计算吞吐量；
• 不会做循环展开、寄存器分配优化，代码逐行执行，进一步放大内存访问的主导地位。
  在这种情况下，计算单元的性能差异完全被内存开销掩盖。

3. short运算存在隐式类型提升 #

x86架构的通用寄存器是32/64位的，short类型的运算会被编译器隐式提升为int类型执行，计算完成后再截断回short。也就是说，short的运算并没有真正使用16位运算单元，而是和int一样使用32位整数单元，只是多了一步截断操作——这步操作开销极小，在内存瓶颈下完全无法体现。

4. 现代CPU的浮点单元性能已接近整数单元 #

现代x86 CPU的浮点运算单元（FPU）经过多年优化，单精度float的运算延迟和吞吐量已经和整数单元非常接近。在内存密集型场景下，这点细微的计算差异完全被内存访问的耗时覆盖。

优化建议 #

如果想要验证定点运算的性能优势，可以调整测试方案：

• 改为计算密集型测试：将loopSize设为1000甚至更高，或者在循环内增加更多运算（比如多次乘加），让计算开销成为耗时的主导因素；
• 启用编译器优化：使用-O2或-O3编译，让编译器生成SIMD优化代码，此时CPU的并行计算能力会被激活，定点和浮点的性能差异会更明显；
• 适配缓存大小：将数组大小调整为刚好能放进L1/L2缓存（比如几KB到几十KB），避免内存带宽瓶颈，让计算延迟的差异体现出来。

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