私の状況
私が開発したソフトウェアモジュールを紹介する論文を書いており、そのランタイムを同じタスクの他のモジュールと比較したいと思います。ランタイムテストの欠点を認識していますが、私の場合は回避策がないと考えてください。(私は理論的にいくつかの特性を推定することができますが、それだけでは十分ではありません。)
ベンチマークに使用したい特定のシナリオには、2つのパラメーターがあります。問題の複雑度 と、詳細な問題を決定するランダムシード です。主に私はへの依存を示したいです 。予備調査と理論によると、ランタイムへのの影響は小さいか無視できます。1つのタスクが完了するまでに最大で10分かかります。
実際の質問
私は、そのような実験を実行する上で一般的に受け入れられているか公開されている手順、または少なくとも一般的な落とし穴のリスト(理想的には公開)を探しています。
これまでに見つけたもの
何もない。インターネット検索は、あらゆる種類の無関係な結果を表示しますが、その場合、正しい用語を使用していない可能性があります。私が良い基準であることがわかっているキーワードの最小値を含めること(下記を参照)も役に立ちませんでした。
どうやってやるの
すべての実験を、GUIなどの干渉する可能性のあるソフトウェアを可能な限り無効にして、同じマシンで実行します。
すべてのモジュールに同じ選択シナリオ、つまり同じおよび ます。
シナリオごとに、さまざまなモジュールをランダムな順序で直接続けてテストします。つまり、さまざまなモジュールのループが最も内側のループです。これにより、マシンのパフォーマンスのゆるやかな変動(温度変化など)によるさまざまなモジュールへのバイアスを回避できます。ランダムな順序は、キャッシュや、同じモジュールの後に常にテストされる1つのモジュールなどの影響によるバイアスを回避する必要があります。
各について、ベンチマークとして異なるシードを使用して、いくつかのシナリオで最小ランタイムを取得します。これにより、マシンのパフォーマンスが短時間変動して、個々の実行が非常に悪くなるため、さまざまなモジュールへのバイアスが回避されます。