問題タブ [intel-vtune]

インテルVTuneアンプXEで同じテスト（たとえば、軽量ホットスポット）を複数回実行する方法はありますか？1回のテストを実行するために複数回クリックするのは面倒です。ドキュメントを調べましたが、何も見つかりませんでした。
ありがとう ！

さまざまな最適化フラグを使用してFortranプログラムをコンパイルしました。デフォルトの最適化フラグ-O2を持つ1つのプログラムと、-fast最適化フラグを持つ別のコンパイル済みプログラムがあります。最適化フラグ-O2でコンパイルされたプログラムを開くことができました。したがって、Vtuneにプログラムをロードしようとすると、プログラムも実行されますか？

ただし、最適化フラグ-fastを使用してコンパイルされたプログラムをロードしようとすると、Vtuneは「結果の確定に失敗しました」というエラーをスローします。開いている結果は空です。これは、データ収集中のエラーが原因である可能性があります。これは実際にはどういう意味ですか？私はこのフォーラムの他のスレッドを調べましたが、それが何を意味するのか完全には理解できませんでした。

私が受け取ったコレクターメッセージは次のとおりです。

エラー：分析ターゲットのバイナリファイルに、プロファイリングに必要なシンボルが含まれていません。詳細については、ドキュメントを参照してください。エラー：有効なdlopenシンボルが分析ターゲットの静的バイナリに見つかりません。

私はubuntu12.04システムを使用しています。

本当にありがとう。すぐに返信してください。

Jdbaba

趣味のプログラムを使用して、ハイ パフォーマンス コンピューティングのテクニックを独学しています。

私の PC には、32 GB のメモリと Microsoft vs2010 C コンパイラの無料バージョンを備えた Intel Ivy Bridge Core i7 3770 プロセッサが搭載されています。

64 ビット プログラムには、4 GB のルックアップ テーブルが 5 つあるため、約 20 GB のメモリが必要です (以下の bytevecM ... bytevecX)。この検索プログラムの内側のループは、別の C ファイルとして記述されています (後でアセンブラー バージョンに置き換えたい場合があるため)。以下に示します。

ところで、上記のアルゴリズムは、開始範囲と終了範囲が異なる各スレッドで 1 つのコピーを実行することで、簡単に並列化できることに注意してください。

直感、Intel 組み込み関数、および各変更の個別のベンチマークを使用して、以下に示すように、実行時間を約 5 時間から 3 時間に短縮することができました。

この高速化の大部分は、内側のループを手動で展開したことによるものです。

私は Intel SSE/AVX 命令に非常に慣れていないので、上記の何かを見て顔を引っ張った場合はお知らせください。

インテル VTune は、最大のホット スポットが次の行で発生すると報告しています。

対応するアセンブリ コードで、ホット スポットを以下に示します。

これは、「データの局所性」の問題のように思えます。内側のループを通過するたびに、m7 の値は 4 GB の範囲で激しく予測できないほど変化するため、qqm=bytevecM[m7^1] を検索するときに、最初の UNROLL(1) でキャッシュ ミスが発生する可能性があります。

後続の UNROLL(2)..UNROLL(127) xor m7 と 2..127 があるため、通常、残りの UNROLL でキャッシュ ヒットが発生します。興味深いことに、UNROLL(96) を UNROLL(1) の直後に移動して UNROLL の順序を変更すると、大幅な速度向上が見られました。

メモリからバイトを読み取ると、そのバイトを含む (64 バイト) キャッシュ ラインがいっぱいになることを理解しています。

私はこの分野に非常に慣れていないので、特に大きなテーブル (私の場合は 4 GB テーブル) を扱う場合に、メモリ ルックアップを高速化する方法に関するアドバイスや参考文献を歓迎します。

上記のアルゴリズムでデータの局所性を改善する明確な方法がわかりません。それがどのように達成されるかについての提案も歓迎します。

2013 年 3 月 29 日更新

