コードに関するプロファイリング/タイミング情報を報告するにはどうすればよいですか？

Computational Physicsジャーナルの多くの出版物がコードのパフォーマンスにさまざまなメトリックを使用しているのを見てきました。特にGPGPUコードの場合、ユーザーが公開するタイミング結果には非常に多くの種類があるようです。特に、私は見ました：

• timeGPUとCPUのバージョンで（基本的に）実行し、平均を報告することの比較
• 呼び出された各GPU / CPU関数のプロファイリングデータの比較（そのため、実行されたmainすべての関数のタイミングを調整しますが、ドライバーの初期化時間は無視します）
• メモリ転送（この場合はPCI-Eバスを介して）、ディスクへのI / O、あるフォーマットから別のフォーマットへのデータ変換などを無視した、いくつかの関連機能のデータのプロファイリングの比較
• 1つの関数のみのプロファイリングデータの比較（たとえば、CPUとGPU量子モンテカルロでスピン更新を実行する時間のみを比較）、メモリ転送時間、ディスクへのI / O、ハミルトニアンの設定/対角化などを無視、など

2番目と3番目のメリットも確認​​できますが、最初のオプションは4つの中で最も「正直」です。言語間またはInfinibandとGigabit間のI / O実装の違いが4.99秒だった場合、5秒のランタイムの違いを報告するのは少しばかげています。最後のオプションは、この関数がプログラム全体の問題点でない限り、それについての情報を報告することは、私の結果を複製している誰かが見るパフォーマンスを反映しないだけなので、私には少し「不器用」に思えます。これらのアプローチのどれがより正直ですか？理想的には、紙にはこれらすべてが含まれますが、図/長さに制限がある場合、これは最も価値があり、正直で、提供に関連性がありますか？

合計実行時間（ウォールクロック）は、業界または実際のアプリケーションで重要な唯一のメトリックです。恥ずかしい場合でも、この数値を省略してはなりません。もちろん、このメトリックはテスト環境に大きく依存するため、これについて詳しく説明する必要があります。

他のすべてのメトリックは、問題への洞察を提供する場合に報告できます（または報告する必要があります）、または興味深い結論（たとえば、理論上の限界の検証）をそれらから引き出すことができます。

このブログのエントリは、この点、特に最後の段落を扱っていると思います。

すべての作業の氷山の一角と、ソフトウェアに侵入した妥協点しか報告できない場合がよくあります。レポートのパフォーマンスは優れていますが、実際の問題は、コードがインターネット上で自由にアクセスできるようになっていることです。これにより、興味のある人なら誰でも結果を評価して再現できます。

理想的には、ソフトウェアをリリースする場合、ペーパーで提示されたデータを生成するテストを利用可能にすることもできます。