分配给数组时Numba慢吗？
Posted
技术标签:
【中文标题】分配给数组时Numba慢吗？【英文标题】：Numba slow when assigning to an array? 【发布时间】：2013-08-06 22:26:01 【问题描述】：Numba 似乎是加速数字代码执行的绝佳解决方案。但是，当对数组进行赋值时，Numba 似乎比标准 Python 代码慢。考虑这个例子，比较四个替代方案，有/没有 Numba，写入一个数组/标量：
（故意将计算保持非常简单，以专注于问题，即分配给标量与分配给数组单元格）
@autojit
def fast_sum_arr(arr):
z = arr.copy()
M = len(arr)
for i in range(M):
z[i] += arr[i]
return z
def sum_arr(arr):
z = arr.copy()
M = len(arr)
for i in range(M):
z[i] += arr[i]
return z
@autojit
def fast_sum_sclr(arr):
z = 0
M = len(arr)
for i in range(M):
z += arr[i]
return z
def sum_sclr(arr):
z = 0
M = len(arr)
for i in range(M):
z += arr[i]
return z
使用 IPython 的 %timeit 评估我得到的四个备选方案：
In [125]: %timeit fast_sum_arr(arr)
100 loops, best of 3: 10.8 ms per loop
In [126]: %timeit sum_arr(arr)
100 loops, best of 3: 4.11 ms per loop
In [127]: %timeit fast_sum_sclr(arr)
100000 loops, best of 3: 10 us per loop
In [128]: %timeit sum_sclr(arr)
100 loops, best of 3: 2.93 ms per loop
sum_arr，不是用 Numba 编译的，比用 Numba 编译的 fast_sum_arr 快两倍多。另一方面，用 Numba 编译的 fast_sum_sclr 比没有用 Numba 编译的 sum_sclr 快两个数量级以上。
所以 Numba 在加速 sum_sclr 的任务上表现得非常好，但实际上使 sum_arr 执行得更慢。 sum_sclr 和 sum_arr 之间的唯一区别是前者分配给标量，而后者分配给数组单元。
不知道有没有关系，不过最近在博客http://www.phi-node.com/看到了以下内容：
“事实证明，当 Numba 遇到它不直接支持的任何构造时，它会切换到（非常）慢的代码路径。”
博客作者使用 if 语句而不是 Python 的 max() 让 Numba 执行得更快。
对此有何见解？
谢谢，
FS
【问题讨论】：
我不明白你的循环应该做什么。这不是有效的z[1:] += arr[1:]，还是因为z 和r 具有相同的值，z[1:] *= 2？我希望这比任何显式循环都快得多，但我不一定希望编译器能够分辨出来。
【参考方案1】：
这里慢的是 arr.copy() 函数，而不是对数组的写访问。证明：
# -*- coding: utf-8 -*-
from numba import autojit
from Timer import Timer
import numpy as np
@autojit
def fast_sum_arr(arr, z):
#z = arr.copy()
M = len(arr)
for i in range(M):
z[i] += arr[i]
return z
def sum_arr(arr, z):
#z = arr.copy()
M = len(arr)
for i in range(M):
z[i] += arr[i]
return z
@autojit
def fast_sum_sclr(arr):
z = 0
M = len(arr)
for i in range(M):
z += arr[i]
return z
def sum_sclr(arr):
z = 0
M = len(arr)
for i in range(M):
z += arr[i]
return z
if __name__ == '__main__':
vec1 = np.ones(1000)
z = vec1.copy()
with Timer() as t0:
for i in range(10000):
pass
print "time for empty loop ", t0.secs
print
with Timer() as t1:
for i in range(10000):
sum_arr(vec1, z)
print "time for sum_arr [µs]: ", (t1.secs-t0.secs) / 10000 * 1e6
with Timer() as t1:
for i in range(10000):
fast_sum_arr(vec1, z)
print "time for fast_sum_arr [µs]: ", (t1.secs-t0.secs) / 10000 * 1e6
with Timer() as t1:
for i in range(10000):
sum_sclr(vec1)
print "time for sum_arr [µs]: ", (t1.secs-t0.secs) / 10000 * 1e6
with Timer() as t1:
for i in range(10000):
fast_sum_sclr(vec1)
print "time for fast_sum_arr [µs]: ", (t1.secs-t0.secs) / 10000 * 1e6
"""
time for empty loop 0.000312089920044
time for sum_arr [µs]: 432.02688694
time for fast_sum_arr [µs]: 7.43598937988
time for sum_arr [µs]: 284.574580193
time for fast_sum_arr [µs]: 5.74610233307
"""
【讨论】：
视错觉。这更快的事实取决于 numba 使用延迟初始化的事实。第一次在同一会话中调用该函数时速度很慢，然后从第二次到第 10000 次时速度更快。因此第一个较慢，平均消失。尝试使用 1 而不是 10000 来调用它，并尝试在函数内部使用 copy 来调用它。你会看到 copy() 的位置不是瓶颈。【参考方案2】：我对 numba 知之甚少，但如果我们对它在幕后所做的事情做出一些基本假设，我们可以推断为什么 autojit 版本较慢以及如何通过微小的更改来加快它的速度...
让我们从 sum_arr 开始，
1 def sum_arr(arr):
2 z = arr.copy()
3 M = len(arr)
4 for i in range(M):
5 z[i] += arr[i]
6
7 return z
很清楚这里发生了什么，但让我们选择可以重写为的第 5 行
1 a = arr[i]
2 b = z[i]
3 c = a + b
4 z[i] = c
Python 将进一步改变这一点
1 a = arr.__getitem__(i)
2 b = arr.__getitem__(i)
3 c = a.__add__(b)
4 z.__setitem__(i, c)
a,b 和 c 都是 numpy.int64（或类似）的实例
我怀疑 numba 正在尝试检查这些项目的日期类型并将它们转换为一些 numba 本机数据类型（我看到的 numpy 代码最大的减速之一是无意中从 python 数据类型切换到 numpy 数据类型）。如果这确实发生了，numba 至少进行 3 次转换，2 次 numpy.int64 -> 本机，1 次本机 -> numpy.int64，或者中间体可能更糟（numpy.int64 -> python int -> 本机（c诠释））。我怀疑 numba 会在检查数据类型时增加额外的开销，可能根本不会优化循环。让我们看看如果我们从循环中移除类型更改会发生什么......
1 @autojit
2 def fast_sum_arr2(arr):
3 z = arr.tolist()
4 M = len(arr)
5 for i in range(M):
6 z[i] += arr[i]
7
8 return numpy.array(z)
第 3 行的细微变化是 tolist 而不是 copy，将数据类型更改为 Python ints，但我们仍然在第 6 行有一个 numpy.int64 -> native。让我们将其重写为 z[i] += z[我]
1 @autojit
2 def fast_sum_arr3(arr):
3 z = arr.tolist()
4 M = len(arr)
5 for i in range(M):
6 z[i] += z[i]
7
8 return numpy.array(z)
通过所有更改，我们看到了相当可观的加速（尽管它不一定能击败纯 python）。当然，arr+arr，就是傻得快。
1 import numpy
2 from numba import autojit
3
4 def sum_arr(arr):
5 z = arr.copy()
6 M = len(arr)
7 for i in range(M):
8 z[i] += arr[i]
9
10 return z
11
12 @autojit
13 def fast_sum_arr(arr):
14 z = arr.copy()
15 M = len(arr)
16 for i in range(M):
17 z[i] += arr[i]
18
19 return z
20
21 def sum_arr2(arr):
22 z = arr.tolist()
23 M = len(arr)
24 for i in range(M):
25 z[i] += arr[i]
26
27 return numpy.array(z)
28
29 @autojit
30 def fast_sum_arr2(arr):
31 z = arr.tolist()
32 M = len(arr)
33 for i in range(M):
34 z[i] += arr[i]
35
36 return numpy.array(z)
37
38 def sum_arr3(arr):
39 z = arr.tolist()
40 M = len(arr)
41 for i in range(M):
42 z[i] += z[i]
43
44 return numpy.array(z)
45
46 @autojit
47 def fast_sum_arr3(arr):
48 z = arr.tolist()
49 M = len(arr)
50 for i in range(M):
51 z[i] += z[i]
52
53 return numpy.array(z)
54
55 def sum_arr4(arr):
56 return arr+arr
57
58 @autojit
59 def fast_sum_arr4(arr):
60 return arr+arr
61
62 arr = numpy.arange(1000)
还有时间，
In [1]: %timeit sum_arr(arr)
10000 loops, best of 3: 129 us per loop
In [2]: %timeit sum_arr2(arr)
1000 loops, best of 3: 232 us per loop
In [3]: %timeit sum_arr3(arr)
10000 loops, best of 3: 51.8 us per loop
In [4]: %timeit sum_arr4(arr)
100000 loops, best of 3: 3.68 us per loop
In [5]: %timeit fast_sum_arr(arr)
1000 loops, best of 3: 216 us per loop
In [6]: %timeit fast_sum_arr2(arr)
10000 loops, best of 3: 65.6 us per loop
In [7]: %timeit fast_sum_arr3(arr)
10000 loops, best of 3: 56.5 us per loop
In [8]: %timeit fast_sum_arr4(arr)
100000 loops, best of 3: 2.03 us per loop
【讨论】：
有趣的见解。在我的测试中，我得到了 有趣的见解。在我的测试中，未编译的函数仍然优于已编译的函数。差异不是很显着。标量情况 (fast_sum_sclr) 和向量情况 (fast_sum_arrX) 中的加速度之间的显着差异仍未得到解释。【参考方案3】：是的，Numba 使用延迟初始化，所以第二次调用它会更快。 对于大型数组，尽管延迟初始化，numba 仍然比 no-numba 好。
尝试以下取消注释不同的 b
import time
import numpy as np
from numba import jit, autojit
@autojit
def fast_sum_arr(arr):
z = arr.copy()
M = len(arr)
for i in range(M):
z[i] += arr[i]
return z
def sum_arr(arr):
z = arr.copy()
M = len(arr)
for i in range(M):
z[i] += arr[i]
return z
@autojit
def fast_sum_sclr(arr):
z = 0
M = len(arr)
for i in range(M):
z += arr[i]
return z
def sum_sclr(arr):
z = 0
M = len(arr)
for i in range(M):
z += arr[i]
return z
b = np.arange(100)
# b = np.arange(1000000)
# b = np.arange(100000000)
print('Vector of len \n'.format(len(b)))
print('Sum ARR:\n')
time1 = time.time()
sum_arr(b)
time2 = time.time()
print('No numba: '.format(time2 - time1))
time1 = time.time()
fast_sum_arr(b)
time2 = time.time()
print('Numba first time: '.format(time2 - time1))
time1 = time.time()
fast_sum_arr(b)
time2 = time.time()
print('Numba second time: '.format(time2 - time1))
print('\nSum SCLR:\n')
time1 = time.time()
sum_sclr(b)
time2 = time.time()
print('No numba: '.format(time2 - time1))
time1 = time.time()
fast_sum_sclr(b)
time2 = time.time()
print('Numba first time: '.format(time2 - time1))
time1 = time.time()
fast_sum_sclr(b)
time2 = time.time()
print('Numba second time: '.format(time2 - time1))
在我使用 python 3 的系统上，numba 0.34.0 得到
"""
Vector of len 100
Sum ARR:
No numba: 7.414817810058594e-05
Numba first time: 0.07130813598632812
Numba second time: 3.814697265625e-06
Sum SCLR:
No numba: 2.6941299438476562e-05
Numba first time: 0.05761408805847168
Numba second time: 1.4066696166992188e-05
"""
和
"""
Vector of len 1000000
Sum ARR:
No numba: 0.3144559860229492
Numba first time: 0.07181787490844727
Numba second time: 0.0014197826385498047
Sum SCLR:
No numba: 0.15929198265075684
Numba first time: 0.05956888198852539
Numba second time: 0.00037789344787597656
"""
和
"""
Vector of len 100000000
Sum ARR:
No numba: 30.345629930496216
Numba first time: 0.7232880592346191
Numba second time: 0.586756706237793
Sum SCLR:
No numba: 16.271318912506104
Numba first time: 0.11036324501037598
Numba second time: 0.06010794639587402
"""
有趣的是，第一次调用和第二次调用之间的计算时间差异随着数组大小的增加而减小。不过，我不知道它为什么会这样工作。
【讨论】：
以上是关于分配给数组时Numba慢吗？的主要内容，如果未能解决你的问题，请参考以下文章