numpy.dot在这里代表BLAS矢量-矢量乘法，而numpy.sum使用成对求和例程，切换到块大小为128个元素的8x展开求和循环。
我不知道NumPy使用的是什么BLAS库，但据我所知，一个好的BLAS通常会利用SIMD操作，而numpy.sum不会这样做。numpy.sum代码中的任何SIMD使用都必须是编译器自动向量化，这可能比BLAS效率低。
当您将数组大小增加到100万个元素时，此时可能会达到缓存阈值。dot代码使用大约16 MB的数据，sum代码使用大约8 MB的数据。dot代码可能会将数据转移到较慢的缓存级别或RAM。或者dot和sum都使用较慢的缓存级别，而dot的性能较差，因为它需要读取更多的数据。与具有更高的每元件性能的X1 M10 N1 X相比，定时与某种阈值效应更一致。

此答案提供了更多详细信息，从而完善了@user2357112的正确答案。两个函数都经过优化。也就是说，成对求和通常速度稍慢，但通常提供更准确的结果。它也是次优的，但相对较好。Windows上默认使用的OpenBLAS不执行成对求和。
下面是Numpy代码的汇编代码：

下面是OpenBLAS代码的汇编代码：

Numpy代码的主要问题是它不使用AVX（256位SIMD指令集），而是使用SSE（128位SIMD指令集），这与OpenBLAS相反，至少在1.22.4（我使用的版本）及之前的版本中是这样。在Numpy代码中，指令是标量1！我们最近对此进行了研究，Numpy的最新版本现在应该使用AVX。也就是说，由于成对求和（特别是对于大数组），它可能仍然不如OpenBLAS快。

注意，两个函数都花费了不可忽略的时间在开销上，因为数组太小了。这样的开销可以使用Numba中的手写实现来消除。
如果阵列更长，则计时顺序相反。
这是意料之中的。实际上，当函数该高速缓存中操作时，它们是相当受计算限制的，但是当数组很大**并且适合L3缓存甚至RAM时，它们变成受内存限制的。因此，np.dot统计对于更大的数组会更慢，因为它需要从内存读取两倍大的数据。更具体地说，它需要从内存中读取8*1000000*2/1024**2 ~= 15.3 MiB，所以你可能需要从RAM中读取数据，而RAM的吞吐量非常有限。事实上，像我这样的好的双通道3200 MHz DDR4 RAM可以达到接近40 GiB和15.3/(40*1024) ~= 374 µs的实际吞吐量。也就是说，顺序代码很难完全饱和此吞吐量，因此顺序代码达到30 GiB/s已经很不错了，更不用说许多主流PC RAM在较低频率下运行。30 GHz/s吞吐量导致约500 µs，这与您的时序非常接近。同时，np.sum和np.add.reduce由于其低效率实现而更受计算限制，但是要读取的数据量小了两倍，并且实际上可以更好地适合具有显著更大吞吐量的L3高速缓存。
要证明此效果，您可以简单地尝试运行：

# L3 cache of 9 MiB

# 2 x 22.9 = 45.8 MiB
a = np.ones(3_000_000)
b = np.ones(3_000_000)
%timeit -n 100 np.dot(a, a)   #  494 µs => read from RAM
%timeit -n 100 np.dot(a, b)   # 1007 µs => read from RAM

# 2 x 7.6 = 15.2 MiB
a = np.ones(1_000_000)
b = np.ones(1_000_000)
%timeit -n 100 np.dot(a, a)   #  90 µs => read from the L3 cache
%timeit -n 100 np.dot(a, b)   # 283 µs => read from RAM

# 2 x 1.9 = 3.8 MiB
a = np.ones(250_000)
b = np.ones(250_000)
%timeit -n 100 np.dot(a, a)   # 40 µs => read from the L3 cache (quite compute-bound)
%timeit -n 100 np.dot(a, b)   # 46 µs => read from the L3 cache too (quite memory-bound)

在我的机器上，L3的大小只有9 MiB，因此第二次调用不仅需要读取两倍多的数据，而且从较慢的RAM读取的数据也比从L3缓存读取的数据多。

