実行中のベンチマークの JSON 結果ファイルをアップロードしようとすると、複数のHTTP 500エラーが表示されます。Caliperログには、次のような例外が多数記録されます。

ただし、レポートは/runs私のアカウントのページに表示されるので、少なくとも一部はアップロードできるようです。失敗した試行のいずれかで指定された URL に対してacurl POSTを実行すると、同じエラーが発生します。

他の誰かがこれらのエラーに遭遇しましたか? 構成に欠けているものはありますか?

キャリパーconfig.properties:

キャリパーのバージョン:

システムプロパティ：

また、エラー ログは、失敗した結果を手動でアップロードすることを提案します。しかし、 Microbenchmarks Appspot ページに結果をアップロードするためのオプションが表示されません。

編集 1: ベンチマーク起動コマンド:

microbenchmark Rパッケージの機能のいくつかを知るようになりました。Hadley Wickham のこの出版物からサンプル コードを実装したところ、正確な情報が見つからず、対処できないエラーが表示されました。説明/ヒントなどをよろしくお願いします。

コード例:

コンソール出力:

アップデート。これが私のseesionInfo()コンソール出力です：

UPDATE 2.パッケージの作成者が私に求めた詳細情報:

• R変数R.version

  R.version _
  platform x86_64-w64-mingw32
  arch x86_64
  os mingw32
  system x86_64, mingw32
  status
  major 3
  minor 0.2
  year 2013
  month 09
  day 25
  svn rev 63987
  language R
  version.string R version 3.0.2 (2013-09-25) ニックネームフリスビーセーリング

• コンピューターの CPU のメーカー、モデル、および速度:

プロセッサ: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz 3.70 GHz

RAM: 16.0GB

システム タイプ: 64 ビット

更新 3。

上記のコードの変更の 1 つが正しい結果を返すことに気付きました。

その時点でサイズがわかっている場合は、コンストラクターCollectionにサイズを渡す方が良いですか? 拡張と割り当て/再割り当てCollectionに関する節約効果は顕著ですか?Collection

Collectionの最小サイズがわかっているが、上限がわからない場合はどうなりますか。少なくとも最小限のサイズで作成する価値はありますか?

Google の Caliper プロジェクトを使用して、いくつかのマイクロベンチマークを作成するよう依頼されました。最新のベータ スナップショットの注釈機能を使用したいと思っていますが、いくつかの小さな例を除けば、実際に実行する方法に関する適切なドキュメントを見つけるのに苦労しています... ユーザーに指示するビデオ チュートリアルがあります。新しい Maven 統合機能も使用しないように求められました。

現在、私は別のSOの質問から収集した他の情報で変更された、彼らの1つから取り除かれた小さな例を持っています:

実行すると、サイズのデフォルト値を設定していないというメッセージが表示されます。どこに置くべきかを追跡するのに苦労しています。

@Param 行をコメントアウトして「サイズ」を完全に削除し、setUp の配列宣言に厳密な値を指定すると、「実行する実験はありません」と判断されますが、これは理にかなっていると思います。

私が間違っていることを指摘できる最新のリソースやチュートリアルがあれば (おそらく、正直なところ、かなりの数)、私は非常に感謝しています。

編集：

私はいくつかのアドバイスに従ってこれに更新しました：

ベータ スナップショットを実行し、Benchmarks クラスを引数として渡しています。私は以下を受け取ります：

インストゥルメントを検出していないようです。ドキュメントには、デフォルトの割り当てであるランタイムを使用するだけであると記載されているため、渡していません（これは私の目的には問題ありません）。

ダブル編集：その問題、ばかげた間違いを見つけました。確認次第、簡単に追記します。

世代別ガベージ コレクターがアプリケーションのパフォーマンスに及ぼす微妙な影響を調査しているときに、書き込まれた値がプリミティブか参照かに関して、非常に基本的な操作 (ヒープの場所への単純な書き込み) のパフォーマンスに驚くべき矛盾があることに気付きました。

マイクロベンチマーク

結果

ループ全体がほぼ 8 倍遅いため、書き込み自体はおそらく 10 倍以上遅くなります。何がこのような減速を説明できるのでしょうか?

プリミティブ配列の書き込み速度は、1 ナノ秒あたり 10 回を超えます。おそらく、私は自分の質問の反対側を尋ねるべきです:何が原始的な書き込みをそんなに速くするのですか? （ところで、私がチェックしたところ、時間は配列サイズに比例してスケーリングします。）

これはすべてシングルスレッドであることに注意してください。指定する@Threads(2)と両方の測定値が増加しますが、比率は似ています。

ちょっとした背景:カード テーブルと関連する書き込みバリア

Young 世代のオブジェクトは、Old 世代のオブジェクトからのみ到達可能である可能性があります。ライブ オブジェクトの収集を避けるために、YG コレクターは、最後の YG コレクション以降に旧世代領域に書き込まれたすべての参照を認識している必要があります。これは、カード テーブルと呼ばれる一種の「ダーティ フラグ テーブル」で実現されます。このテーブルには、512 バイトのヒープのブロックごとに 1 つのフラグがあります。

