Go 移動平均計算をゴルーチンで並列化するとパフォーマンスが低下するのはなぜですか?

背景

この問題には、スライスの移動平均を計算するための Go 関数の最適化が含まれます。この関数は本質的に恥ずかしいほど並列です。つまり、同時に実行できる独立したタスクに簡単に分割できます。

最適化の試みと結果

開発者は、2 つのゴルーチンを使用して関数を並列化しようとしました。方法:

• Moving_avg_concurrent2:スライスは小さな部分に分割され、各部分は個別のゴルーチンによって処理されました。
• Moving_avg_concurrent3: マスター/ワーカー パラダイムが採用され、マスター ゴルーチンが計算する複数のワーカー ゴルーチンを生成しました。入力の異なるウィンドウの移動平均lice.

ベンチマークでは、両方の同時アプローチのパフォーマンスが元のシリアル関数 moving_avg_serial4 よりも悪いことが示されました。

moving_avg_concurrent2 はスケールしないのはなぜですか?

move_avg_concurrent2 がスケーリングしない理由は、作成とゴルーチンの管理は並列処理の利点を上回ります。この場合、オーバーヘッドには、ゴルーチンの作成とスケジュールに費やされる時間、およびゴルーチン間の通信と同期に費やされる時間が含まれます。

moving_avg_concurrent3 は、moving_avg_serial4 よりもはるかに遅いのはなぜですか?

マスター/ワーカーパラダイムでは、直接 goroutine アプローチと比較して追加のオーバーヘッドが発生します。 move_avg_concurrent3 では、マスター ゴルーチンとワーカー ゴルーチン間の通信用のチャネルを作成し、ワーク ユニットの送受信を管理する必要があります。このオーバーヘッドにより、関数のパフォーマンスがさらに低下します。

ゴルーチンのオーバーヘッドがそれほど多くのオーバーヘッドを生成する可能性はありますか?

はい、ゴルーチンのオーバーヘッドがプログラムのパフォーマンスに大きな影響を与える可能性があります。 Goroutine は軽量のスレッドですが、作成、スケジュール、同期に関連するオーバーヘッドがまだあります。 move_avg_concurrent3 の場合、チャネル管理とマスター/ワーカー通信のオーバーヘッドにより、関数の実行時間が増加します。

以上がGo 移動平均計算をゴルーチンで並列化するとパフォーマンスが低下するのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。