什么是使用actors可以并行处理的最小工作单元？

Question

16

虽然Scala actor被描述为轻量级，而Akka actor更是如此，但使用它们肯定会有一些开销。因此，我的问题是，什么是值得使用Actor并行处理的最小工作单元（假设它可以并行处理）？只有在存在潜在延迟或有很多重计算的情况下才值得这样做吗？

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

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

假设使用Actor对我的程序进行结构化非常合适，因此不会产生额外的开发开销（甚至比非Actor实现更少的开发开销），但它执行的工作单位非常小-是否存在一些性能损害的点，应该避免使用Actor？

- Russell

3个回答

5

我的经验法则是，对于日常工作，如果需要几毫秒的时间，那么就有可能值得并行化。虽然事务处理速率比这要高（通常不超过几十微秒的开销），但我喜欢避免过多的开销。当然，它可能需要花费比几毫秒更长的时间才真正值得并行化。你总是需要权衡写更多代码所花费的时间和运行该代码所节省的时间。

- Rex Kerr

听起来很合理 - 对于一个非常适合演员的结构的程序，但其工作单位少于毫秒，你有什么看法？ - Russell

@Russell - 如果性能可以接受，使用actors。如果不行，进行基准测试以查看actors是否占用了大部分时间（例如，您可以通过发送双重消息来获得一个想法）。 - Rex Kerr

谢谢你们两个的回答 - 这是一种不幸的情况，你只能选择一个标记为已接受。 - Russell

0

如果在工作单元中不期望出现副作用，那么最好在运行时做出工作分割的决策：

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-所有窃取后工作队列的最大长度

这里有更多细节和数字的介绍：

- Andriy Plokhotnyuk

请注意，该演示文稿不是英文的；这里是一个有效的链接：http://shipilev.net/pub/talks/jeeconf-May2012-forkjoin.pdf - nezda

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Roland Kuhn · Accepted Answer

使用actor的问题并不是关于工作单元的问题，它的主要好处是使并发程序更容易实现。但与此同时，你需要根据不同的范式来建模你的解决方案。

因此，你首先需要决定是否需要使用并发（这可能是出于性能或正确性的原因），然后再决定是否使用actor。后者很大程度上是品味问题，尽管在Akka 2.0中，除非我有充分的理由，否则我会选择使用actor，因为你可以轻松地获得可分布性（up & out）而几乎没有额外的开销。

如果你仍然想反过来做决定，从我们的性能测试中可以得出一个经验法则：目标消息处理速率不应超过每秒几百万条。