Wie soll ich Profilierungs- / Timing-Informationen zu meinem Code melden?

Ich habe viele Veröffentlichungen in Fachzeitschriften für Computerphysik gesehen, die unterschiedliche Metriken für die Leistung ihres Codes verwenden. Insbesondere für GPGPU-Code scheint es eine Vielzahl von Timing-Ergebnissen zu geben, die von Menschen veröffentlicht werden. Insbesondere habe ich gesehen:

• Vergleiche von (im Wesentlichen) Ausführung timeauf der GPU- und CPU-Version und Berichterstattung über einen Durchschnitt
• Vergleiche der Profildaten für jede aufgerufene GPU / CPU-Funktion (zeitliche Abstimmung des Laufs mainund aller von ihr aufgerufenen Funktionen, jedoch ohne Berücksichtigung der Treiberinitialisierungszeit)
• Vergleiche von Profildaten für mehrere relevante Funktionen, Ignorieren von Dingen wie Speicherübertragungen (in diesem Fall über den PCI-E-Bus), E / A auf die Festplatte, Transformieren der Daten von einem Format in ein anderes usw.
• Vergleiche von Profildaten für nur eine Funktion (z. B. Vergleichen nur der Zeit für Spin-Updates in einer CPU mit GPU Quantum Monte Carlo) und Ignorieren von Dingen wie Speicherübertragungszeit, E / A auf Festplatte, Einrichten des Hamilton-Operators / Diagonalisieren , usw

Mein Gefühl ist, dass die erste Option die "ehrlichste" der vier ist, obwohl ich auch die Vorzüge der zweiten und dritten sehen kann. Es ist ein bisschen lächerlich, einen Laufzeitunterschied von 5 Sekunden zu melden, wenn 4,99 Sekunden der Unterschied bei E / A-Implementierungen zwischen Sprachen oder Infiniband und Gigabit waren. Die letzte Option erscheint mir etwas "skizzenhaft", da diese Funktion nicht die Leistung widerspiegelt, die jemand, der meine Ergebnisse repliziert, sehen würde, wenn diese Funktion nicht der Schmerzpunkt des gesamten Programms ist. Welcher dieser Ansätze ist klarer? Idealerweise würde ein Papier all dies enthalten, aber im Falle einer Beschränkung der Zahlen / Länge, was ist / sind am wertvollsten, ehrlichsten und relevantesten?

Die Gesamtlaufzeit (Wanduhr) ist die einzige Metrik, die in der Industrie oder in realen Anwendungen von Bedeutung ist: Diese Zahl sollte niemals weggelassen werden, auch wenn sie peinlich ist. Natürlich hängt diese Metrik stark von der Testumgebung ab, daher sollte dies ausführlich beschrieben werden.

Alle anderen Metriken können (oder sollten) gemeldet werden, wenn sie Einblick in das Problem geben, oder daraus können interessante Schlussfolgerungen (z. B. Überprüfung einer theoretischen Grenze) gezogen werden.

Ich denke, dass dieser Blogeintrag diesen Punkt anspricht, insbesondere den letzten Absatz.

Es ist oft der Fall, dass man nur die Spitze des Eisbergs aller Arbeiten und Kompromisse melden kann, die in eine Software eingeflossen sind. Die Berichtsleistung ist gut, aber die eigentliche Sache ist, wenn der Code im Internet frei zugänglich gemacht wird. Auf diese Weise kann jeder Interessierte die Ergebnisse bewerten und reproduzieren.

Wenn Sie die Software freigeben, können Sie im Idealfall auch die Tests zur Verfügung stellen, mit denen die in einem Dokument dargestellten Daten generiert werden.