Haskell,Scala,Clojure,高性能模式匹配和并发的选择



在阅读了许多关于FP在并发执行和性能方面的优势的博客和帖子后,我最近开始研究FP。我对FP的需求在很大程度上受到了我正在开发的应用程序的影响。我的应用程序是另一个子系统中基于状态的数据注入程序,其中时间非常关键(接近每秒200万个事务)。我有几个这样的子系统需要测试。我正在认真考虑使用FP的并行性,并希望采取正确的方法,SO上的许多帖子都谈到了Scala、Haskell和Clojure wrt语言构造、库和JVM支持的缺点和优点。从语言的角度来看,我可以学习任何语言,只要它能帮助我达到目的。

某些帖子支持Haskell的模式匹配和语言的简单性,基于JVM的FP-lang相对于使用现有的java库有很大的优势。JaneStreet是OCAML的忠实支持者,但我真的不确定OCAML的开发者支持和帮助论坛。

如果有人处理过如此大的数据,请分享你的经验。

您想要快速还是想要easy

如果你想要快速,你应该使用C++,即使你使用FP原理来帮助正确性。由于时间安排至关重要,因此对软实时编程(如果需要,还可以支持硬实时编程)的支持将非常重要。你可以决定如何以及何时有时间恢复内存,并且只花尽可能多的时间在这项任务上。

你所说的三种语言都比手工调优的C++要慢2-3倍,而且只有在以相当传统的命令式方式使用时才会慢。它们都使用垃圾收集,这将在事务中引入不受控制的随机延迟。

也就是说,现在要用C++以防弹的方式运行这项工作需要做很多工作。应用FP原则需要相当多的样板(即使在C++11中也是如此),并且大多数库在默认情况下都是可变的。(编辑:Rust正在成为一个很好的替代品,但详细描述Rust超出了这个答案的范围。)

也许你没有时间,可以缩减其他规格。例如,如果关键不是定时而是吞吐量,那么你可能想要Scala胜过Clojure(请参阅《计算机语言基准测试游戏》,在撰写本文时,Scala赢得了所有基准测试,并且在几乎所有情况下都有较低的代码大小(编辑:CLBG在这方面不再有帮助,尽管你可能会在Web档案中找到支持这些语句的档案);OCaml和Haskell的选择还有其他原因(类似的基准分数,但它们有不同的语法和互操作性等等)。

至于哪种系统具有最好的并发支持,Haskell、Clojure和Scala都很好,而OCaml则有点缺乏。

这几乎把它缩小到Haskell和Scala。您需要使用Java库吗?Scala。你需要使用C库吗?可能是哈斯克尔。你两者都不需要吗?然后你可以根据你在风格上更喜欢哪一个来选择,而不必过于担心你选错了一个会让你的生活变得更加艰难。

我已经用Clojure完成了这项工作,事实证明它非常有效,原因如下:

  • 就库而言,在JVM上是一个巨大的优势。出于我的目的,这实际上排除了Haskell和Ocaml,因为我们需要轻松访问Java生态系统并与基于JVM的工具(Maven构建等)集成
  • 如果需要严格优化内部循环,您可以使用纯Java。我们这样做是为了一些自定义代码处理大型双[]数组,但Clojure 99%的时间都能为您提供所需的性能。看见http://www.infoq.com/presentations/Why-Prismatic-Goes-Faster-With-Clojure关于如何让Clojure快速运行的一些示例(相当技术性的视频,假设有一些先验知识!)。一旦你开始计算利用多个核心的容易程度,Clojure在性能上就非常有竞争力
  • Clojure具有非常好的多核并发支持。事实证明,这对于管理并发任务非常有用。看见http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey
  • REPL为数据的测试和探索工作提供了一个非常好的环境
  • Clojure是lazy,这使得它适合处理大于内存的数据集(假设您注意不要试图同时将整个数据集强制放入内存)。在这样的环境中也有一些不错的图书馆,最著名的是Storm和Aleph。Storm对您来说可能特别有趣,因为它是为分布式实时处理大量事件而设计的

我对其他语言没有太多的经验,但我对Haskell和Scala的一些实践经验给我的印象是:

  • 如果您关心静态类型的纯粹性和严格的函数编程,那么Haskell非常棒。静态类型可以有力地保证正确性,因此可能适合高度算法化的工作。就我个人而言,我发现纯FP a有点太死板了——很多时候可变状态是有用的,我认为Clojure在这里有一个稍微好一点的平衡(通过允许受控的可复用性通过托管引用)
  • Scala是一种很棒的语言,它与Clojure共享JVM的优势。对我来说,Scala更像是一个"更好的Java",具有功能特性和令人印象深刻的类型系统。这不是Clojure的范式转变。不利的一面是,类型系统可能会变得相当复杂/令人困惑

总的来说,我认为你可以对这些感到满意。这可能会归结为您对JVM的关心程度以及您对类型系统的看法。

最新更新