运行了一个玩具性能示例后，我们现在将稍微偏离主题并将性能与
进行对比
一些 python 实现。首先让我们设置计算阶段，并提供命令行
python 脚本的功能。
import argparse
import time
import math
import numpy as np
import os
from numba import njit
from joblib import parallel, delayed
parser = argparse.argumentparser()
parser.add_argument("--workers", type=int, default=8)
parser.add_argument("--arraysize", type=int, default=100_000_000)
args = parser.parse_args()
# set the number of threads to 1 for different libraries
print("=" * 80)
print(
f"\nstarting the benchmark for {args.arraysize} elements "
f"using {args.workers} threads/workers\n"
)
# generate the data structures for the benchmark
array0 = [np.random.rand() for _ in range(args.arraysize)]
array1 = array0.copy()
array2 = array0.copy()
array_in_np = np.array(array1)
array_in_np_copy = array_in_np.copy()
这是我们的参赛者：
- 基础python
for i in range(len(array0)):
array0[i] = math.cos(math.sin(math.sqrt(array0[i])))
- numpy（单线程）
np.sqrt(array_in_np, out=array_in_np) np.sin(array_in_np, out=array_in_np) np.cos(array_in_np, out=array_in_np)
- joblib（请注意，这个示例不是真正的就地示例，但我无法使用 out 参数使其运行）
def compute_inplace_with_joblib(chunk):
return np.cos(np.sin(np.sqrt(chunk))) #parallel function for joblib
chunks = np.array_split(array1, args.workers) # split the array into chunks
numresults = parallel(n_jobs=args.workers)(
delayed(compute_inplace_with_joblib)(chunk) for chunk in chunks
)# process each chunk in a separate thread
array1 = np.concatenate(numresults) # concatenate the results
- 努巴
@njit
def compute_inplace_with_numba(array):
np.sqrt(array,array)
np.sin(array,array)
np.cos(array,array)
## njit will compile this function to machine code
compute_inplace_with_numba(array_in_np_copy)
这是计时结果：
in place in ( base python): 11.42 seconds in place in (python joblib): 4.59 seconds in place in ( python numba): 2.62 seconds in place in ( python numpy): 0.92 seconds
numba 出奇的慢！？难道是由于 mohawk2 在 irc 交流中关于此问题指出的编译开销造成的吗？
为了测试这一点，我们应该在执行基准测试之前调用compute_inplace_with_numba一次。这样做表明 numba 现在比 numpy 更快。
in place in ( base python): 11.89 seconds in place in (python joblib): 4.42 seconds in place in ( python numpy): 0.93 seconds in place in ( python numba): 0.49 seconds最后，我决定在同一个例子中使用 base r 来骑行：
n<-50000000
x<-runif(n)
start_time <- sys.time()
result <- cos(sin(sqrt(x)))
end_time <- sys.time()
# calculate the time taken
time_taken <- end_time - start_time
# print the time taken
print(sprintf("time in base r: %.2f seconds", time_taken))
产生以下计时结果：
Time in base R: 1.30 seconds与 perl 结果相比，我们注意到此示例的以下内容：
- 基础 python 中的就地操作比 perl
- 慢约 3.5 单线程 pdl 和 numpy 给出了几乎相同的结果，紧随其后的是基础 r
- 未能考虑 numba 的编译开销会产生 错误
- 的印象，即它比 numpy 慢。考虑到编译开销，numba 比 numpy 快 2 倍 joblib 的并行化确实改进了基础 python，但仍然不如单线程 perl 实现
- 多线程 pdl（和 openmp）碾压（不是崩溃！）所有语言中的所有其他实现。 希望这个帖子 提供了一些值得思考的东西 用于下一次数据/计算密集型操作的语言。 本系列的下一部分将研究在 c 中使用数组的相同示例。最后一部分将（希望）提供有关内存局部性的影响以及使用动态类型语言所产生的开销的一些见解。