スキームの「醜い」部分は、参照のすべての書き込みにカードテーブル不変条件が付随しなければならないことに気付いたときに発生します-コードの一部を維持します: 書き込まれるアドレスを保護するカードテーブル内の場所をマークする必要があります汚れています。このコードは書き込みバリアと呼ばれます。

特定のマシンコードでは、これは次のようになります。

書き込まれた値がプリミティブである場合、同じ高レベルの操作に必要なのはこれだけです。

書き込みバリアは、「ちょうど」もう 1 つの書き込みに寄与しているように見えますが、私の測定では、1 桁の速度低下を引き起こすことが示されています。これは説明できません。

UseCondCardMark悪化させるだけ

エントリがすでにダーティとマークされている場合、カード テーブルへの書き込みを回避するはずの、非常にわかりにくい JVM フラグがあります。これは主に、多くのカード テーブルへの書き込みによってCPU キャッシュを介したスレッド間での誤った共有が発生する、いくつかの縮退したケースで重要です。とにかく、私はそのフラグをオンにしてみました：

質問を読んだ後、ソートされた配列の処理がソートされていない配列よりも速いのはなぜですか? 変数を volatile にしようとしました (volatile を使用すると動作が遅くなるはずですが、動作は速くなると予想していました) volatile を使用しないコードは次のとおりです: (動作時間は約 11 秒です。)

出力は次のとおりです。

これは、arraySize とデータ変数を揮発性として使用した場合で、約 7 秒で動作します。

volatile を使用した出力は次のとおりです。

揮発性でプロセスが遅くなると思っていたのですが、より速く動作しています。何が起こったか？

この投稿で行ったのと同じテストを行いました: new String() vs リテラル文字列のパフォーマンス

つまり、どちらがパフォーマンスが優れているかをテストしたかったのです。予想通り、リテラルによる代入の方が速いという結果になりました。理由はわかりませんが、いくつかの割り当てを追加してテストを行ったところ、何か奇妙なことに気付きました: プログラムに 10.000 回を超えるループを実行させると、リテラルによる割り当ては、割り当てが 10.000 未満の場合よりも比較的高速ではありません。 . また、1.000.000 回の繰り返しでは、新しいオブジェクトを作成するよりもさらに遅くなります。

これが私のコードです：

上記のように実行します。私はJavaを学んでいるのですが、上司からテストをするように言われ、テストの結果を提示した後、なぜこれが起こるのか、答えを見つけるように言われました。グーグルやスタックオーバーフローで何も見つからないので、誰かが私を助けてくれることを願っています.

ありがとうございました！

配列がビットごとの and を介して計算されるときに境界チェックを排除できるかどうかを調べるために、簡単なベンチマークを作成しました。これは基本的に、ほぼすべてのハッシュ テーブルが行うことです。

へのインデックスとして、tableはhまたはhashCode派生値です。結果は、境界チェックが排除されていないことを示しています。

私のベンチマークの考え方は非常に単純です。2 つの値iと を計算jします。両方とも有効な配列インデックスであることが保証されています。

• iループカウンターです。配列インデックスとして使用されると、境界チェックがなくなります。
• jとして計算されます。x & (table.length - 1)ここで、xは反復ごとに変化する値です。配列インデックスとして使用される場合、境界チェックは排除されません。

関連する部分は次のとおりです。

他の実験では

代わりは。タイミングの違いはおそらく 15% です (私が試したさまざまなバリアントでほぼ一貫しています)。私の質問:

• これには、バウンドチェックの排除以外に考えられる理由はありますか?
• バウンドチェックの削除がない理由がわからない複雑な理由がありますjか?

回答の要約

MarkoTopolnik の答えは、それがすべてより複雑であり、境界チェックの排除が勝利であるとは限らないことを示しています。特に彼のコンピューターでは、「通常の」コードは「マスクされた」コードよりも遅くなります。これは、この場合実際に有害であることが示されている追加の最適化を許可しているためだと思います（現在のCPUの複雑さを考えると、コンパイラーは確実に知ることさえほとんどありません）。

leventovの答えは、配列の境界チェックが「マスク」で行われ、それを排除することでコードが「通常」と同じくらい高速になることを明確に示しています。

x & (0-1)Donal Fellows は、長さが 0 のテーブルではマスキングが機能しないという事実を指摘していますx。したがって、コンパイラが実行できる最善の方法は、バウンド チェックを長さ 0 のチェックに置き換えることです。しかし、長さゼロのチェックはループから簡単に移動できるため、これはまだ価値があります。

提案された最適化

a[x & (a.length - 1)]if and only ifの等価スローa.length == 0により、コンパイラは次のことを実行できます。

• 配列アクセスごとに、インデックスがビットごとの and を介して計算されているかどうかを確認します。
• その場合、いずれかのオペランドが長さから 1 を引いたものとして計算されたかどうかを確認してください。
• その場合は、境界チェックを長さゼロのチェックに置き換えます。
• 既存の最適化に任せましょう。

このような最適化は、SSAグラフの親ノードのみを参照するため、非常にシンプルで安価です。多くの複雑な最適化とは異なり、1 つのチェックをわずかに単純なチェックに置き換えるだけなので、有害になることはありません。そのため、ループの外に移動できなくても問題はありません。

これを hotspot-dev メーリング リストに投稿します。

ニュース

John Rose がRFEを提出し、すでに「簡単な」パッチがあります。