numpy ufuncs速度vs循环速度
我已经阅读了很多＆＃34;避免使用numpy＆＃34;的循环。所以，我试过了。我正在使用此代码（简化版）。一些辅助数据：
In[1]: import numpy as np
resolution = 1000 # this parameter varies
tim = np.linspace(-np.pi, np.pi, resolution)
prec = np.arange(1, resolution + 1)
prec = 2 * prec - 1
values = np.zeros_like(tim)
我的第一个实现是使用for循环：
In[2]: for i, ti in enumerate(tim):
values[i] = np.sum(np.sin(prec * ti))
然后，我摆脱了明确的for周期，并实现了这个目标：
In[3]: values = np.sum(np.sin(tim[:, np.newaxis] * prec), axis=1)
对于小型阵列来说这个解决方案更快，但是当我扩大规模时，我有这样的时间依赖性：
我缺少什么或是正常行为？如果不是，在哪里挖？
编辑：根据评论，这里有一些额外的信息。使用IPython的%timeit和%%timeit测量时间，每次运行都在新鲜内核上执行。我的笔记本电脑是 acer aspire v7-482pg（i7,8GB）。我正在使用：
- python 3.5.2
- numpy 1.11.2 + mkl
- Windows 10
1 个答案:
答案 0 :(得分：9)
这是正常和预期的行为。它太简单了，无法应用＆＃34;避免循环使用numpy＆＃34; 语句。如果你正在处理内循环，它（几乎）总是如此。但是在外环（例如你的情况下）的情况下，有更多例外。特别是如果替代方案是使用广播，因为这会通过使用更多内存来加速您的操作。
只需为＆＃34;添加一些背景，避免使用numpy＆＃34; 语句进行循环：
NumPy数组存储为具有c类型的连续数组。 Python int与C int不同！因此，无论何时迭代数组中的每个项目，都需要从数组中插入项目，将其转换为Python int然后执行任何操作，最后您可能需要将其转换为ac再次整数（称为装箱和拆箱值）。例如，您希望使用Python sum数组中的项目：
import numpy as np
arr = np.arange(1000)
%%timeit
acc = 0
for item in arr:
acc += item
# 1000 loops, best of 3: 478 µs per loop
你最好使用numpy：
%timeit np.sum(arr)
# 10000 loops, best of 3: 24.2 µs per loop
即使你将循环推送到Python C代码中，你也远离那些笨拙的表现：
%timeit sum(arr)
# 1000 loops, best of 3: 387 µs per loop
此规则可能有例外，但这些将非常稀疏。至少只要有一些等效的numpy功能。因此，如果你要迭代单个元素，那么你应该使用numpy。
有时普通的python循环就足够了。它没有广泛宣传，但与Python功能相比，numpy函数的开销很大。例如，考虑一个3元素数组：
arr = np.arange(3)
%timeit np.sum(arr)
%timeit sum(arr)
哪一个会更快？
解决方案：Python函数的性能优于numpy解决方案：
# 10000 loops, best of 3: 21.9 µs per loop <- numpy
# 100000 loops, best of 3: 6.27 µs per loop <- python
但这与你的例子有什么关系？事实并非如此，因为你总是在数组上使用numpy-functions（不是单个元素，甚至不是少数元素）所以你的内部循环已经使用了优化函数。这就是为什么两者表现大致相同（+/-因子10，元素很少，因子2，大约500元素）。但这不是真正的循环开销，而是函数调用开销！
您的循环解决方案
使用line-profiler和resolution = 100：
def fun_func(tim, prec, values):
for i, ti in enumerate(tim):
values[i] = np.sum(np.sin(prec * ti))
%lprun -f fun_func fun_func(tim, prec, values)
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 101 752 7.4 5.7 for i, ti in enumerate(tim):
3 100 12449 124.5 94.3 values[i] = np.sum(np.sin(prec * ti))
在循环中花费了95％，我甚至将循环体分成几个部分来验证这一点：
def fun_func(tim, prec, values):
for i, ti in enumerate(tim):
x = prec * ti
x = np.sin(x)
x = np.sum(x)
values[i] = x
%lprun -f fun_func fun_func(tim, prec, values)
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 101 609 6.0 3.5 for i, ti in enumerate(tim):
3 100 4521 45.2 26.3 x = prec * ti
4 100 4646 46.5 27.0 x = np.sin(x)
5 100 6731 67.3 39.1 x = np.sum(x)
6 100 714 7.1 4.1 values[i] = x
消费者的时间为np.multiply，np.sin，np.sum，您可以通过将每次通话的时间与其开销进行比较来轻松检查：
arr = np.ones(1, float)
%timeit np.sum(arr)
# 10000 loops, best of 3: 22.6 µs per loop
因此，一旦与计算运行时相比，计算函数调用开销很小，您就会有类似的运行时。即使有100件物品，你也会非常接近开销时间。诀窍是知道他们在哪个方面实现收支平衡。有1000个项目，呼叫开销仍然很重要：
%lprun -f fun_func fun_func(tim, prec, values)
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 1001 5864 5.9 2.4 for i, ti in enumerate(tim):
3 1000 42817 42.8 17.2 x = prec * ti
4 1000 119327 119.3 48.0 x = np.sin(x)
5 1000 73313 73.3 29.5 x = np.sum(x)
6 1000 7287 7.3 2.9 values[i] = x
但是对于resolution = 5000，与运行时相比，开销非常低：
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 5001 29412 5.9 0.9 for i, ti in enumerate(tim):
3 5000 388827 77.8 11.6 x = prec * ti
4 5000 2442460 488.5 73.2 x = np.sin(x)
5 5000 441337 88.3 13.2 x = np.sum(x)
6 5000 36187 7.2 1.1 values[i] = x
当你在每个np.sin电话中花费500us时，你不再关心20us的开销。
可能需要注意的是：line_profiler每行可能包含一些额外的开销，也可能是每个函数调用，因此函数调用开销变得可以忽略的点可能会更低!!! p>
您的广播解决方案
我首先分析了第一个解决方案，让我们对第二个解决方案做同样的事情：
def fun_func(tim, prec, values):
x = tim[:, np.newaxis]
x = x * prec
x = np.sin(x)
x = np.sum(x, axis=1)
return x
再次使用带有resolution=100的line_profiler：
%lprun -f fun_func fun_func(tim, prec, values)
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 1 27 27.0 0.5 x = tim[:, np.newaxis]
3 1 638 638.0 12.9 x = x * prec
4 1 3963 3963.0 79.9 x = np.sin(x)
5 1 326 326.0 6.6 x = np.sum(x, axis=1)
6 1 4 4.0 0.1 return x
这已经显着超过了开销时间，因此与循环相比，我们的速度提高了10倍。
我还对resolution=1000进行了分析：
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 1 28 28.0 0.0 x = tim[:, np.newaxis]
3 1 17716 17716.0 14.6 x = x * prec
4 1 91174 91174.0 75.3 x = np.sin(x)
5 1 12140 12140.0 10.0 x = np.sum(x, axis=1)
6 1 10 10.0 0.0 return x
和precision=5000：
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def fun_func(tim, prec, values):
2 1 34 34.0 0.0 x = tim[:, np.newaxis]
3 1 333685 333685.0 11.1 x = x * prec
4 1 2391812 2391812.0 79.6 x = np.sin(x)
5 1 280832 280832.0 9.3 x = np.sum(x, axis=1)
6 1 14 14.0 0.0 return x
1000大小仍然更快，但正如我们已经看到的那样，在循环解决方案中呼叫开销仍然是不可忽略的。但是对于resolution = 5000，每个步骤花费的时间几乎相同（有些慢一点，有些更快但总体上非常相似）
另一个影响是当你进行乘法时实际的广播变得很重要。即使有非常聪明的numpy解决方案，这仍然包括一些额外的计算。对于resolution=10000，您会看到广播乘法开始占用更多＆＃34;％时间＆＃34;与循环解决方案有关：
Line # Hits Time Per Hit % Time Line Contents
==============================================================
1 def broadcast_solution(tim, prec, values):
2 1 37 37.0 0.0 x = tim[:, np.newaxis]
3 1 1783345 1783345.0 13.9 x = x * prec
4 1 9879333 9879333.0 77.1 x = np.sin(x)
5 1 1153789 1153789.0 9.0 x = np.sum(x, axis=1)
6 1 11 11.0 0.0 return x
Line # Hits Time Per Hit % Time Line Contents
==============================================================
8 def loop_solution(tim, prec, values):
9 10001 62502 6.2 0.5 for i, ti in enumerate(tim):
10 10000 1287698 128.8 10.5 x = prec * ti
11 10000 9758633 975.9 79.7 x = np.sin(x)
12 10000 1058995 105.9 8.6 x = np.sum(x)
13 10000 75760 7.6 0.6 values[i] = x
但除了实际花费的时间之外还有另一件事：内存消耗。您的循环解决方案需要O(n)内存，因为您始终处理n个元素。然而，广播解决方案需要O(n*n)个内存。如果您在循环中使用resolution=20000，则可能需要等待一段时间，但仍然只需要8bytes/element * 20000 element ~= 160kB，但通过广播，您需要~3GB。这忽略了常数因素（如临时数组，即中间数组）！假设你走得更远，你的内存会很快耗尽！
再次总结这些观点的时间：
- 如果你对numpy数组中的单个项目执行python循环，那你就错了。
- 如果循环遍历numpy-array的子数组，请确保每个循环中的函数调用开销与函数中花费的时间相比可以忽略不计。
- 如果你播放numpy阵列，请确保你的内存不足。
但关于优化的最重要的一点仍然是：
-
如果代码太慢，只能优化代码！如果它太慢，那么只有在分析代码后才进行优化。
-
不要盲目地信任简化的陈述，而再次永远不会在没有分析的情况下进行优化。
最后一个想法：
如果cython或{{}中尚无现有解决方案，则可以使用numba，numexpr或numpy轻松实现需要循环或广播的此类功能3}}
例如，将来自循环解决方案的内存效率与低resolutions的广播解决方案的速度相结合的numba函数将如下所示：
from numba import njit
import math
@njit
def numba_solution(tim, prec, values):
size = tim.size
for i in range(size):
ti = tim[i]
x = 0
for j in range(size):
x += math.sin(prec[j] * ti)
values[i] = x
正如评论numexpr中所指出的，还可以非常快速地评估广播的计算，而不需要需要O(n*n)内存：
>>> import numexpr
>>> tim_2d = tim[:, np.newaxis]
>>> numexpr.evaluate('sum(sin(tim_2d * prec), axis=1)')
- 我写了这段代码，但我无法理解我的错误
- 我无法从一个代码实例的列表中删除 None 值，但我可以在另一个实例中。为什么它适用于一个细分市场而不适用于另一个细分市场？
- 是否有可能使 loadstring 不可能等于打印？卢阿
- java中的random.expovariate()
- Appscript 通过会议在 Google 日历中发送电子邮件和创建活动
- 为什么我的 Onclick 箭头功能在 React 中不起作用？
- 在此代码中是否有使用“this”的替代方法？
- 在 SQL Server 和 PostgreSQL 上查询，我如何从第一个表获得第二个表的可视化
- 每千个数字得到
- 更新了城市边界 KML 文件的来源？