問題タブ [xeon-phi]

From this https://software.intel.com/en-us/videos/purpose-of-the-mic-architecture I understand that applications with complex or numerous random memory access are not well suited for Intel Xeon-phi. This is because the architecture uses 61 cores and 8 memory controllers. In case of L1 and L2 cache misses, it takes up to 100s cycles to fetch the line into memory and get it ready for use by the CPU. Such applications are called latency-bound.

Then, the tutorial mentions that many-core architecture (Xeon-phi coprocessor only) are well suited for highly parallel homogeneous code. Two questions from there:

1. What is referred to as homogeneous code ?

2. What are real-world applications which can fully benefit from MIC architecture ?

現在、インテルが提供する GDB バージョン (gdb-mic) を使用して、Xeon Phi のネイティブ アプリケーションをデバッグしようとしています。Phi にログインしているときにプログラムを実行すると、LD_LIBRARY_PATH=/tmp (以前に libiomp5.so を転送した場所) を設定していれば動作します。

しかし、GDB を使用してアプリケーションをデバッグすると、ライブラリ パスを設定できません。コマンド「set env LD_LIBRARY_PATH=/tmp」を試しましたが、GDB はまだ libiomp5.so を見つけられません。

以前にその問題に遭遇した人はいますか?

ありがとう ！

Intel のいくつかのドキュメントによると、Xeon Phi のコアは 1 サイクルあたり最大 2 つの命令を発行できることを理解しています。U パイプに 1 つ、V パイプに 1 つ。次のドキュメントでは、フロントエンドがラウンドロビン方式で複数のコンテキスト間を切り替えると記載されています。これらの 2 つの命令は同じコンテキストから来ていますか? または、それらは異なるコンテキストから来ることができますか? できないと思いますが、これに関する詳細なドキュメントは見つかりませんでした。

インテル Xeon Phi コプロセッサー・パイプラインのフロントエンドについて知っておくべきもう 1 つの重要な点は、同じハードウェア コンテキスト (ハードウェア スレッド) から 2 クロック サイクル連続して命令を発行しないことです。実行中。そのため、発行率を最大にするには、少なくとも 2 つのハードウェア コンテキストが実行されている必要があります。複数のコンテキストが実行されている場合、フロントエンドはそれらをラウンドロビン方式で切り替えます。

ソース: https://software.intel.com/en-us/articles/optimization-and-performance-tuning-for-intel-xeon-phi-coprocessors-part-2-understanding

また、ベクトル命令とスカラー命令があると仮定すると、フロントエンドは U パイプでベクトル命令を発行し、V パイプでスカラー命令を発行して最大発行レートを達成しますか? V パイプがベクトル命令の小さなサブセットしか実行できないことを考えると、これら 2 つのパイプラインの実際の使用が発行率に影響するのではないかと思います。

コアは 2 幅のプロセッサで、サイクルごとに 2 つの命令を実行できます。1 つは U パイプで、もう 1 つは V パイプです。また、必要に応じて浮動小数点命令を実行する x87 ユニットも含まれています。

...

ベクトル ユニットはコアと通信し、U または V パイプラインに割り当てられたベクトル命令を実行します。コアはクロックごとに 2 つの命令を実行できます。1 つは U パイプで、もう 1 つは V パイプで実行されます。V パイプは命令のサブセットを実行し、最適なプロセッサ パフォーマンスを得るために重要な命令ペアリング ルールによって管理されます。

ソース: https://software.intel.com/en-us/articles/intel-xeon-phi-core-micro-architecture

最新のプロセッサは、メモリ アクセスと計算をオーバーラップさせます。Intel Xeon Phi でこのオーバーラップを調査したいと考えています。これを行う従来の方法は、コードを変更して、このスライドで GPU に使用されているアプローチのように、メモリのみと計算のみの 2 つのバージョンを作成することです: http://www.nvidia.com/content/GTC-2010/ pdfs/2012_GTC2010.pdf .

しかし、私のプログラムには複雑な制御フローとデータの依存関係があります。このような 2 つのバージョンを作成するのは非常に困難です。

この重複を測定する便利な方法はありますか? Vtune プロファイルを検討していますが、どの HW カウンターを見ればよいかまだわかりません。

xeon phi コアで vtune を実行したところ、シングル スレッド ベンチマークで 0.777 の CPI が得られました。ただし、単一スレッドの理論上の最大 CPI は 1.0 であるため、これが真実である可能性はほとんどありません。( https://software.intel.com/en-us/articles/optimization-and-performance-tuning-for-intel-xeon-phi-coprocessors-part-2-understandingで「理論 CPI」を検索してください)

vtune スレッド情報を確認して、他のスレッドが実行されていないことを確認しました。

1. VTune CPI 情報:

Function / Call Stack Clockticks Instructions Retired CPI Rate Retiring Bad Speculation Back-End Bound Front-End Module Function (Full) ソースファイル開始アドレス

上記の情報から、CPI は 0.777 です。

2. 関数 centered_3d の VTune スレッド情報:

239.616s -- 同時に使用される論理 CPU = 0

163.632s -- 同時に使用される論理 CPU = 1

上記の情報は、vtune が間違った計算を行っていることを意味しますか? 例: サイクル数または命令数を正しくカウントしない可能性はありますか?

インテルの Web サイトから MPSS ソフトウェア スタック バージョン 3.5.2 のソース コードをダウンロードしました。xeon phi 移植 GCC (GCC 4.7.0 から移植) をソースからコンパイルし、ローカル サブディレクトリにインストールしようとしています。ただし、次のエラーが発生します-

私の構成は次のとおりです-

Makefile が を呼び出しているのはなぜk1om-mpss-linux-gccですか? これは、make が完了した後のクロス コンパイルされた gcc バイナリであってはなりませんか? どうすればこれを修正できますか、または何が欠けていますか?

編集 1: 構成パラメーターを に変更しました--build=x86_64-mpsssdk-linux --host=x86_64-mpsssdk-linux。次のエラーが表示されます-

gtype-desc.cはマシン生成ファイルです。

EDIT 2:私は今、エラーが発生しています-

どうすればこれを修正できますか? これらはベクトル命令のように見えますが、gcc クロス コンパイラはベクトル命令をサポートしていないと思いました。