問題タブ [benchmarking]

実際のハードウェアとは対照的に、仮想マシン内で実行されるベンチマークはどの程度信頼できますか？

特定の状況を分析してみましょう。最近のコード変更によるパフォーマンスへの影響をベンチマークしたいとします。簡単にするために、ワークロードは完全にCPUバウンドであると想定します（ただし、IOバウンドおよび混合ワークロードも重要です）。マシンがVirtualBoxで実行されていると仮定します。これは、最適なマシンだからです;）

元のコードと新しいコードを測定し、新しいコードが5％高速であったと仮定します（仮想マシンでベンチマークした場合）。実際のハードウェアでも少なくとも5％高速になると安全に主張できますか？

そしてさらに重要な部分は、新しいコードが3％遅いと仮定します。実際のハードウェアでは3％以下遅くなるが、間違いなく3％以上遅くなることを完全に確信できますか？

更新：私が最も興味を持っているのは、戦場での結果です。つまり。VMで10％遅いコードが、実際のアイアンで5％速く実行された場合、またはその逆の場合を目撃できますか？または、常に一貫性がありましたか（つまり、VMで高速/低速の場合、実際のマシンでは常に比例して高速/低速です）？これまでのところ、鉱山は多かれ少なかれ一貫しています。少なくとも、常に同じ方向に進んでいます。

ストップウォッチベンチマークを使用する人はいますか、それともパフォーマンスツールを常に使用する必要がありますか？Javaで利用できる優れた無料ツールはありますか？どのツールを使用していますか？

私の懸念を明確にするために、ストップウォッチのベンチマークは、オペレーティングシステムのスケジューリングが原因でエラーが発生する可能性があります。プログラムの特定の実行時に、OSは、タイミングをとっている関数の途中で別のプロセス（または複数）をスケジュールする場合があります。Javaでは、スレッド化されたアプリケーションの時間を計測しようとすると、JVMスケジューラーがさらに少しランダム性をミックスに投入するため、状況はさらに悪化します。

ベンチマーク時にオペレーティングシステムのスケジューリングにどのように対処しますか？

MIPSコード、GCC、またはLLVMに「最適な」フリー/ OSSコンパイラーとは何かを知りたいのですが、それよりも優れたものはありますか？

コードサイズよりも、高速でメモリに制約のある生成されたアセンブリコードについてもっと知りたいです。

言い換えれば、llvm-optはgcc -O3よりもうまく機能しますか？

これは私の好奇心を満たすための質問です。しかし、私にとっては興味深いものです。

この小さな単純なベンチマークを書きました。正規表現実行の 3 つのバリアントをランダムな順序で数千回呼び出します。

基本的に、同じパターンを使用しますが、異なる方法で使用します。

1. なしの通常の方法RegexOptions。.NET 2.0 以降、これらはキャッシュされません。ただし、かなりグローバルなスコープで保持され、リセットされないため、「キャッシュ」する必要があります。

2. とRegexOptions.Compiled

3. Regex.Match(pattern, input).NET 2.0 でキャッシュされるstatic への呼び出しで

コードは次のとおりです。

私がそれを呼び出すたびに、結果は次のようになります。

それで、あなたはそれを持っています。大したことではありませんが、約 7 ～ 8% の違いがあります。

謎はこれだけではありません。最初の方法が再評価されることはなく、グローバルな静的変数に保持されているため、最初の方法がそれほど遅くなる理由を説明できません。

ちなみに、これは .Net 3.5 と Mono 2.2 でまったく同じように動作します。Windows の場合。

それで、コンパイルされたバリアントが遅れる理由はありますか？

EDIT1：

コードを修正すると、結果は次のようになります。

これは、他のすべての質問もほとんど時代遅れです。

答えてくれてありがとう。

Google アナリティクスはパフォーマンスにどの程度影響しますか?

私は次のものを探しています：

• ベンチマーク (応答時間/ページ読み込み時間などを含む)
• 類似のベンチマークへのリンクまたは結果

サイトで Google アナリティクス (GA) をテストする (考えられる) 方法の 1 つ:

1. 独自のサーバーから ga.js (Google アナリティクス JavaScript ファイル) を提供します。
2. Google Daily (テスト 1) と Weekly (テスト 2) から更新します。

これにより、クライアント Web サーバーと GA サーバー間の通信がどのように減少するかを知りたいと思います。

誰かがこれらのテストのいずれかを実施しましたか? もしそうなら、あなたはあなたの結果を提供できますか？そうでない場合、GA を使用してパフォーマンス ヒット (またはその欠如) をテストするためのより良い方法はありますか?

＜背景＞

私は、C++ コードを最適化する必要があるところまで来ています。分子シミュレーション用のライブラリを作成していて、新しい機能を追加する必要があります。過去にこの機能を追加しようとしましたが、ネストされたループで呼び出される仮想関数を使用しました。私はそれについて悪い感情を抱いていました.そして最初の実装はこれが悪い考えであることを証明しました. ただし、これはコンセプトのテストには問題ありませんでした。

< /背景>

今、私はこの機能を可能な限り高速にする必要があります (アセンブリ コードや GPU 計算がなくても、これは C++ である必要があり、より読みやすくする必要があります)。テンプレートとクラス ポリシー (Alexandrescu の優れた本から) について少し理解が深まり、コンパイル時のコード生成が解決策になる可能性があると思います。

ただし、ライブラリに実装するという膨大な作業を行う前に、設計をテストする必要があります。問題は、この新機能の効率をテストする最良の方法についてです。

この g++ がないと (おそらく他のコンパイラも)、オブジェクト コードで不要な操作が保持されるため、明らかに最適化をオンにする必要があります。1e-3 秒のデルタが良い設計と悪い設計の違いを生む可能性があるため、ベンチマークで新しい機能を多用する必要もあります (この機能は、実際のプログラムで何百万回も呼び出されます)。

