Python 向量化计算的本质优势

NumPy 的 np.dot 更快是因为绕过 Python 解释器的类型检查、内存寻址和对象引用开销，直接在连续内存上执行 BLAS 级别点积，而非逐元素解释执行。

为什么 NumPy 的 np.dot 比 Python 循环快几十倍

根本原因不是“底层用 C 写的”这么笼统——而是它绕过了 Python 解释器对每个元素的类型检查、内存寻址和对象引用开销。循环里每次 a[i] * b[i] 都要查 a 是不是 list、i 是不是 int、乘完结果要不要新分配 float 对象；而 np.dot 一次性告诉 CPU：“按这块连续内存里的 float64，做 BLAS 级别的向量点积”，中间不经过 Python 字节码。

实操建议：

• 别用 for i in range(len(arr)): 做逐元素计算，哪怕只是加个标量——改用 arr + 5
• 遇到嵌套循环（比如手动实现矩阵乘），先查 NumPy 是否有对应函数：np.matmul、np.einsum、@ 运算符
• 如果必须写循环，且数组很大，考虑用 Numba 的 @njit 编译，但注意它不支持任意 Python 对象（如 dict、str）

np.vectorize 并不加速，只是语法糖

很多人误以为加了 np.vectorize 就自动向量化——其实它只是把你的 Python 函数包装成“看起来能广播”的接口，底层仍是 for 循环调用原函数，甚至比手写循环还慢，因为多了额外的参数分发和 dtype 推断开销。

常见错误现象：

• 用 np.vectorize(my_custom_func) 处理百万级数组，耗时反而比纯 Python 列表推导式更长
• 函数里用了 print 或 logging，结果发现每元素都打印一次——证明它真在挨个调用

真正该做的：

• 把逻辑拆成 NumPy 原生操作：比如想对每个数取 log 后平方，写 np.log(x) ** 2，而不是封装 lambda x: np.log(x)**2 再 vectorize
• 实在无法避免自定义逻辑（比如分段函数），优先用 np.where 或布尔索引：result = np.where(x > 0, np.sqrt(x), x * 2)

广播（broadcasting）不是免费的，但比显式循环便宜得多

广播本身不复制内存，但它需要实时计算每个轴的步长（stride）和元素偏移。小数组几乎无感，但高维张量（比如 (1, 512, 512) 和 (3, 1, 1) 相加）会触发多层嵌套索引计算——这时如果能提前 reshape 成兼容形状，性能可能提升 10%~20%。

使用场景与建议：

• 做图像批处理时，别让模型输入是 (batch, h, w, 3) 而均值是 (3,)——显式 reshape 成 (1, 1, 1, 3)，避免运行时反复推导广播规则
• 用 np.broadcast_arrays 预检两个数组是否可广播，避免在循环里反复触发 ValueError: operands could not be broadcast together
• 广播遇上 np.nan 要小心：np.array([1, np.nan]) + 0

  

  得到 [1., nan]，但若广播后某路径没触发计算，NaN 可能意外消失（尤其配合 np.any/np.all）

GPU 加速不是“换库就行”，得看数据搬运成本

用 CuPy 或 PyTorch 把数组搬到 GPU 上跑 cp.dot，只在计算远大于 PCIe 带宽延迟时才划算。比如单次矩阵乘 (2048×2048)，GPU 显著快；但对 (100×100) 数组做 1000 次小 dot，频繁 Host↔Device 搬运反而拖垮整体。

关键判断点：

• 用 time.perf_counter() 分别测纯 CPU 计算、数据上传、GPU 计算、数据下载四段耗时——如果上传+下载 > 计算本身，就别上 GPU
• CuPy 的 cp.asarray 不拷贝内存，但首次调用时会隐式同步，容易误判为“启动慢”；建议预热：cp.ones((10,10)); cp.cuda.Stream.null.synchronize()
• 混合精度（cp.float16）在 GPU 上快，但在 CPU 上可能因强制转 float32 反而更慢，别盲目降精度

实际项目里最常被忽略的，是向量化前的数据组织方式——比如把列存 CSV 用 pandas.read_csv 默认读成 object 类型的列，后续所有 .values 转 NumPy 都带类型转换开销；直接指定 dtype 或用 polars 读，才能让向量化真正落地。