为什么与使用 np.int16 的相同操作相比，使用 dtype np.int64 的操作要慢得多？答案

【问题标题】：why operations with dtype np.int64 are much slower compared to same operations with np.int16?为什么与使用 np.int16 的相同操作相比，使用 dtype np.int64 的操作要慢得多？
【发布时间】：2019-06-09 20:39:02
【问题描述】：

这就是我的意思 - a 是 1.000.000 np.int64 元素的向量，b 是 1.000.000 np.int16 元素的向量：

In [19]: a = np.random.randint(100, size=(10**6), dtype="int64")

In [20]: b = np.random.randint(100, size=(10**6), dtype="int16")

不同操作的时间安排：

In [23]: %timeit a + 1
4.48 ms ± 253 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [24]: %timeit b + 1
1.37 ms ± 14.3 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [25]: %timeit a / 10
5.77 ms ± 31.6 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [26]: %timeit b / 10
6.09 ms ± 70.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [27]: %timeit a * 10
4.52 ms ± 198 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [28]: %timeit b * 10
1.52 ms ± 12.6 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

当 Numpy 必须在内存中创建新的临时结果时，我可以理解这种差异 - 底层 C 代码必须在内存中复制/填充更多数据。

但我无法理解在适当位置分配值的这种差异，如下所示：

In [21]: %timeit a[::2] = 111
409 µs ± 19 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

In [22]: %timeit b[::2] = 111
203 µs ± 112 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)

您知道为什么即使对于那些 Numpy 不必创建副本/视图的操作，它的速度也会变慢吗？

【问题讨论】：

您是否意识到您必须使用更大的 dtype 写入更多数据？
@user2357112，真丢人！谢谢！ :-)
我不知道，但也许那些非常简单和同类的操作是 SIMD 加速的？在那种情况下，我的理解是 int16 每条指令的数据点数实际上是 int64 的 4 倍。
@PaulPanzer：很有可能； numpy 是为高性能数字运算而编写的，简单的矢量化将是一个明显的优化。也就是说，除非阵列适合处理器缓存，否则我不希望看到它产生太大影响。 RAM 太慢了，无法以足够快的速度为 CPU 提供足够的资源。
@PaulPanzer：如果a 小到可以放入缓存中，那么矢量化就很重要。如果不是，耸耸肩，没有明显的想法。我怀疑一个实现弱点，可能与cumsum 具有多种操作模式有关，如果内联处理，而不是通过不同的代码路径，可能会减慢速度。您需要一个带有符号和分析的构建。

标签： python performance numpy

【解决方案1】：

从内存中读取会花费一些东西。写入内存需要付出一些代价。您正在读取四倍的数据，并写入四倍的数据，并且工作比读取/写入内存要快得多，以至于它实际上是 I/O 绑定的。 CPU 只是比内存快（而且速度比随着时间的推移变得越来越极端）；如果您正在执行内存密集型工作，较小的变量会运行得更快。

【讨论】：