M1处理器下Numpy不同规模数组内积运行时异常慢的原因咨询

你的实验核心矛盾在于：数组规模从10^8扩大到109（10倍），内积耗时从0.1秒暴涨到57秒（570倍），远偏离线性增长，且反超随机数组生成耗时。核心原因是内存带宽与缓存命中率的瓶颈，结合M1架构和Numpy/BLAS的实现特性，具体拆解如下：

1. 数据规模突破缓存阈值，访存成为瓶颈 #

每个float64元素占8字节：

• 10^{8长度的数组：单个数组800MB，两个数组共1.6GB，虽远超M1的16MB片上统一缓存，但仍处于主内存带宽的高效利用区间——Numpy内积依赖的BLAS库可将数据分块，分批加载到缓存中计算，此时CPU的FP64计算能力能被充分利用，耗时接近线性增长（理论上10}9规模应约1秒）。
• 10^9长度的数组：单个数组8GB，两个数组共16GB，完全超出M1的内存容量上限（即使是16GB内存的M1机型，也会触发系统内存压缩/swap机制）。此时内积计算需持续从主内存（DRAM）读取数据，而DRAM带宽（M1约68GB/s）远低于缓存带宽（TB级），同时读取两个数组的数据流还会进一步挤占内存带宽，导致计算完全被访存速度限制。

2. 随机数生成与内积的操作特性差异 #

• 随机数生成：Numpy的np.random.rand基于PCG64算法，属于计算密集型操作，且是顺序写入内存——CPU可在生成随机数的流水线中，批量将结果写入内存，顺序写入的带宽利用率远高于双数据流读取，因此数据规模扩大10倍后，耗时仅从0.8秒涨到10.8秒（约13.5倍），接近线性增长。
• 内积计算：属于访存密集型操作，需要同时读取两个数组的对应元素做乘加累加。当数据无法放入缓存时，每次读取都要等待DRAM响应，乘加运算本身的耗时可忽略，整体性能完全由内存读取速度决定，这就是耗时陡增的核心原因。

3. M1架构的特殊影响 #

M1采用统一内存架构（CPU/GPU共享内存），当数组占满内存时，系统会启动内存压缩甚至磁盘swap，进一步加剧访存延迟。此外，M1的FP64计算单元数量少于FP32，在访存瓶颈下，原本有限的计算能力也无法被有效利用，双重因素导致性能暴跌。

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