このノードが作成されてから、以下に示すように、実行時間を 3 時間から 20 分にさらに短縮することができました。

4 GB の bytevec ごとに 4 MB のビットマップを追加すると、約 40 分に短縮され、_mm_prefetch 呼び出しを追加することでさらに半分になりました。

基本的なアルゴリズムは変更されていないことに注意してください。ビットマップを追加することでデータの局所性が改善されました。_mm_prefetch 呼び出しを追加することで、レイテンシが短縮されました。

さらなるパフォーマンス改善のための提案を歓迎します。改善されたプログラムは次のとおりです。

最初の質問から続けて、64 ビット C プログラムの VTune プロファイリングで見つかったメモリ ホットスポットを最適化しようとしています。

特に、128 バイトのメモリ ブロックにすべてゼロが含まれているかどうかをテストする最速の方法を見つけたいと考えています。メモリ ブロックの任意のメモリ アラインメントを想定できます。64 バイトのアラインメントを使用しました。

私は、Intel Ivy Bridge Core i7 3770 プロセッサ、32 GB のメモリ、Microsoft vs2010 C コンパイラの無料バージョンを搭載した PC を使用しています。

私の最初の試みは：

対応するアセンブリの VTune プロファイリングは次のとおりです。

インテルの組み込み関数を使用して、それを改善できました。

対応するアセンブリの VTune プロファイリングは次のとおりです。

ご覧のとおり、アセンブリ手順が少なくなり、このバージョンはタイミング テストでさらに高速であることが証明されました。

私はインテルの SSE/AVX 命令の分野に非常に弱いので、このコードを高速化するためにどのように使用すればよいかについてのアドバイスを歓迎します。

利用可能な何百もの組み込み関数を精査しましたが、理想的な組み込み関数を見逃している可能性があります。特に、_mm_cmpeq_epi64(); を効果的に使用できませんでした。私はこの組み込み関数の「等しくない」バージョン (この問題により適しているようです) を探しましたが、結果は未熟でした。以下のコードは「機能します」が：

それは判読不能の境界線上にあり、(当然のことながら) 上記の 2 つのバージョンよりもはるかに遅いことが証明されています。_mm_cmpeq_epi64() を使用するよりエレガントな方法が必要であると確信しており、それを実現する方法についてのアドバイスを歓迎します。

C の組み込み関数を使用することに加えて、この問題に対する未加工の Intel アセンブリ言語ソリューションも歓迎されます。

Linuxプラットフォームでc++で記述されたコードを最適化したいと思います。そのために、Intel VTune Performance Analyzer Profilerを使用しています。ホットスポットを特定すると、パスを指定したバイナリ実行可能ファイルが正常に実行され、エラーが発生します。データを表示できません。データに使用できる視点がありません"。

誰かがこのエラーをソートするのを手伝ってもらえますか？

以前の 2 つの質問、「64 ビット C/インテル アセンブリ プログラムのメモリ パフォーマンス/データ ローカリティを改善する方法」と「 C/インテル アセンブリを使用して」に続いて、128 バイトのメモリ ブロックにすべてゼロが含まれているかどうかをテストする最速の方法は何ですか? 、以下で説明するように、これらの質問で言及されているテスト プログラムの実行時間を 150 秒から 62 秒にさらに短縮しました。

64 ビット プログラムには、5 つの 4 GB ルックアップ テーブル (bytevecM、bytevecD、bytevecC、bytevecL、bytevecX) があります。最後の質問で分析した (膨大な) キャッシュ ミス数を減らすために、ルックアップ テーブルごとに 1 つずつ、5 つの 4 MB ビットマップを追加しました。

元の内部ループは次のとおりです。

この単純な「事前チェック」の背後にある考え方は、128 バイトすべてがゼロの場合にコストのかかる内部ループを回避することでした。ただし、プロファイリングでは、前回説明したように、膨大な数のキャッシュ ミスが原因で、この事前チェックが主要なボトルネックであることが示されました。そこで、事前チェックを行うために 4 MB のビットマップを作成しました。(ところで、128 バイト ブロックの約 36% はゼロであり、前回誤って報告した 98% ではありません)。

