Julia性能与Python+Numba LLVM/jit编译的cod相比

Question

到目前为止，我看到的Julia的性能基准测试，比如at http://julialang.org/，将Julia与纯Python或Python+numy进行比较。与NumPy不同，SciPy使用BLAS和LAPACK库，在这些库中我们可以获得最佳的多线程SIMD实现。如果我们假设Julia和Python在调用BLAS和LAPACK函数时的性能是相同的（在幕后），那么当对不调用BLAS或LAPACK函数的代码使用Numba或NumbaPro时，Julia的性能与CPython相比如何？在

我注意到的一点是Julia使用的是llvmv3.3，而Numba使用的是llvm3.5上构建的llvmlite。Julia的旧LLVM是否会阻止在新体系结构（如Intel Haswell（AVX2指令））上实现最佳SIMD？在

我对意大利面代码和处理非常大向量的小DSP循环的性能比较感兴趣。对于我来说，由于在GPU设备内存中移动数据的开销，CPU比GPU更有效地处理后者。我只对单个Intel Core-i7 CPU的性能感兴趣，所以集群性能对我来说并不重要。我特别感兴趣的是创建DSP函数的并行实现的容易和成功。在

这个问题的第二部分是比较Numba和NumbaPro（忽略MKL BLAS）。给定NumbaPro的target="parallel"参数，NumbaPro的nogil参数真的需要吗？在

Answer 1

这是一个非常宽泛的问题。关于基准测试请求，您最好自己运行一些符合自己需求的小基准测试。要回答其中一个问题：

One thing I notice is that Julia is using LLVM v3.3, while Numba uses llvmlite, which is built on LLVM v3.5. Does Julia's old LLVM prevent an optimum SIMD implementation on newer architectures, such as Intel Haswell (AVX2 instructions)?

[2017/01+:以下信息不再适用于当前的Julia版本]

Julia确实关闭了llvm3.3的avx2，因为Haswell上有一些很深的bug。

Julia是用llvm3.3构建的，用于当前的发行版和晚间新闻，但是您可以使用3.5、3.6，通常是svn trunk（如果我们还没有为某一天的API更改进行更新，请提交一个问题）。为此，请在Make.user中设置LLVM_VER=svn（例如），然后继续按照构建说明进行操作。在

Answer 2

（比较不可比总是一把双面剑。在

以下是一个公平的信念，即如果任何衍生的结论可以作为合理支持的决策的基础，那么应该将LLVM/JIT支持的代码基准与其他一些LLVM/JIT支持的替代方案进行比较。）

---

简介：^{（numba资料和[us]结果在页面下方略低）}

恕我直言，julia-lang官方网站提供了一组性能测试的列表，其中陈述了两类事实。第一个与性能测试的执行方式有关（julia使用LLVM编译的代码执行v/s python，剩下的是GIL步骤的解释代码执行）。第二，使用C编译的代码执行作为相对时间单位=1.0，其他语言完成相同的“基准测试任务”需要多长时间

The chapter header, above a Table with results, says(cit.:)

High-Performance JIT Compiler
Julia’s LLVM-based just-in-time (JIT) compiler combined with the language’s design allow it to approach and often match the performance of C.


I thought a bit more rigorous to compare apples to apples and took just one of the "benchmark-task"-s, called the pi-sum.

这是解释过的python的第二糟糕时期，显示运行速度比LLVM/JIT编译的julia代码或C编译的替代代码慢21.99倍。在

于是小实验开始了。在

@numba.jit( JulSUM, nogil = True )：

Let's start to compare apples to apples. If julia code is reported to run 22x faster, let's first measure a plain interpreted python code run.

>>> def JulSUM():
...     sum = 0.
...     j   = 0
...     while j < 500:
...           j   += 1
...           sum  = 0.
...           k    = 0
...           while k < 10000:
...                 k   += 1
...                 sum += 1. / ( k * k )
...     return sum
...
>>> from zmq import Stopwatch
>>> aClk = Stopwatch()
>>> aClk.start();_=JulSUM();aClk.stop()
1271963L
1270088L
1279277L
1277371L
1279390L
1274231L

所以，pi-sum的核心大约是1.27x.xxx[us]~1.27~1.28[s]

考虑到julia-lang网站上的table row for ^{} in language presentation，LLVM/JIT支持的julia代码执行速度应该快22倍，即在~57.92[ms]

^{pr2}$

So, let's convert oranges to apples, using numba.jit ( v24.0 )

>>> import numba
>>> JIT_JulSUM = numba.jit( JulSUM )
>>> aClk.start();_=JIT_JulSUM();aClk.stop()
1175206L
>>> aClk.start();_=JIT_JulSUM();aClk.stop()
35512L
37193L
37312L
35756L
34710L

So, after JIT-compiler has made it's job, numba-LLVM'ed python exhibits benchmark times somewhere about 34.7 ~ 37.3 [ms]

我们能走得更远吗？在

当然，我们还没有做太多的numba调整，虽然代码示例如此微不足道，但在未来的道路上，预计不会出现太多令人惊讶的进步。在

首先，让我们去掉这里不必要的GIL步骤：

>>> JIT_NOGIL_JulSUM = numba.jit( JulSUM, nogil = True )
>>> aClk.start();_=JIT_NOGIL_JulSUM();aClk.stop()
85795L
>>> aClk.start();_=JIT_NOGIL_JulSUM();aClk.stop()
35526L
35509L
34720L
35906L
35506L

nogil=True
does not bring the execution much farther,
but still shaves a few [ms] more, driving all results under ~ 35.9 [ms]

>>> JIT_NOGIL_NOPYTHON_JulSUM = numba.jit( JulSUM, nogil = True, nopython = True )
>>> aClk.start();_=JIT_NOGIL_NOPYTHON_JulSUM();aClk.stop()
84429L
>>> aClk.start();_=JIT_NOGIL_NOPYTHON_JulSUM();aClk.stop()
35779L
35753L
35515L
35758L
35585L
35859L

nopython=True
does just a final polishing touch
to get all results consistently under ~ 35.86 [ms] ( vs. ~57.92 [ms] for LLVM/JIT-julia )

---

DSP处理尾声：

关于加速DSP处理的其他好处的OP问题，
您可以尝试测试numba+Intel Python（通过Anaconda），Intel在二进制文件方面开辟了一个新的领域，针对IA64处理器的内部特性进行了优化，因此，代码执行可以享受额外的CPU限制技巧，基于Intel对ILP4的了解，矢量化和分支预测在运行时会显示它们自己的CPU-s。值得一个测试来比较（另外，你可能会喜欢他们的非破坏性代码分析工具集成到VisualStudio中，在那里可以实时分析体外代码执行热点，这是一个DSP工程师会喜欢的事情，不是吗？在

Answer 3

请参阅here（第4节），以了解我亲自研究的一些同行评审基准。比较的是朱莉娅和皮比。在