什么真的更高效？ Haskell 或 OCaml [关闭]答案

【问题标题】：What's really more performant? Haskell or OCaml [closed]什么真的更高效？ Haskell 或 OCaml [关闭]
【发布时间】：2010-11-29 21:10:12
【问题描述】：

在过去的 18 个月里，我一直在掌握函数式编程，从学习 OCaml 开始，现在又花了几周时间学习 Haskell。现在我想进行下一步并实现一些实际应用程序：一个简单的实时地形编辑器。我已经编写了许多实时地形渲染引擎，所以这是一个熟悉的话题。而且使用的递归算法和数据结构似乎非常适合函数式实现。

由于这是一个实时应用程序，我自然会寻找我能获得的最佳性能。现在一些（恕我直言）OCaml 的支持者经常抱怨 Haskell 比 OCaml 或 F# 慢。但是根据The Computer Language Benchmarks GameHaskell 经常击败 OCaml，即使只是很小的一部分 - 仍然存在问题，这个基准测试只需要非常具体的样本。

正确的做法当然是用两种语言实现程序并进行比较，但我只是不想做双重工作。

但也许其他人在 OCaml 和 Haskell 中做了类似的应用程序并给出了一些数据？

【问题讨论】：

@Trufa，我敢说 DRY 原则适用于比整个应用程序更小的“粒度”；在方法或类级别上会更有意义。我同意 OP 的观点，即您只能在两种语言和平台本质上做完全相同的事情时直接比较两种语言和平台——但当然，这是一种相当极端的发现方式，在大多数情况下不太实用。
@Trufa：写两个等价的程序来比较它们的性能特点，和DRY的原理无关。 DRY 是关于一条信息有一个规范的来源，而不是很多独立的来源。在这种情况下，两个程序本身都不包含必要的信息，所以只有当你已经编写了比较并且出于某种神秘的原因考虑再次编写它时，DRY 才会发挥作用。两个是比较所需的最少程序数，所以我看不出它可能是“明显低效”的。
语言基准测试游戏最近在 OCaml 邮件列表上引起了一些争议——一些规则似乎比其他规则对 OCaml 的影响更大。例如 OCaml 二叉树代码在 47 秒内运行。在“有趣的替代方案”部分中找到的 OCaml 树代码在 12.67s 中运行，这将使其排在 C 之后的第二位。alt 代码调整垃圾收集器，我猜这违反了二叉树代码的规则。我无法评论 Haskell 是否比 OCaml 更快，但用于基准测试的一些代码不是最佳的。
@Niki Yoshiuchi，二叉树基准测试对 Haskell 的影响也很严重，因为不允许使用惰性树。
主要的兴趣点肯定是 OCaml 的增量 GC 会导致平均 10 毫秒的暂停，最长可达 30 毫秒（对于表现良好的代码），而 GHC 的 stop-the-world GC 会导致任意长的暂停。令人惊讶的是，除了我之外，没有其他人提到过这一点，我的麻烦被投了 3 票……

标签： haskell benchmarking ocaml

【解决方案1】：

从各方面来说，OCaml 和 Haskell 都有足够高性能的编译器和运行时，几乎可以处理任何事情。根据纯粹的性能在它们之间进行选择对我来说似乎很愚蠢。您已经走到了这一步——以更清晰、更简洁、更具表现力、更高级别的代码的名义远离显然是最低级和性能最低的语言（C、C++ 等）。那么，当所涉及的性能差异要小得多时，为什么现在改用该标准呢？

我会选择一些更广泛的标准——如果您想要普遍的并行性，那么 Haskell 是更好的选择。如果您想要真正普遍的突变，那么 OCaml 会更好。

如果您最多只需要非常粗略的并行性，并且打算坚持使用大部分功能结构，那么请根据其他内容进行选择，例如语法（我认为 Haskell 在这里要好得多，但这是主观的）或可用的库（Haskell在数量/可用性方面获胜，但 OCaml 可能会在图形部门中胜出）。

我认为无论哪种方式你都不会出错

【讨论】：

“根据纯粹的性能在它们之间进行选择对我来说似乎很愚蠢”。即使性能差异可以达到数量级？
但基准测试显示它们并驾齐驱。不是数量级。
@Tyr：取决于您查看的基准。这个问题是关于软实时性能的，这意味着延迟和吞吐量。 GHC 的 stop-the-world GC 将导致此类应用程序的暂停时间过长，比 OCaml 的增量 GC 的暂停时间长几个数量级。其他一切都是多余的。
@Tyr 你说的这些基准在哪里？
C++11 不是低级的。

【解决方案2】：

在两位非常聪明的同事的帮助下，我用 Objective Caml 和 Haskell 编写了一个数据流优化库。 Haskell 版本更加多态，有更多的编译时类型检查，因此运行时检查更少。 OCaml 版本使用可变状态来累积数据流事实，本周可能会更快或更慢，具体取决于月相。关键事实是，在它们的预期应用程序中，这两个库都非常快，不值得被愚弄。也就是说，在各自的编译器（Quick C-- 和GHC）中，花在数据流优化上的时间很少，代码不值得改进。

基准测试是地狱。

【讨论】：

你只谈论吞吐量，他想要延迟。
C-- 的链接似乎已失效，现在自动重定向到有关护肤行业的博客...

【解决方案3】：

我编写了许多实时地形渲染引擎，所以这是一个熟悉的话题。

足够熟悉，知道大部分时间会花在哪里？

如果是这样，那么也许您可以为该部分编写代码，用不同的语言进行比较。

但是根据计算机语言基准测试游戏 Haskell 经常击败 OCaml，即使只是很小的一部分 - 仍然存在问题，该基准测试只需要非常具体的样本。

基准测试游戏报告 4 组结果 - 一个核心和 quad core，32 位或 64 位 Ubuntu - 您可能会发现 OCaml 或 Haskell 基准测试程序的性能会因平台而异。

基准测试所能做的就是获取非常具体的样本，当然您应该忽略对与您的应用程序中将花费大部分时间不同的任务进行比较 - 大整数算术？正则表达式？字符串？ - 并查看与您打算做的最相似的比较。

【讨论】：

在命令式地执行此类操作时非常熟悉。如果它只是关于地形渲染，那么一个纯粹的函数式方法就很自然了，因为你所做的基本上就是运行一些树结构，将顶点和索引发送到列表中。有趣的是，当数据结构发生变化时……很多。
>> 当数据结构发生变化时......很多

【解决方案4】：

根据我看到的所有数据，它们大致具有可比性。您编写的代码将比语言本身产生更大的影响。

【讨论】：

“基于我看到的所有数据”。如果您可以链接到一些数据会很棒，因为我看到的几乎所有数据都显示 Haskell 的运行速度明显慢于 OCaml。而且我不是在谈论 Haskell 和你在 Great Computer Language Shootout 中看到的 FFI hack。