初试 Julia 语言 (转)

原文地址：

https://blog.csdn.net/seekiu/article/details/47397067

 

随着  Julia 1.0版本的推出，人工智能圈子比较炸锅， 好像这门小众语言要赶超Python了， 做为如今编程领域的大佬，Python最被人诟病的就是运算性能，恰巧 Julia 是已高性能并行计算为主打，而且兼顾了语法简洁和动态性，好奇之下找了找网上的相关资料，发现确实是过小众了，最后发现了下面这篇文章，以为有些用处。

 

 如下为原文内容：

 

上一篇博文中推荐了 Python 的 JIT 编译器 numba，这两天又用空余的时间尝试了一下最近的一个新兴语言 Julia。Julia 的目标设定得很高，将来是要成为一个速度上接近甚至超过 Fortran/C 这样的传统语言的通用编程语言。然而就我这两天很初步的尝试结果看来，它也许有这个能力，但至少目前，对工程计算的人来讲，尚未达到 production-ready 的程度。（固然，这只是基于我我的的编程经验和需求的结论，极可能不适用于其余人。并且Julia自己是一门相对年轻的语言，很值得持续关注。）

之因此这样说，有三个方面的理由：

1. 做为一个动态语言，它的 JIT 编译器（在不少状况下）尚未智能到，让我能够同时享受动态语言的便利和它的速度优点。例如最近我在试用 Julia 时最早尝试的就是把原来用 Numba 写的函数重写一遍，然而发现结果很是很差。Julia 版本的函数执行速度至关于纯 Python 的速度，与 Numba 版本相差三个数量级，占用的内存也异常地大。后来发现，最主要的缘由是三层嵌套循环中，循环长度我按 Python 的习惯定义为变量，而在 Julia 中不变的全局量最好声明为常量。仅仅这个修改，让速度提高了两个数量级，但还不及 numba 的速度。进一步的测试还能够经过一些细小的地方来进一步提高速度，如这篇文章作的那样，最终高度优化以后速度也许能够达到接近 Fortran。可是，若是要这样作，为何不干脆用 Fortran 呢？相比之下，numba 的可用性就要高太多了。不过毕竟它如今的稳定版本仍是0.3.10，还须要再给它一点时间发展成熟。

2. 做为一个新兴、小众的语言，相关的工具链还太弱了。没有合格的 IDE，Juno 在我看来如今连半成品都还算不上。包管理彷佛是用的 Git，有时会出一些奇怪的问题，这时候用 Pkg 倒还不如手动去管理。调试程序也比较痛苦，一方面是不少错误信息跟没给差很少，像我这种不熟悉的人基本只能用 print 一半一半地查，另外一方面是相关的调试工具也还不够好用。

3. 文档、相关信息还太少。已经有很多人开始使用 Julia，但网上公开的信息中，官方的文档还比较简陋，其余用户贴出的博客也不多。这致使在遇到问题的时候，很难快速地难过 Google 直接获得问题的答案，而每每须要在社区中等待圈内人士的解答。

另一个对 Julia 印象不太好的是，官网给出的 benchmark 没有多少参考价值，至少其结果中 Python 和 Matlab 都颇有问题，多半是单纯地逐行翻译出来的程序。这就跟我把 numba 的程序直接翻译成 Julia，而后得出结论它很慢同样，是不公平的比较。

无论怎么样，Julia 目前看来仍是值得持续关注的，可是目前，我还不会考虑把它做为主要的计算语言。