ELKIの場合、標準の Java JDK と Collections API で提供されるものよりも柔軟な並べ替えの実装が必要です (そして持っています)。(ソートは私の究極の目標ではありません。kd ツリーや R* ツリーなどのインデックス構造を一括でロードするために部分ソートを使用しています。現在 ELKI にあるものよりも一般的な実装を利用できるようにしたいと考えています。 - いずれにせよ、ソートを最適化することは、インデックス構築時間を最適化することを意味します)。
ただし、並べ替えアルゴリズムは、データ サイズによって大きく異なります。小さな配列の場合、挿入ソートが適切に実行されることは既知の事実です (実際、ほとんどのクイックソートの実装は、特定のしきい値を下回ると挿入ソートにフォールバックします)。理論ではなく、ソート理論では考慮されていない CPU パイプラインとコードサイズの影響によるものです。
そのため、現在、特定のニーズに最適な組み合わせを見つけるために、いくつかの並べ替えの実装をベンチマークしています。より柔軟な実装を、JDK のデフォルトの実装 (すでに微調整されていますが、おそらく別の JDK バージョン用) と同等にしたいと考えています。
長期的には、これらを簡単に再現して再実行できるようにする必要があります。ある時点で、JDK8 が表示されます。また、Dalvik VM では、結果が Java 7 とは異なる場合もあります。AMD、Core i7、および Atom CPU でも結果が異なる場合があります。そのため、Cervidae にはさまざまな並べ替え戦略が含まれており、クラスの読み込み時間に最も適したものを選択する可能性があります。
私の現在の取り組みは GitHub にあります: https://github.com/kno10/cervidae
それでは、実際の質問に移ります。最新のキャリパー コミットでは、マクロベンチマーク用の実験的なコードが追加されました。ただし、両方が必要であるという問題に直面しています。ランタイムがタイマー分解能の 0.1% 未満の場合、Caliper マクロベンチマークは失敗します。10000 個のオブジェクトで、一部のアルゴリズムがこのしきい値に達します。同時に、マイクロベンチマークは、実行に時間がかかりすぎる場合にマクロベンチマークを実行する必要があると不平を言います...
したがって、さまざまな並べ替えサイズのベンチマークを実行するには、実際には、ランタイムに応じてマイクロベンチマークからマクロベンチマークに動的に切り替えるアプローチが必要です。実際、実行時間がマクロ ベンチマークに十分な大きさであることをキャリパーが自動的に認識し、1 回の反復を実行するだけでよいとさえ思います。
現在、次を使用してこれをエミュレートしようとしています。
@Macrobenchmark
public int macroBenchmark() { ... }
public int timeMicroBenchmark(int reps) {
int ret = 0;
for (int i = 0; i < reps; i++) {
ret += macroBenchmark();
}
}
両方のシナリオでベンチマーク コードを共有します。代替コードを使用することです
@Macrobenchmark
public int macroBenchmark() {
return timeMicroBenchmark(1);
}
public int timeMicroBenchmark(int reps) { ... }
2つの「アダプター」のどちらが好ましいですか? ミクロからマクロまで一貫したベンチマークを取得するための他のヒントはありますか?
キャリパーの WebUI が現在機能していないことを考えると、結果の分析には何を使用しますか? 現在、小さな Python スクリプトを使用して JSON の結果を処理し、加重平均を報告しています。実際、Web UI よりも古いテキスト レポートの方が気に入りました。
ベンチマーク ループで Hotspot コンパイルが発生したときに、Caliper にベンチマークを再実行させる方法はありますか? 現在、エラーが記録されていますが、ベンチマークのその部分を再起動することはできますか?