haskell - Eval、rpar 和 rseq —— 有什么好处吗？

Question

我正在学习 Haskell 中的并行性。我看过这段代码:

runEval $ do
  a <- rpar (f x)
  b <- rpar (f y)
  rseq a
  rseq b
  return (a,b)

它和这个在性能和开销方面有什么区别？

let a = f x
let b = f y
(a, b)

也就是说，根本不使用Eval。对我来说，第二个具有相同的性能和更少的开销。

Answer 1

这完全取决于 f 的作用。如果f您的系统需要很长时间来计算，并且您的系统有空闲的CPU核心，那么并行版本将更快地完成。

如果f是像f n = n + 1这样的小东西，那么当然标准单线程版本会更快。创建 Haskell 线程的开销相当低，但也没有那么低。 (当然，如果您只有一个执行上下文，那么无论如何都没有意义)。

请注意，如果我们将开销定义为“系统所做的与计算结果不直接相关的工作”，那么第一个版本总是有更多的“开销”。但是，如果您并行评估f x 和f y，即使系统在开销上“浪费”了一些执行资源，您也可能会更快地完成。我们可以将并行版本的运行时间近似为:

maximum(time for f x, time for f y)  +  overhead

标准版本的运行时间为:

time for f x  +  time for f y

因此，只有当两个 f 调用中较小的一个调用确实比并行化开销花费更多的时间时，并行版本才值得。

当然，实际上情况可能要复杂得多。其中一个问题是:如果 f x 和 f y 共享对相同 thunk 的引用，则标准顺序版本完全共享工作，而并行版本可能会意外地浪费两个线程的时间执行重击。特别是如果 f x 和 f y 的大部分工作实际上是减少 thunk 以使 f 准备好应用，那么你根本就没有“真正”并行化这项工作(而是或多或少地让两个线程竞赛，看看哪一个先完成)。

最终您需要使用测量和判断来决定在何处应用并行性。它不是你可以盲目添加并自动获得好处的东西(否则编译器会为你做这件事)。

但如果您尝试并行运行两个非常琐碎的计算，它肯定不会给您带来任何好处。如果您只是想尝试并行性以了解其工作原理，请尝试编写一个函数 f 来完成足够的工作，以便您的第二个版本至少需要几秒钟的时间来运行，然后看看并行版本是否更快。