朱莉娅(Julia):回顾过去的表现


19

我遇到了一个2012年的问题,该问题对朱莉娅进行了很好的讨论,关于朱莉娅是R / Python的替代品,用于各种类型的统计工作。

这是2012年关于朱莉娅的诺言的原始问题

不幸的是,朱莉娅那时还很新,而统计工作所需的工具包有些原始。错误正在被消除。发行版很难安装。等等。

有人对此问题发表了非常恰当的评论:

这就是说,事后才可能回答这个问题还需要5年。到目前为止,Julia缺少统计编程系统的以下关键方面,这些系统可能与R竞争日常用户:

那是在2012年。现在已经到了2015年,并且已经过去了三年,我想知道人们如何看待Julia的成就?

语言本身和整个Julia生态系统是否有更丰富的经验?我会很高兴知道。

特别:

  1. 您会建议统计工具的新用户学习R上的Julia吗?
  2. 您会建议某人使用哪种Statistics统计用例?
  3. 如果R在执行某项任务时很慢,切换到Julia或Python是否有意义?

注意:2015年6月14日首次发布。


2
我最近看了一眼,对他们的统计数据包的深度并不满意。如果我没记错的话,Python也会被解释,因此会有与R相似的局限性。据我所知,Julia的吸引力在于它有望带来额外的速度和更好的并行化访问。
DWin

3
我认为Julia的问题在于SciPy不断进步,现在我们也加入了Torch。没有人愿意学习第三(或第四或第五)科学计算语言,即使它快速且具有很酷的功能重载功能。
shadowtalker

4
朱莉娅(Julia)是一种精心设计的好语言,但我认为它来得太少太迟了。单节点矩阵计算流程早已过去。Julia本质上是Fortran 2.0,具有一些不错的功能,但是随着我们逐渐过渡到云计算中,在某种程度上,Scala,Clojure甚至Python等功能语言所提供的功能已经很少。如果朱莉娅在10年前处于目前的状态,那将是巨大的成功。
马克·克莱森

2
Python和Rcpp确实在动态发展,R得到越来越多的关注(R Consortium,Microsoft等),因此Julia很难追上……
Tim

1
我没有看到朱莉娅的商业案例,现在仍然没有。程序员似乎重新构建已经存在的东西似乎是多余的尝试。
阿萨卡(Aksakal)

Answers:


15

我已改用Julia,这是我的务实理由:

  • 它确实能很好地粘合代码。我在MATLAB中有很多遗留代码,而MATLAB.jl花费了5分钟的安装时间,完美地运行,并且语法简洁,使得使用MATLAB函数自然而然。Julia对于R,Python,C,Fortran和许多其他语言也具有相同的功能。
  • 朱莉娅(Julia)做得很好。我不仅在谈论多处理器(共享内存)并行性,而且在谈论多节点并行性。我可以访问一个不经常使用的HPC节点,因为每个节点都很慢,所以我决定尝试一下Julia。我在循环中添加了@parallel,通过告诉它机器文件开始了它,并使用了所有5个节点。尝试在R / Python中这样做。在MPI中,要花一些时间才能使它工作(并且知道您在做什么),而不是第一次尝试就花了几分钟!
  • Julia的向量化速度很快(在许多情况下,其速度比任何其他高级语言都要快),并且其去向量化的代码几乎是C速度。因此,如果您编写科学算法,通常通常先在MATLAB中编写它,然后在C中重新编写它。Julia让您编写一次,然后提供编译器代码,并在5分钟后很快。即使您不这样做,这也意味着您可以随意编写代码,并且可以正常运行。在R / Python中,有时必须认真思考才能获得良好的矢量化版本(稍后可能很难理解)。
  • 元编程很棒。想想你经历过“我希望我能用这种语言______”的次数。为此编写一个宏。通常已经有人。
  • 一切都在Github上。源代码。包装。超级容易阅读代码,向开发人员报告问题,与他们交谈以了解如何做某事,甚至自己改进软件包。
  • 他们有一些非常好的图书馆。对于统计数据,您可能会对它们的优化程序包感兴趣(JuliaOpt是管理它们的小组)。数字程序包已经是一流的,并且仅在改进。

也就是说,我仍然非常喜欢Rstudio,但是Atom上的新Juno真的很棒。当它不再繁重且稳定时,由于插件的简便性,我认为它比Rstudio更好(例如:它有一个很好的插件可以适应hidpi屏幕)。所以我认为Julia是现在学习的一门好语言。到目前为止,对我来说效果很好。YMMV。


