【问题标题】:Limitations of parallelizing heterogeneous tasks并行化异构任务的局限性
【发布时间】:2023-03-19 01:20:01
【问题描述】:

我正在阅读 Java Concurrency in Practice,偶然看到一段这样说:-

6.3.4 并行化异构任务的限制

在多个工作人员之间划分异构任务的另一个问题 是任务可能有不同的大小。如果您将任务 A 和 B 划分为 两个工人,但 A 的时间是 B 的十倍,你只是加快了总速度 处理 9%。最后,在多个工作人员之间分配任务总是涉及 一些协调开销;为了使除法是值得的,这 开销必须通过生产力提高来补偿,因为 并行性

现在如果你通过粗体部分,是否正确地说工作线程的协调开销必须超过我使用线程并行实现的性能改进?

谁能帮我理解一下?

【问题讨论】:

  • 其他方式。它必须小于性能增益。我的一部分认为这可能适合 ELU...
  • 可能会迁移到ell.stackexchange.com ;-)

标签: java multithreading parallel-processing


【解决方案1】:

不,粗体字明显改变了句子的意思:

最后,将一项任务分配给多个工作人员总是会涉及一些协调开销;为了使划分变得有价值,这种开销必须超过通过并行性提高的生产力来补偿。

如果这仅仅是“必须不仅仅是提高生产力......”那么你是对的。上面的意思是,通过在工作线程中划分任务(开销)而导致的性能损失必须小于,而不是通过这样做获得的性能提升。

例如,如果您的开销为 10 秒,而您的性能提升仅为 5 秒,那么并行化操作实际上降低了您的整体性能。如果您的开销是 10 秒,但性能提升是 50 秒,那么您最终会减少 40 秒的总执行时间(即改进)。

另一种说法是“......这种开销必须被并行性带来的生产力提高所抵消。”。

【讨论】:

  • 我认为还需要注意的是,独立时序并不是唯一需要考虑的指标。因为除法可能还需要更多的 CPU 时钟、内存甚至 I/O 处理(如果缓存中间状态以使并行数据适合内存)。单独运行时,您的任务不必与其他应用程序进程的机器资源使用同时发生冲突。
  • @LoganMzz 你是绝对正确的——我只是当场编了一些简单的数字来说明这一点,我并不是要暗示并行化代码在任何方面都是一个简单的操作: )
  • 我认为你的答案是完美的,简单,清晰,并针对问题进行了演示。我只想为使用并行任务的 Java 开发人员增加精度,因为并发性不仅仅依赖于资源访问同步。并且注意还特别针对 Java Concurrency in Practice 读者。
  • 值得注意的是管理每个并行工作的开销(创建并行工作单元,原子插入工作列表,将工作拉出工作列表,加载机器寄存器,销毁工作单元,返回调度程序以获取另一个工作单元)实际上可能比您预期的要昂贵得多。在实践中,这意味着您通常不能将“仅几条语句”放入并行单元并领先。 ...
  • ... 人们常常惊讶于他们必须在并行粒度中投入多少工作才能使其高效。并行执行库尤其加剧了这一点。最好编译器知道并行性并且可以最大限度地将这些管理位编织到编译代码中以保持低开销。我不知道 Java 编译器/JIT 是否真的这样做。它非常重要,以至于我们设计了一种编程语言来帮助我们实现这种效果。 (如果您想了解更多信息,请通过我的用户页面查看 PARLANSE)。
猜你喜欢
  • 1970-01-01
  • 2018-08-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-04-08
  • 1970-01-01
  • 2016-05-03
  • 1970-01-01
相关资源
最近更新 更多