与 Python+Numba LLVM/JIT 编译的代码相比，Julia 的性能

Question

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

我注意到的一件事是 Julia 使用的是 LLVM v3.3，而 Numba 使用的是基于 LLVM v3.5 构建的 llvmlite。 Julia 的旧 LLVM 是否会阻止在 Intel Haswell（AVX2 指令）等较新架构上实现最佳 SIMD？

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

这个问题的第二部分是 Numba 与 NumbaPro 的比较（忽略 MKL BLAS）。考虑到 Numba 中 @jit 装饰器的新 nogil 参数，真的需要 NumbaPro 的 target="parallel" 吗？

Answer 1

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

我注意到的一件事是 Julia 使用的是 LLVM v3.3，而 Numba 使用的是基于 LLVM v3.5 构建的 llvmlite。 Julia 的旧 LLVM 是否会阻止在 Intel Haswell（AVX2 指令）等较新架构上实现最佳 SIMD？

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

Julia 确实在 LLVM 3.3 中关闭了 avx2，因为 Haswell 上有一些严重的错误。

Julia 使用 LLVM 3.3 构建当前版本和 nightlies，但您可以使用 3.5、3.6 和通常的 svn trunk 构建（如果我们尚未针对特定日期的某些 API 更改进行更新，请提交问题）。为此，请在Make.user 中设置LLVM_VER=svn（例如），然后按照构建说明进行操作。

Answer 2

请参阅here（第 4 节）了解我个人参与的一些同行评审基准。比较的是 Julia 和 PyPy。

Answer 3

（比较无与伦比，永远是一把双刃剑。

以下内容是出于公平的信念，即应将 LLVM/JIT 驱动的代码基准与其他一些 LLVM/JIT 驱动的替代方案进行比较，以得出任何得出的结论应作为合理支持的决策的基础。）

---

简介：^{（numba 的东西和 [us] 结果在页面下方有点低）}

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

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

高性能 JIT 编译器
Julia 基于 LLVM 的即时 (JIT) 编译器与该语言的设计相结合，使其性能接近并经常与 C 相匹配。


我认为比较苹果和苹果会更严格一些，并且只采用了一个“benchmark-task”-s，称为 pi-sum。

这是解释型 python 的第二差，运行速度比 LLVM/JIT 编译的 julia-code 或 C 编译的替代方案慢 21.99 倍。

于是小实验故事开始了。

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

让我们开始比较苹果和苹果。如果 julia 代码被报告运行速度提高了 22 倍，那么我们首先测量一个普通解释的 python 代码运行。

>>> 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 pi-sum in language presentation，LLVM/JIT 驱动的 julia 代码执行速度应该快 22 倍，即低于 ~57.92 [ms]

>>> 1274231 / 22
57919

所以，让我们使用 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

因此，在 JIT 编译器完成工作后，numba-LLVM'ed python 的基准测试时间在某处大约 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
并没有使执行更远，
但仍会减少几个 [ms]，使 所有结果低于 ~ 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
只进行最后的润色
以获得所有结果始终低于 ~ 35.86 [ms]（对比 ~57.92 [ms ] 对于 LLVM/JIT-julia )

---

DSP 处理结语：

关于加速 DSP 处理的额外好处的 OP 问题，
可以尝试测试 numba + Intel Python（通过 Anaconda )，英特尔在二进制文件中开辟了新视野，针对 IA64 处理器内部进行了优化，因此代码执行可能会享受额外的 CPU 绑定技巧，基于英特尔对 ILP4 的了解，矢量化和分支预测详细说明了他们自己的 CPU-s在运行时展示。值得一试来比较这一点（另外一个人可能会喜欢他们集成到 VisualStudio 中的非破坏性代码分析工具，其中可以实时分析体外代码执行热点——这是 DSP 工程师会喜欢的东西，他/她不会吗？