Log-Log-Diagramme für parallele Skalierung / Effizienz

In meiner eigenen Arbeit beschäftige ich mich hauptsächlich mit der Verbesserung der Skalierbarkeit von Algorithmen. Eine der bevorzugten Methoden zur Darstellung von paralleler Skalierung und / oder paralleler Effizienz besteht darin, die Leistung eines Algorithmus / Codes über die Anzahl der Kerne zu zeichnen, z

Dabei repräsentiert die Achse die Anzahl der Kerne und die y- Achse eine Metrik, z. B. die pro Zeiteinheit geleistete Arbeit. Die verschiedenen Kurven zeigen parallele Wirkungsgrade von 20%, 40%, 60%, 80% und 100% bei 64 Kernen.$x$$y$

Leider werden diese Ergebnisse in vielen Veröffentlichungen mit einer Log-Log- Skalierung aufgezeichnet , z. B. die Ergebnisse in diesem oder diesem Artikel. Das Problem bei diesen Log-Log-Diagrammen ist, dass es unglaublich schwierig ist, die tatsächliche parallele Skalierung / Effizienz zu bewerten, z

Welches ist das gleiche Diagramm wie oben, aber mit Log-Log-Skalierung. Beachten Sie, dass es jetzt keinen großen Unterschied zwischen den Ergebnissen für 60%, 80% oder 100% parallele Effizienz gibt. Ich habe ein bisschen mehr ausführlich darüber geschrieben hier .

Hier ist meine Frage: Welche Gründe gibt es für die Anzeige von Ergebnissen bei der Protokoll-Protokoll-Skalierung? Ich verwende regelmäßig die lineare Skalierung, um meine eigenen Ergebnisse anzuzeigen, und werde regelmäßig von Schiedsrichtern darauf aufmerksam gemacht, dass meine eigenen parallelen Skalierungs- / Effizienzergebnisse nicht so gut aussehen wie die (logarithmischen) Ergebnisse anderer, aber für das Leben von mir Ich kann nicht verstehen, warum ich den Plotstil wechseln soll.

Derzeit schreiben wir eine Arbeit, die eine Reihe vergleichbarer Handlungen enthält, und wir hatten mehr oder weniger das gleiche Problem. In diesem Artikel wird die Skalierung verschiedener Algorithmen über die Anzahl der Kerne verglichen, die auf einem BlueGene zwischen 1 und 100.000 liegen. Der Grund für die Verwendung von Loglog-Plots in dieser Situation ist die Anzahl der beteiligten Größenordnungen. Es gibt keine Möglichkeit, 6 Größenordnungen auf einer linearen Skala zu zeichnen.

Und tatsächlich sind die Algorithmen beim Zeichnen der Zeit über die Anzahl der Kerne im Protokoll nicht sehr unterscheidbar, wie Sie im folgenden Diagramm sehen können.

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

Das Auftragen der relativen parallelen Effizienz auf einer Semilog-Skala zeigt ziemlich deutlich die Skalierung eines Algorithmus und zeigt auch, wie die Algorithmen relativ zueinander arbeiten.

Georg Hager schrieb darüber in Fooling the Masses - Stunt 3: Die Log-Skala ist dein Freund .

Log-Log-Diagramme mit starker Skalierung sind zwar im oberen Bereich nicht sehr anspruchsvoll, ermöglichen jedoch die Darstellung der Skalierung über viele weitere Größenordnungen. Um zu sehen, warum dies nützlich ist, betrachten Sie ein 3D-Problem mit regelmäßiger Verfeinerung. Auf einer linearen Skala können Sie die Leistung in etwa zwei Größenordnungen darstellen, z. B. 1024 Kerne, 8192 Kerne und 65536 Kerne. Es ist für den Leser unmöglich, anhand des Diagramms zu erkennen, ob Sie etwas Kleineres erstellt haben, und realistisch gesehen vergleicht das Diagramm meist nur die beiden größten Durchläufe.

Angenommen, wir können 1 Million Gitterzellen pro Kern in den Speicher einpassen, bedeutet dies, dass wir nach zweimaliger Skalierung um den Faktor 8 immer noch 16.000 Zellen pro Kern haben können. Das ist immer noch eine beträchtliche Subdomänengröße, und wir können erwarten, dass dort viele Algorithmen effizient ausgeführt werden. Wir haben das visuelle Spektrum des Diagramms (1024 bis 65536 Kerne) abgedeckt, sind aber noch nicht einmal in das Regime eingetreten, in dem eine starke Skalierung schwierig wird.

Nehmen wir stattdessen an, dass wir mit 16 Kernen begonnen haben, ebenfalls mit 1 Million Gitterzellen pro Kern. Wenn wir jetzt auf 65536 Kerne skalieren, werden wir nur 244 Zellen pro Kern haben, was viel anspruchsvoller sein wird. Eine logarithmische Achse ist die einzige Möglichkeit, das Spektrum von 16 Kernen bis 65536 Kernen eindeutig darzustellen. Natürlich können Sie auch weiterhin eine lineare Achse verwenden und eine Beschriftung mit der Aufschrift "Die Datenpunkte für 16, 128 und 1024 Kerne überlappen sich in der Abbildung" verwenden. Jetzt verwenden Sie jedoch Wörter anstelle der Abbildung.

Eine Protokoll-Protokoll-Skala ermöglicht es Ihrer Skalierung auch, Maschinenattribute wie das Überschreiten eines einzelnen Knotens oder Racks "wiederherzustellen". Es liegt an Ihnen, ob dies wünschenswert ist oder nicht.

Ich stimme mit allem überein, was Jed in seiner Antwort zu sagen hatte, aber ich wollte Folgendes hinzufügen. Ich bin ein Fan davon geworden, wie Martin Berzins und seine Kollegen Skalierung für ihr Uintah-Framework zeigen. Sie zeichnen eine schwache und starke Skalierung des Codes auf Log-Log-Achsen auf (unter Verwendung der Laufzeit pro Schritt der Methode). Ich denke, es zeigt, wie gut der Code skaliert (obwohl die Abweichung von der perfekten Skalierung ein wenig schwer zu bestimmen ist). Siehe Seite 7 und 8, Abbildungen 7 und 8 dieses * Papiers. Sie geben auch eine Tabelle mit den Nummern an, die den einzelnen Skalierungsfiguren entsprechen.

Ein Vorteil davon ist, dass, sobald Sie die Zahlen angegeben haben, ein Rezensent nicht viel sagen kann (oder zumindest nicht viel, was Sie nicht widerlegen können).

* J. Luitjens, M. Berzins. "Verbessern der Leistung von Uintah: Ein umfangreiches adaptives Meshing-Computer-Framework", In Proceedings des 24. IEEE International Parallel and Distributed Processing Symposium (IPDPS10), Atlanta, GA, S. 1-10. 2010. DOI: 10.1109 / IPDPS.2010.5470437