为何减小NumPy数组规模反而会导致cumprod运算大幅变慢？

嘿，这个反直觉的现象确实挺有意思的，我来帮你捋清楚背后的门道！

先对齐下你的场景：你手里有个10^4 × 2^13（也就是10000行、8192列）的NumPy数组，元素都是贴近1.0的浮点值，用np.cumprod(axis=0)计算每列的累积乘积，耗时大概6.6秒。但你调整数组规模时发现——明明减小了数组总大小，运算速度反而大幅变慢？这背后的核心原因其实和CPU缓存的工作机制直接相关。

关键本质：CPU缓存命中率的“适配性”问题 #

NumPy默认采用**行优先（C风格）**的内存存储布局——简单说就是数组里每一行的元素在内存中是连续挨在一起的，而同一列的元素之间，间隔了整整一行的字节数（也就是n_columns × 每个元素的字节数）。

而cumprod(axis=0)是按列做累积运算，这意味着它需要反复读取同一列的下一个元素，每次读取都要跳过一整行的内存。当你的列数刚好是2^13=8192时，这个内存间隔刚好踩中了现代CPU缓存的“甜蜜点”：

• 对于float64类型的元素（每个占8字节），8192列对应的行宽度是8192×8=65536字节=64KB，这刚好是多数CPU L1缓存的单核心容量。当CPU读取某列的一个元素时，会把整个64KB的缓存块加载进来，后续读取该列的其他元素时，都能直接从缓存中获取，缓存命中率接近100%，运算效率自然拉满。

但如果你减小列数，比如降到2^12=4096，行宽度就变成了32KB，这时候缓存加载的块里，大部分都是当前列不需要的其他列元素，导致缓存命中率急剧下降——CPU不得不频繁从速度慢几十倍的主内存中读取数据，直接拖慢了运算速度。

验证猜想的小实验 #

你可以快速做两个测试来验证这个结论：

1. 转成列优先存储再运算：
   把数组改成列优先（Fortran风格）存储，让同一列的元素在内存中连续排列，彻底解决缓存适配问题：

   my_array_f = np.asfortranarray(my_array)
   %timeit np.cumprod(my_array_f, axis=0)
   

   这时候不管列数多少，运算速度都会明显提升，尤其是列数较小的场景。

2. 对比不同列数的耗时：
   分别测试列数为4096、8192、16384的情况，你会发现8192列的运算速度最快，前后的列数都会变慢——这就是缓存适配性带来的差异。

实用优化方案 #

如果你的业务需要调整数组规模，同时保持cumprod的运算效率，可以试试这几个方法：

• 强制列优先存储：创建数组时指定order='F'，或者用np.asfortranarray()转换现有数组，让按列运算的内存访问模式更友好。
• 用Numba加速自定义实现：Numba可以编译出适配内存布局的机器码，甚至利用CPU的向量化指令，比原生np.cumprod更灵活：

  from numba import jit
  
  @jit(nopython=True)
  def cumprod_by_col(arr):
      result = np.empty_like(arr)
      # 逐列计算累积乘积
      for col_idx in range(arr.shape[1]):
          result[0, col_idx] = arr[0, col_idx]
          for row_idx in range(1, arr.shape[0]):
              result[row_idx, col_idx] = result[row_idx-1, col_idx] * arr[row_idx, col_idx]
      return result
  
  %timeit cumprod_by_col(my_array)
  

• 分块运算：如果数组太大无法完全放入缓存，可以把列分成若干个64KB宽度的块，分块计算cumprod后再合并结果，最大化缓存利用率。

备注：内容来源于stack exchange，提问作者Mr. Jefferson's Ghost