Warum führte die Parallelisierung einer Go-Moving-Average-Berechnung mit Goroutinen zu Leistungseinbußen?

Hintergrund

Dieses Problem beinhaltet die Optimierung einer Go-Funktion zur Berechnung des gleitenden Durchschnitts eines Slice. Die Funktion ist von Natur aus peinlich parallel, was bedeutet, dass sie leicht in unabhängige Aufgaben aufgeteilt werden kann, die gleichzeitig ausgeführt werden können.

Optimierungsversuche und Ergebnisse

Der Entwickler hat versucht, die Funktion mithilfe von Goroutinen in zwei Teile zu parallelisieren Wege:

• Moving_avg_concurrent2: Das Slice wurde in kleinere Teile aufgeteilt und jedes Teil wurde von einer separaten Goroutine verarbeitet.
• Moving_avg_concurrent3: Das Master/Worker-Paradigma wurde übernommen, bei dem eine Master-Goroutine mehrere Worker-Goroutinen erzeugte, um die Bewegung zu berechnen Durchschnitt für verschiedene Fenster des Eingabesegments.

Benchmarks zeigten, dass beide gleichzeitigen Ansätze schlechter abschnitten als das Original serielle Funktion moving_avg_serial4.

Warum skaliert Moving_avg_concurrent2 nicht?

Der Grund, warum Moving_avg_concurrent2 nicht skaliert, ist, dass der Aufwand für die Erstellung und Verwaltung von Goroutinen die Vorteile der Parallelität überwiegt. In diesem Fall umfasst der Overhead die Zeit, die für die Erstellung und Planung der Goroutinen aufgewendet wird, sowie die Zeit, die für die Kommunikation und Synchronisierung zwischen den Goroutinen aufgewendet wird.

Warum ist Moving_avg_concurrent3 so viel langsamer als Moving_avg_serial4?

Das Master/Worker-Paradigma führt im Vergleich zum direkten Goroutine-Ansatz zu zusätzlichem Overhead. In Moving_avg_concurrent3 besteht die Notwendigkeit, einen Kanal für die Kommunikation zwischen den Master- und Worker-Goroutinen zu erstellen und das Senden und Empfangen von Arbeitseinheiten zu verwalten. Dieser Overhead verschlechtert die Leistung der Funktion weiter.

Ist es möglich, dass der Goroutine-Overhead so viel Overhead erzeugt?

Ja, es ist möglich, dass der Goroutine-Overhead die Leistung eines Programms erheblich beeinträchtigen kann. Goroutinen sind leichtgewichtige Threads, die jedoch immer noch mit einem gewissen Overhead bei der Erstellung, Planung und Synchronisierung verbunden sind. Im Fall von Moving_avg_concurrent3 erhöht sich der Aufwand für die Verwaltung des Kanals und der Master/Worker-Kommunikation zur Laufzeit der Funktion.

Das obige ist der detaillierte Inhalt vonWarum führte die Parallelisierung einer Go-Moving-Average-Berechnung mit Goroutinen zu Leistungseinbußen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!