运行了一个玩具性能示例后，我们现在将稍微偏离主题并将性能与
进行对比一些 python 实现。首先让我们设置计算阶段，并提供命令行
python 脚本的功能。
import argparseimport timeimport mathimport numpy as npimport osfrom numba import njitfrom joblib import parallel, delayedparser = 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 librariesprint("=" * 80)print( f"nstarting the benchmark for {args.arraysize} elements " f"using {args.workers} threads/workersn")# generate the data structures for the benchmarkarray0 = [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 joblibchunks = np.array_split(array1, args.workers) # split the array into chunksnumresults = parallel(n_jobs=args.workers)( delayed(compute_inplace_with_joblib)(chunk) for chunk in chunks )# process each chunk in a separate threadarray1 = np.concatenate(numresults) # concatenate the results
努巴
@njitdef compute_inplace_with_numba(array): np.sqrt(array,array) np.sin(array,array) np.cos(array,array) ## njit will compile this function to machine codecompute_inplace_with_numba(array_in_np_copy)
这是计时结果：
in place in ( base python): 11.42 secondsin place in (python joblib): 4.59 secondsin place in ( python numba): 2.62 secondsin place in ( python numpy): 0.92 seconds
numba 出奇的慢！？难道是由于 mohawk2 在 irc 交流中关于此问题指出的编译开销造成的吗？
为了测试这一点，我们应该在执行基准测试之前调用compute_inplace_with_numba一次。这样做表明 numba 现在比 numpy 更快。
in place in ( base python): 11.89 secondsin place in (python joblib): 4.42 secondsin place in ( python numpy): 0.93 secondsin place in ( python numba): 0.49 seconds
最后，我决定在同一个例子中使用 base r 来骑行：
n<-50000000x<-runif(n)start_time <- sys.time()result <- cos(sin(sqrt(x)))end_time <- sys.time()# calculate the time takentime_taken <- end_time - start_time# print the time takenprint(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 中使用数组的相同示例。最后一部分将（希望）提供有关内存局部性的影响以及使用动态类型语言所产生的开销的一些见解。
以上就是性能追求第二部分：Perl 与 Python的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1348448.html
微信扫一扫 
支付宝扫一扫 