超过3年以来,您介意更新此答案吗?
Bayequentist

1
我在这里给出了更新的响应:scicomp.stackexchange.com/questions/10922/…。也许应该复制过来。
克里斯·拉卡卡斯

11

我认为“学习X而不是Y”是提出问题的正确方法。实际上,您可以学习(至少是两者的基础)并根据手头的具体任务决定合适的工具。而且由于Julia从其他语言继承了大多数语法和概念,因此应该很容易理解它(以及Python,尽管我不确定R是否可以这么说)。

那么哪种语言更适合什么任务呢?根据我对这些工具的经验,我对它们进行以下评分:

  • 对于可以使用REPL和几个脚本进行的纯统计研究R似乎是理想的选择。它是专门为统计而设计的,具有最长的工具历史,并且可能是最大的统计库集。

  • 如果要整合统计信息(例如,机器学习)集成到生产系统中Python似乎是更好的选择:作为一种通用编程语言,它具有强大的Web堆栈,可以按字面意义绑定到大多数API和库,从抓取网络创建3D游戏

  • 高性能算法Julia中更容易编写。如果您只需要使用或合并现有的库,例如由C / C ++支持的SciKit Learne1071),则可以使用Python和R。但是在快速后端本身方面,Julia成为了真正的节省时间的工具:它的速度比Python或R,不需要其他C / C ++知识。例如,Mocha.jl在纯Julia深度学习框架Caffe中重新实现,该框架最初是用C ++编写的,并带有Python的包装。

  • 同样不要忘记,某些库仅在某些语言中可用。例如,只有Python具有成熟的计算机视觉生态系统,有些形状匹配和变形算法仅在Julia中实现,而且我听说过一些独特的R语言医学统计软件包。


我要说的是,大多数人应该尝试选择一种语言,并且大多数情况下都会保留这种语言-至少对我来说,使用多种语言最终我将它们混合在一起,这样
浪费

1
编写高性能算法的一个自相矛盾的问题是,即使它们可以更轻松地用R或Julia这样的高级语言编写,但是当您实际编写高性能算法时,您可能还是喜欢使用C ++之类的东西。也许那只是我。
Cliff AB

3

(b)您会建议某人使用什么样的统计用例?

(c)如果R在某项任务上执行缓慢,是否应该切换到Julia或Python?

高维和计算密集型问题。

  • 多处理。Julia的单节点并行功能(@spawnat)比python中的便利得多。例如,在python中,您不能在REPL上使用map reduce多处理池,并且您希望并行化的每个函数都需要大量样板。

  • 集群计算。Julia的ClusterManagers软件包使您几乎可以像使用一台具有多个内核的计算机一样使用计算集群。[我一直在努力使它看起来更像ClusterUtils中的脚本 ]

  • 共享内存。朱莉娅的SharedArray对象优于python中的等效共享内存对象。

  • 速度。在随机数生成和线性代数(支持多线程BLAS)方面,我的Julia实现(单机)比我的R实现快。
  • 互操作性。Julia的PyCall模块使您无需包装即可访问python生态系统-例如,我将其用于pylab。R也有类似的东西,但是我还没有尝试过。还有ccallC / Fortran库。
  • GPU。朱莉娅的CUDA包装器距离超过那些在Python开发(RS是几乎不存在的,当我检查)。我怀疑这种情况会继续存在,因为在Julia中调用外部库比在python中调用外部库要容易得多。

  • 生态系统。Pkg模块使用github作为后端。我相信这将对Julia模块的长期可维护性产生重大影响,因为它使提供补丁程序或使所有者承担责任更加容易。

  • σ

针对大问题编写快速代码将越来越依赖于并行计算。Python本质上是并行不友好(GIL),R中的本机多重处理是不存在的AFAIK。Julia不需要您使用C语言来编写高性能代码,同时又保留了python / R / Matlab的大部分感觉。

来自python / R的Julia的主要缺点是缺乏核心功能之外的文档。python非常成熟,您在文档中找不到的通常是在stackoverflow上。相比之下,R的文档系统相当不错。

(a)您会建议统计工具的任何新用户通过R学习Julia吗?

是的,如果您适合(b)部分中的用例。如果您的用例涉及大量异构工作

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.