上一篇博文中推荐了 Python 的 JIT 编译器 numba,这两天又用空余的时间尝试了一下最近的一个新兴语言 Julia。Julia 的目标设定得很高,未来是要成为一个速度上接近甚至超过 Fortran/C 这样的传统语言的通用编程语言。然而就我这两天很初步的尝试结果看来,它也许有这个能力,但至少目前,对工程计算的人来说,还没有达到 production-ready 的程度。(当然,这只是基于我个人的编程经验和需求的结论,很可能不适用于其他人。而且Julia本身是一门相对年轻的语言,很值得持续关注。)
之所以这样说,有三个方面的理由:
作为一个动态语言,它的 JIT 编译器(在很多情况下)还没有智能到,让我可以同时享受动态语言的便利和它的速度优势。例如最近我在试用 Julia 时最先尝试的就是把原来用 Numba 写的函数重写一遍,然而发现结果非常不好。Julia 版本的函数执行速度相当于纯 Python 的速度,与 Numba 版本相差三个数量级,占用的内存也异常地大。后来发现,最主要的原因是三层嵌套循环中,循环长度我按 Python 的习惯定义为变量,而在 Julia 中不变的全局量最好声明为常量。仅仅这个修改,让速度提升了两个数量级,但还不及 numba 的速度。进一步的测试还可以通过一些细小的地方来进一步提升速度,如这篇文章做的那样,最终高度优化之后速度也许可以达到接近 Fortran。但是,如果要这样做,为什么不干