Extending WRSS to Rust, Julia, Haskell, and Python Under Irregular Parallel Workloads

Wenn Ingenieure Software entwickeln, um massive Probleme zu lösen, zerlegen sie die Arbeit oft in kleinere Stücke und verteilen diese gleichzeitig an viele Prozessoren, in der Hoffnung, dass die Aufgabe schneller abgeschlossen wird. Diese Strategie, bekannt als paralleles Rechnen, funktioniert wunderbar, wenn die Arbeit perfekt gleichmäßig verteilt ist, wie etwa beim Sortieren eines Kartendecks, bei dem jeder Stapel die gleiche Anzahl an Karten enthält. In diesen geordneten Situationen haben Forscher einen Weg entwickelt, um exakt zu messen, an welchem Punkt die Geschwindigkeit aufhört sich zu verbessern – ein Punkt, an dem das Hinzufügen weiterer Arbeiter nicht mehr hilft. Dieses Messwerkzeug, genannt Workload–Runtime Scaling Signature, hat erfolgreich die Leistungsgrenzen für mehrere Programmiersprachen kartiert, wenn die Aufgaben vorhersehbar und einheitlich sind. Die reale Welt ist jedoch selten so ordentlich. Viele wissenschaftliche und geschäftliche Anwendungen beinhalten unordentliche, unregelmäßige Daten, bei denen einige Arbeiter einen Berg an Arbeit erhalten, während andere fast gar nichts bekommen, was einen verborgenen Flaschenhals schafft, den Standardwerkzeuge nicht sehen können.

Ein Forscher setzte sich zum Ziel zu testen, ob sein bestehendes Messwerkzeug dieses Chaos bewältigen konnte. Er nahm das Framework, das für ordentliche, regelmäßige Aufgaben funktionierte, und wandte es auf vier schwierige, unregelmäßige Jobs an: das Durchsuchen komplexer Netzwerke, das Navigieren durch tiefe Entscheidungsbäume, das Multiplizieren dünnbesetzter Matrizen und die Simulation von Teilchen, die sich durch den Raum bewegen. Er führte diese Aufgaben mit vier sehr unterschiedlichen Programmiersprachen – Rust, Julia, Haskell und Python – auf einem leistungsstarken Computersystem aus. Das Ziel war es zu sehen, ob die alte Methode immer noch aufzeigen konnte, wo die Verlangsamungen auftraten, wenn die Arbeitsverteilung unvorhersehbar war und von den Daten selbst abhing.

Der Forscher entdeckte, dass dem ursprünglichen Werkzeug ein entscheidendes Puzzleteil fehlte. In der alten Methode wurde die gesamte Rechenzeit in eine einzige Kategorie zusammengefasst. Aber bei diesen unregelmäßigen Jobs musste der langsamste Arbeiter oft signifikant mehr Arbeit verrichten als der durchschnittliche Arbeiter, schlichtweg weil die Daten dies erzwangen. Der Forscher erkannte, dass diese zusätzliche Belastung, verursacht durch die ungleiche Arbeitsverteilung, ein eigenständiges Problem war, das von der gesamten Menge der benötigten Berechnung getrennt betrachtet werden musste. Er schlug einen neuen Weg vor, die Daten zu betrachten, indem er die Rechenzeit in zwei Teile spaltete: die durchschnittliche Arbeit, die alle leisten, und die zusätzliche, unfaire Arbeit, die dem langsamsten Arbeiter auferlegt wurde. Diese neue, vierteilige Sichtweise offenbarte, dass die alte dreiteilige Sichtweise oft darüber täuschte, wo der wahre Flaschenhals lag.

Als der Forscher diese neue, detailliertere Sichtweise auf seine Tests anwandte, änderten sich die Ergebnisse dramatisch. Bei Aufgaben wie der Suche durch komplexe Netzwerke oder der Simulation von Teilchen in dichten Clustern behauptete die alte Methode, dass die Computer immer noch durch die schiere Menge an Berechnungen begrenzt würden. Sie deutete darauf an, dass das Hinzufügen von mehr Arbeitern weiterhin helfen würde. Die neue Methode hingegen zeigte, dass das eigentliche Problem die Imbalance selbst war. In vielen Fällen war die zusätzliche Arbeit des langsamsten Arbeiters so groß, dass sie die Tatsache maskierte, dass das System bereits gegen eine Wand stieß, die durch Warten und Koordination verursacht wurde. Beispielsweise zeigte die neue Methode in einem Test mit einem Netzwerk aus vier Millionen Punkten, dass die Imbalance bis zu 34 Prozent der Gesamtzeit ausmachte – ein Faktor, den die alte Methode innerhalb der allgemeinen Berechnungswerte verborgen hatte.

Dieser Perspektivwechsel änderte das Verständnis des Forschers darüber, wann man mit dem Hinzufügen von Arbeitern aufhören sollte. In der alten Sichtweise schien ein Programm bis zu sechzehn Arbeitern gut skalieren zu können. In der neuen Sichtweise zeigte dasselbe Programm, dass die Vorteile bereits bei nur vier oder acht Arbeitern stoppten, weil die Imbalance zum dominierenden Problem geworden war. Die Studie fand heraus, dass dieses neue Diagnosewerkzeug für unregelmäßige Arbeitslasten essenziell war, für regelmäßige jedoch unnötig, da dort die Arbeit natürlich ausgeglichen ist. Der Forscher kam zu dem Schluss, dass man ohne die Trennung der durchschnittlichen Arbeit von der unfairen Zusatzarbeit die Leistung der Software systematisch falsch einschätzen könnte, wenn man die Ingenieure über die Optimierung ihrer Software täuschen wollte.

Die Studie hob auch hervor, wie verschiedene Programmiersprachen mit diesem Chaos umgehen. Die als Rust bekannte Sprache, die den Speicher sehr streng verwaltet, zeigte die beste Fähigkeit, die Arbeit im Gleichgewicht zu halten, mit der geringsten Menge an unfairer Zusatzzeit. Python, das einen anderen Ansatz zur Ausführung von Aufgaben nutzt, zeigte die größte Imbalance, wahrscheinlich weil seine Methode der Arbeitsaufteilung zu grob war, um die feingliedrigen Unregelmäßigkeiten zu handhaben. Julia und Haskell lagen dazwischen, wobei Julia je nach den spezifischen Daten eine gewisse Variabilität aufwies. Diese Erkenntnisse legen nahe, dass es bei unordentlichen, unvorhersehbaren Aufgaben nicht nur um die reine Geschwindigkeit geht, sondern darum, wie gut eine Sprache in der Lage ist, die ungleichmäßige Last unter ihren Arbeitern zu verteilen.

Letztendlich liefert die Forschung eine klarere Karte für die Navigation durch die Komplexität moderner Computertechnik. Sie zeigt, dass die alten Faustregeln nicht mehr gelten, wenn die Arbeit unregelmäßig ist. Indem man die durchschnittliche Anstrengung einfach von der zusätzlichen Last trennt, die dem langsamsten Arbeiter auferlegt wird, können Ingenieure endlich die wahren Grenzen ihrer Systeme erkennen. Diese Klarheit ermöglicht es ihnen, bessere Entscheidungen darüber zu treffen, wann sie mehr Leistung hinzufügen und wann sie sich auf die Lastverteilung konzentrieren sollten, um sicherzustellen, dass ihre Software in der chaotischen Realität realer Daten so effizient wie möglich arbeitet.