scala - 与参与者并行化的最小工作单元是什么？

Question

虽然 Scala Actors 被描述为轻量级的，但 Akka Actors 更是如此，使用它们显然有一些开销。

所以我的问题是，值得与 Actor 并行化的最小工作单元是什么（假设它可以并行化）？只有在存在一些潜在的延迟或有很多繁重的计算时才值得吗？

我正在寻找可以轻松应用于日常工作的一般经验法则。

编辑：到目前为止的答案让我意识到我感兴趣的实际上可能与我最初提出的问题相反。所以：

假设用参与者构建我的程序非常合适，因此不会产生额外的开发开销（甚至比非参与者实现产生的开发开销更少），但它执行的工作单元非常小 - 是否存在在哪一点上使用演员会损害性能并且应该避免？

score 6 · Accepted Answer

是否使用actor主要不是工作单元的问题，它的主要好处是使并发程序更容易正确处理。作为交换，您需要根据不同的范例为您的解决方案建模。

因此，您需要首先决定是否使用并发（这可能是由于性能或正确性），然后是是否使用参与者。后者在很大程度上是一个口味问题，尽管使用 Akka 2.0 我需要充分的理由不这样做，因为您基本上可以免费获得可分发性（向上和向外），而且开销很小。

如果您仍想另辟蹊径，我们的性能测试的经验法则可能是目标消息处理速率不应高于每秒几百万。

score 5 · Accepted Answer

对于日常工作，我的经验法则是，如果它需要几毫秒，那么它可能值得并行化。尽管交易率高于此（通常不超过几十微秒的开销），但我喜欢远离开销占主导地位的情况。当然，可能需要比几毫秒长得多的时间才能真正值得并行化。您总是必须平衡编写更多代码所花费的时间与运行它所节省的时间。

score 0 · Accepted Answer

如果工作单元中没有预期的副作用，那么最好在运行时做出工作拆分的决定：

protected T compute() {
  if (r – l <= T1 || getSurplusQueuedTaskCount() >= T2)
    return problem.solve(l, r);
// decompose
}

在哪里：

T1 = N / (L * Runtime.getRuntime.availableProcessors())

N - 单位工作量

L = 8..16 - 负载系数，手动配置

T2 = 1..3 - 所有偷窃后工作队列的最大长度

这是包含更多细节和数据的演示文稿：

3 回答 3