使用NumPy对uint16与uint64数组求和无速度提升是什么原因？

这个现象是NumPy默认实现的优化策略、编译选项限制，以及硬件层面的指令优先级共同导致的，具体原因如下：

1. NumPy默认实现的优化倾向 #

• 首先，NumPy对整数求和默认会做类型提升：比如uint16、uint32类型的数组求和时，会先把每个元素扩展为64位整数后再累加，避免溢出问题，这一步类型转换本身就抵消了小整数运算的理论优势。这也能对应你测试结果中uint64求和耗时明显低于uint16、uint32的现象——uint64不需要做类型扩展，直接累加即可。
• 绝大多数默认渠道分发的NumPy（比如pip官方源、系统自带的NumPy）都是兼容性优先的通用构建，不会启用针对特定CPU的高级整数SIMD指令（比如AVX2、AVX512的16位/32位整数向量加法指令），你设想的单指令完成多组整数加法的逻辑根本没有被触发。
• 而浮点数求和的优化在NumPy中优先级更高，通用构建默认就会启用SSE/AVX层级的浮点SIMD向量化，甚至会采用多累加器打散依赖链、FMA融合指令等优化手段，浮点运算的吞吐量被拉满，自然比没有做对应优化的整数求和更快。

2. 硬件层面的特性影响 #

• 主流x86架构CPU的浮点运算单元和整数运算单元是独立的，大部分消费级CPU的浮点SIMD吞吐量并不弱于整数SIMD，部分型号甚至浮点加法的吞吐比同宽度整数加法更高。
• 你的测试数据量很小（10000个元素完全可以塞进L1缓存），小整数内存占用更小的优势完全没有体现，运算瓶颈完全在运算单元的吞吐和指令优化程度上，自然看不到小整数的性能收益。

你可以尝试以下方法验证小整数的理论性能优势：

• 改用针对特定CPU指令集优化的NumPy发行版，比如conda-forge渠道编译的NumPy，或者手动编译时开启-march=native参数启用当前CPU支持的所有指令集，重新测试即可看到整数求和的性能提升。
• 用Numba手动实现针对uint16的向量化求和，手动启用SIMD优化后，uint16的求和速度会明显快于64位浮点求和。

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