以下は、4 GB のルックアップ テーブルから 4 MB のビットマップを作成するために使用したコードです。

これを行うためのより良い方法の提案は大歓迎です。

上記の関数で作成されたビットマップを使用して、次のように、4 GB のルックアップ テーブルではなく 4 MB のビットマップを使用するように「事前チェック」を変更しました。

これは、単純なシングルスレッドの場合、実行時間が 150 秒から 62 秒に短縮されたという点で「成功」しました。ただし、以下に示すように、VTune は依然としてかなり大きな数値を報告します。

異なる範囲で 8 つの同時スレッドを実行する、より現実的なテストのプロファイルを作成しました。ゼロ ブロックの内部ループ チェックの VTune 出力を以下に示します。

それに加えて、（紛らわしいことに）多くの時間がこの行に起因していました。

上記の VTune 出力の大きな数字を完全には理解していません。誰かがこれらの数字にもっと光を当てることができれば、私はすべて耳を傾けます.

私の 5 つの 4 MB ビットマップは、私の Core i7 3770 プロセッサが 8 MB の L3 キャッシュに収まるサイズよりも大きく、多くのキャッシュ ミスが発生しているように思えます (ただし、以前よりははるかに少なくなっています)。私の CPU に 30 MB の L3 キャッシュがあれば (今後の Ivy Bridge-E のように)、5 つのビットマップすべてが L3 キャッシュに快適に収まるため、このプログラムははるかに高速に実行されると思います。そうですか？

それに加えて、ビットマップをテストするコードは次のとおりです。

このコードを高速化するための提案は大歓迎です。

Vtune Profiler APIを使用して、Xeon Phi（Linux、オフロード実行を使用）で実行されているコードをプロファイリングして、実行された命令の数、L1キャッシュミスの数などを確認したいのですが、使用方法を説明する場所が見つかりません。このライブラリ。

Linuxのライブラリファイルとインクルードファイルはどこにありますか？Xeon Phiで実行されている短いコードをプロファイリングするコードを作成するにはどうすればよいですか？

私はこのようなものを期待します：

ありがとう

Intel Vtune Amplifier XE 2013 を使用して、マルチコア CPU で実行されている並列プログラムをプロファイリングしています。特に、OpenCL で記述され、Xeon Phi で実行されています。Vtune によってもたらされた結果の正確な解釈はどうあるべきだろうか、つまり、

1. 単一のスレッドまたはコア全体によって収集されたパフォーマンス カウンターの値ですか? (Xeon Phi の場合のように、CPU に多くのコアがあり、多くのスレッドをコアで同時に実行できると仮定します)。
2. Vtune はマルチコア CPU でどのようにサンプリングしましたか? 単一のコアでサンプリングして報告したか、それとも多数のコアでサンプリングして平均をとったか?

Linux アプリケーションの hotspot collect にインテル(R) VTune(TM) Amplifier XE 2013 Update 5 (ビルド 274450) を使用していますが、レポートには「[既知のモジュールの外側]」がほとんどの時間を消費していると書かれているので、不明なモジュールに関する詳細情報を取得します。

vtune Amplifier のリリース ノートを読むと、「カーネルが 2.6.20 (200233501) より古いシステムでは、ホットスポットのリストに "既知のモジュールの外部" が含まれている可能性があります」とありますが、私の Linux カーネルは「2.6.32」です。これについて何か考えはありますか？

このコードを最適化しようとしています。

インテル VTune は、プロセッサ時間の約半分がループ内の 2 行ではなく、 2 番目のfor 命令に費やされていることを示しています。アセンブリ ソースを展開すると、c++ 命令が多数のオペコードに変換されていることがわかります。そのうちの 3 つは CPU 時間を浪費しているようです。 for for

単純な移動と比較に時間がかかる理由がわかりません。