为什么使用 Goroutines 并行化 Go 移动平均计算会导致性能下降？

背景

这个问题涉及优化 Go 函数来计算切片的移动平均值。该函数本质上是令人尴尬的并行，这意味着它可以轻松地拆分为可以并发执行的独立任务。

优化尝试和结果

开发人员尝试使用两个 goroutine 并行化该函数ways:

• Moving_avg_concurrent2:切片被分割成更小的片段，每个片段由一个单独的goroutine处理。
• Moving_avg_concurrent3: 采用了 master/worker 范式，一个 master goroutine 催生了多个worker goroutine 计算输入切片不同窗口的移动平均值。

基准测试表明，两种并发方法的性能都比原始串行函数moving_avg_serial4。

为什么 moving_avg_concurrent2 无法缩放？

原因moving_avg_concurrent2 无法扩展的原因是创建和管理 goroutine 的开销超过了并行性的好处。在这种情况下，开销包括创建和调度 goroutine 所花费的时间，以及 goroutine 之间的通信和同步所花费的时间。

为什么 moving_avg_concurrent3 比 moving_avg_serial4 慢很多？

与直接 goroutine 方法相比，master/worker 范式引入了额外的开销。在 moving_avg_concurrent3 中，需要创建一个用于 master 和worker goroutine 之间通信的通道，并管理工作单元的发送和接收。这种开销进一步降低了函数的性能。

goroutine 开销是否有可能产生如此大的开销？

是的，goroutine 开销可能会显着影响程序的性能。 Goroutine 是轻量级线程，但它们仍然有一些与其创建、调度和同步相关的开销。在 moving_avg_concurrent3 的情况下，管理通道和 master/worker 通信的开销会增加函数的运行时间。

以上是为什么使用 Goroutines 并行化 Go 移动平均计算会导致性能下降？的详细内容。更多信息请关注PHP中文网其他相关文章！