对于小型阵列，L1缓存速度很快，阅读数据应该不会成为瓶颈。在我的i5- 9600 KF机器上，L1缓存的吞吐量非常大：~268 GiB/s。这意味着读取两个大小为1000的数组的最佳时间是8*1000*2/(268*1024**3) ~= 0.056 µs。实际上，调用Numpy函数的开销要比这个大得多。

快速实施

下面是一个快速的Numba实现：

import numba as nb

# Function eagerly compiled only for 64-bit contiguous arrays
@nb.njit('float64(float64[::1],)', fastmath=True)
def fast_sum(arr):
    s = 0.0
    for i in range(arr.size):
        s += arr[i]
    return s

以下是性能结果：

array items |    time    |  speedup (dot/numba_seq)
--------------------------|------------------------
 3_000_000   |   870 µs   |   x0.57
 1_000_000   |   183 µs   |   x0.49
   250_000   |    29 µs   |   x1.38

如果你使用parallel=True和nb.prange而不是range，Numba将使用多线程，这对于大型数组很好，但对于某些机器上的小型数组可能不太好（由于创建线程和共享工作的开销）：

array items |    time    |  speedup (dot/numba_par)
--------------------------|--------------------------
 3_000_000   |   465 µs   |   x1.06
 1_000_000   |    66 µs   |   x1.36
   250_000   |    10 µs   |   x4.00

正如预期的那样，Numba对于小数组来说速度更快（因为Numpy调用开销基本上被消除了），并且在大数组方面可以与OpenBLAS竞争。

.LBB0_7:
        vaddpd  (%r9,%rdx,8), %ymm0, %ymm0
        vaddpd  32(%r9,%rdx,8), %ymm1, %ymm1
        vaddpd  64(%r9,%rdx,8), %ymm2, %ymm2
        vaddpd  96(%r9,%rdx,8), %ymm3, %ymm3
        vaddpd  128(%r9,%rdx,8), %ymm0, %ymm0
        vaddpd  160(%r9,%rdx,8), %ymm1, %ymm1
        vaddpd  192(%r9,%rdx,8), %ymm2, %ymm2
        vaddpd  224(%r9,%rdx,8), %ymm3, %ymm3
        vaddpd  256(%r9,%rdx,8), %ymm0, %ymm0
        vaddpd  288(%r9,%rdx,8), %ymm1, %ymm1
        vaddpd  320(%r9,%rdx,8), %ymm2, %ymm2
        vaddpd  352(%r9,%rdx,8), %ymm3, %ymm3
        vaddpd  384(%r9,%rdx,8), %ymm0, %ymm0
        vaddpd  416(%r9,%rdx,8), %ymm1, %ymm1
        vaddpd  448(%r9,%rdx,8), %ymm2, %ymm2
        vaddpd  480(%r9,%rdx,8), %ymm3, %ymm3
        addq    $64, %rdx
        addq    $-4, %r11
        jne     .LBB0_7

话虽如此，它并不是最佳的：LLVM-Lite JIT编译器使用4倍展开，而在我的Intel CoffeeLake处理器上，8倍展开应该是最佳的。实际上，vaddpd指令的延迟是4个周期，而每个周期可以执行2条指令，因此需要8个寄存器来避免延迟，并且生成的代码受到延迟限制。此外，该汇编代码在Intel Alderlake和Sapphire急流处理器上是最佳的，因为它们具有两倍低的vaddpd延迟。2饱和FMA SIMD处理单元远非易事。我认为编写更快函数的唯一方法是使用SIMD内部函数编写（C/C++）本机代码，尽管它的可移植性较差。
请注意，由于fastmath，Numba代码不支持NaN或Inf值等特殊数字（AFAIK OpenBLAS可以）。实际上，它应该仍然可以在x86-64机器上工作，但这并不能保证。此外，Numba代码对于非常大的数组来说在数值上是不稳定的。2 Numpy代码应该是三种变体中数值上最稳定的（然后是OpenBLAS代码）。你可以按块计算总和来提高数值稳定性，尽管这会使代码更加复杂。天下没有免费的午餐。