問題は、最適化中に g++ が「賢すぎる」場合があり、計算の結果が決して使用されないと見なすと、ループ全体を削除できることです。出力アセンブリ コードを見たとき、私はすでにそれを見たことがあります。

標準出力に出力を追加すると、コンパイラはループ内で計算を実行するように強制されますが、ほとんどの場合、iostream 実装のベンチマークを実行します。

では、ライブラリから抽出された小さな機能の正しいベンチマークを行うにはどうすればよいでしょうか? 関連する質問: この種のin vitro試験を小さなユニットで行うのは正しいアプローチですか、それとも全体のコンテキストが必要ですか?

アドバイスありがとう！

volatile微調整を可能にするコンパイラ固有のオプションから、またはのようなすべてのコンパイラで動作するはずのより一般的なソリューションまで、いくつかの戦略があるようですextern。

私はこれらすべてを試してみると思います。ご回答ありがとうございます。

私は、DateTime を使用して、C# コードの 1 行で非常に迅速で汚いベンチマークを行っています。

問題は結果にあります：

...等々。

開始時刻と終了時刻が同じであることを考えると、Ticks は明らかに粒度が十分ではありません。

では、パフォーマンスをより適切に測定するにはどうすればよいでしょうか。

最近、Microsoft の Composite UI Application ブロックで構築されたアプリケーションのパフォーマンスの問題、特に読み込みに時間がかかりすぎる問題のトラブルシューティングを依頼されました。

これは、リフレクション/属性を使用してクラスを登録する Microsoft の ObjectBuilder 依存性注入フレームワークを中心に構築されています。プロファイリングは、ObjectBuilder が登録するものを検索する際に読み込まれたすべてのアセンブリのすべての型をスキャンするため、起動時にアプリがリフレクションにかなりの時間を費やしていることを示しました。

代替の DI フレームワークはすべて、属性、XML 構成、または純粋なコードも使用しているようです。
他の属性ベースのフレームワークがこれ以上優れているとは思えません。また、大量の XML を解析する必要がある起動時間などについても懐疑的です。
純粋なコードベースのフレームワークは、はるかに高速であるように見えますが、柔軟性もはるかに低いため、明確な良い選択があるようには見えません...

これにより、DI コンテナーのベンチマークを検索するようになりましたが、見つけることができたのはhttp://www.codinginstinct.com/2008/04/ioc-container-benchmark-unity-windsor.htmlだけです。
これは優れたベンチマークですが、コンテナーを使用して 100 万個のオブジェクトをどれだけ速く作成できるかを測定するだけです。私は 100 万個のオブジェクトを作成することに興味はありません。アプリをできるだけ早く起動したいだけなので、探しているのは DI コンテナーの起動コストに関する情報です。ブログの投稿、逸話、または「ObjectBuilder を高速化する方法は次のとおりです」と簡単です。

前もって感謝します

私が作成したいくつかの API のパフォーマンスをテストするためのベンチマーク アプリケーションがあります。このベンチマーク アプリケーションでは、基本的に QueryPerformanceCounter を使用し、API を呼び出す前後の QPC 値の差を頻度で割ることによってタイミングを取得しています。しかし、別のドライブからアプリケーション (同じ Dll セットで実行されている同じ実行可能ファイル) を実行すると、ベンチマークの結果が異なるようです。また、特定のドライブでアプリケーションを初めて実行し、アプリケーションを閉じて再度実行すると、異なるベンチマーク結果が得られます。誰でもこの動作を説明できますか? ここで何か不足していますか？

さらに役立つ情報:

動作は次のようなものです。アプリケーションを実行し、閉じて再度実行すると、2 回目の実行でベンチマークの結果が改善されたように見え、その後は同じままです。この動作は、C ドライブから実行する場合により顕著になります。また、私のベンチマーク アプリには、アプリを閉じることなく特定の API を再実行/再テストするオプションがあることにも言及したいと思います。ジッティングが関係していることは理解していますが、アプリの最初の実行時に、アプリを閉じずにAPIを複数回再実行すると、数回実行した後にパフォーマンスが安定し、閉じて再実行すると、パフォーマンスが安定することを理解していません同じテストでは、パフォーマンスが向上しているようです。

また、異なるドライブから実行した場合のパフォーマンスの変化をどのように説明しますか?

【情報更新】

ngenを実行したところ、同じ場所からの異なる実行間のパフォーマンスの違いはなくなりました。つまり、ベンチマーク アプリを開いて一度実行し、閉じて同じ場所から再実行すると、同じ値が表示されます。

しかし、私は今別の問題に遭遇しました。D ドライブからアプリを起動して数回 (ベンチマーク プログラムの同じ起動内で API を 2 回反復) 実行すると、3 回目以降、すべての API のパフォーマンスが約 20% 低下するようです。 . 次に、アプリを閉じて再起動して実行すると、最初の 2 回の反復で正しい値 (C から取得した値と同じ値) が得られますが、パフォーマンスはそれを超えて低下します。この動作は、C ドライブから実行した場合には見られません。Cドライブからは、何回実行しても安定しています。

API のパフォーマンスをテストするために、大きな double 配列を使用しています。テストの合間に GC が起動するのではないかと心配していたので、各テストの前後に GC.Collect() と GC.WaitForPendingFinalizers() を明示的に呼び出しています。したがって、GCとは何の関係もないと思います。

3 回目以降は AQ time を使用して何が起こっているかを調べてみましたが、面白いことに、AQ time プロファイルを使用してアプリケーションを実行すると、パフォーマンスはまったく低下しません。

パフォーマンス カウンター as は、おかしな IO アクティビティを示唆していません。

ありがとうニランジャン