問題タブ [microbenchmark]

私は持っている$date_string = '12/1/2014';

私は欲しい：

1. タイムスタンプ番号に解析する (DB に保存する)
2. そして、そのタイムスタンプを解析して、別の形式で出力します。December 1, 2014

私は、DateTime クラスを使用することが推奨される方法であると想定しています (個人的には非常に便利だと思います)。

ただし、両方の解析操作を実行する最速の方法は何か知りたいです。

DBから転送される非常に大量のデータを必要とするアプリでの作業。これには、SELECTクエリとUPDATEクエリの両方が含まれます（つまり、DBへの読み取りと書き込み）。

まず、すべての製品のリストを取得する必要があります（約1000 SKU）。SELECTクエリは非常に単純です。

次に、各製品に対していくつかの自動更新が行われます。UPDATEクエリは次のようなものです。

ここで問題となるのは、すべてのレコードを一度に操作する単一のクエリ、または各製品を個別に処理するPHPループ（foreachまたはwhile）（1000個の単一行クエリ）のどちらを実行するのが速いか、または優れているかです。もちろん、後者にはとが必要ですWHERE model = 'ABC'。LIMIT 1

問題をより複雑に（そして包括的に）するために、他の影響を与える基準を考えてください。

• 異なる数の行がターゲットにされた場合はどうなりますか：100または100,000？
• 複数のテーブルが関係している場合はどうなりますか？以下のJOINedクエリの例を参照してください。

。

この状況またはその状況でどちらの方法が優れているかを判断するための一般的な「経験則」はありますか？

私は、lmbench の作成者によるMHZ - Anatomy of a Benchmark の論文を読んでいて、ソースと一緒にコードを閲覧していました。

1. ペーパーは @ MHz からダウンロードできます: マイクロベンチマークの解剖学
2. ソース コードlmbench-3.0は Carl Staelin と Larry McVoy によって作成されました

BENCH_INNER() マクロの内部では、疑問があります:

1. 私が理解したことから、BENCH_INNER は、選択したタイミング間隔 (「十分」) の最適な反復回数を自動計算するために使用されます。ループは、5 ミリ秒から 1 秒の範囲で選択したタイミング間隔の少なくとも 95% を占めるコード「loop_body」を反復し続けるまで実行されます。

2. 簡単にするために、「十分」に 10000 マイクロ秒を考えてみましょう

3. __iterations = 1 から始めます
4. 時間の経過とともに、__result > 1.2 * '十分な'、つまり __result > 12000 マイクロ秒の段階に到達したとします。
5. ここで __result > 150 マイクロ秒なので、先に進んで __iterations の値をスケーリングし、__result が 1.1 * '十分' にほぼ等しくなるようにします。
6. しかし、__result を再計算する前に、以前の __result > .95 * 'enough' であるため、ループを中断します。
7. 先に進み、__result の値と変更された値 __iterations を保存します (ここで __result の値は、保存した __iterations の値ではありません)。

そのような場合、コードは __result を再計算すべきではありませんか? 私は何か基本的なことを見逃しましたか?

重複の可能性:
Java 例外はどれくらい遅いですか?

次の 2 つのプログラムの実行には、ほぼ同じ時間がかかります。

ただし、次の 2 つのプログラムにかかる時間は比較的異なります。

単純な try/throw/catch メカニズムは、少なくとも部分的に末尾呼び出しが最適化された戻り値のように見えると思います (そのため、制御がどこに戻る必要があるか (最も近いキャッチ) が直接わかります)。もちろん、JRE の実装では多くの最適化が行われます。

なぜ後者には大きな違いがあるのに前者には違いがないのでしょうか? 制御フロー分析により、前の 2 つのプログラムがほとんど同じであると判断され、実際の try/throw/catch が特に遅いためか、Returnfindがメソッド呼び出しを回避するレベルに展開され、Throw のプログラムがメソッド呼び出しを回避できないためでしょうか。 、 また ..？ありがとう。

編集: この質問は、Java の例外はどれくらい遅いですか? とは異なるようです。これは、このようなケースでなぜこれほど大きな違いがあるのか​​を尋ねていないからです。また、例外オブジェクトの作成に時間がかかるという事実も無視します (fillInStackTraceオーバーライドされない限り、スタックを走査してその配列を作成するなどの処理が含まれます)。しかし、それはどうやら私の質問の一部に答えているようです。おそらく、実際のスロー/キャッチ操作を矮小化するでしょう—複雑な分析を行ってスタックが決して見られないと判断しない限り、@Stephenの答えは奇妙になります)。

buffered 0.030000 seconds が「より良い」 buffered 0.030000 seconds と同じなのはなぜですか? ラインサイズを 4 倍にしても時間が変わらない場合、どうすればさらに高速化できますか?

テスト

コード

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 回の反復を実行するだけでよいとさえ思います。

現在、次を使用してこれをエミュレートしようとしています。

両方のシナリオでベンチマーク コードを共有します。代替コードを使用することです

2つの「アダプター」のどちらが好ましいですか? ミクロからマクロまで一貫したベンチマークを取得するための他のヒントはありますか?

キャリパーの WebUI が現在機能していないことを考えると、結果の分析には何を使用しますか? 現在、小さな Python スクリプトを使用して JSON の結果を処理し、加重平均を報告しています。実際、Web UI よりも古いテキスト レポートの方が気に入りました。

ベンチマーク ループで Hotspot コンパイルが発生したときに、Caliper にベンチマークを再実行させる方法はありますか? 現在、エラーが記録されていますが、ベンチマークのその部分を再起動することはできますか?

次の Groovy コードのスニペットで、予想外のベンチマーク結果が得られました。

コンパイル済みのクラス ファイルを使用し、それを Reflection API で呼び出したと言わざるを得ません。語るべき長い話 (聞かないでください ;)。第一印象として、私は 10 ラウンド + 5 回のウォームアップを 10000 ループで使用しました。(junit-benchmark フレームワーク) 私の JDK は Verison 1.7.0_09 で、Groovy 2.1 を使用しました。このコードは、invokedynamic サポートありとなしで 2 回コンパイルしました。要点は、invokedynamic を使用したベンチマークは、通常のコンパイル済みのものよりもはるかに長い時間がかかったということです。また、フィボナッチ数を使用して他のベンチマークも行いましたが、予想どおりに動作しました (indy は約半分の時間かかりました)。

ここで何が問題なのか誰か知っていますか？

ありがとう。