問題タブ [xeon-phi]

一部の計算を Xeon Phi にオフロードする予定ですが、最初に、さまざまな API とさまざまなアプローチで並列プログラミングをテストしたいと考えています。

Xeon Phi (Windows または Linux) 用のシミュレーター/エミュレーターはありますか?

opnecl の 2D 畳み込みでベンチマークされた Xeon Phi のパフォーマンスは、コンパイラー対応のベクトル化を使用した場合でも、openmp 実装よりもはるかに優れているようです。Openmp 版は phi ネイティブ モードで実行し、タイミングは計算部分 (For ループ) のみを測定しました。opencl の実装では、タイミングはカーネル計算のみであり、データ転送は含まれていませんでした。OpenMp 対応バージョンは、2、4、60、120、240 スレッドでテストされました。- バランスの取れたスレッド アフィニティ設定では、240 スレッドで最高のパフォーマンスが得られました。しかし、プラグマ対応のベクトル化がソース コードである 240 スレッドの openmp ベースラインでも、Opencl は約 17 倍優れていました。入力画像サイズは 1024x1024 から 16384x16384 まで、フィルターサイズは 3x3 から 17x17 までです。呼び出しの実行では、opencl は openmp よりも優れていました。これはopenclの予想される高速化ですか?? 本当であるには良すぎるようです。

編集：

コンパイル (openmp)

ソース (Convole.cpp):

ソース 2 (convolve.cl)

OpenMP の結果 (OpenCL との比較):

*生のカーネル実行時間。PCI バス経由のデータ転送時間は含まれていません。

ホストの openMP コードで intel のオフロード プラグマを使用しています。コードは次のようになります

MIC への $x$ のコード オフロード計算。このコードは、一部の openMP を CPU コアに割り当ててビジー状態に保ちます。上記のコードは期待どおりに機能します。ただし、最初のオフロード プラグマは時間がかかり、ボトルネックになっています。それにもかかわらず、全体として、$x$ の計算を MIC にオフロードすることは報われます。私が試みているこの遅延の問題を潜在的に克服する1つの方法は次のとおりです

SO この新しいコードは、オフロードを実行するスレッドを割り当てますが、他の openmp スレッドは他のワークシェアリング構造に使用できます。ただし、このコードは機能しません。次のエラーメッセージが表示されます

オフロード レポートは、上記のコードが主な原因であることを示しています。一時的な回避策の 1 つは、信号として定数を使用することです。つまり、signal(0) が機能します。ただし、より永続的な解決策が必要です。私のコードで何がうまくいかないのか、誰でも光を当てることができますか?

ありがとう

私は多くの繰り返し (~10^6-10^7) を含むループを含むコードに取り組んでおり、配列 (「myresult」としましょう) が多くの貢献の合計を介して計算されています。OpenMP を使用する Fortran 90 では、次のようになります。

コードはインテル Xeon コプロセッサーを搭載したシステムで実行されますが、もちろん、可能であればその存在から恩恵を受けたいと考えています。OpenMP で MIC オフロード ステートメント (!dir$ offload target ...) を使用して、ループがコプロセッサだけで実行されるようにしましたが、コプロセッサが終了するのを待っている間、ホストの CPU 時間を無駄にしています。理想的には、ホストとデバイスの間でループを分割できるので、次のようなことが実現可能かどうか (またはより良いアプローチがあるかどうか) を知りたいです。ループはホスト上の 1 つのコアでのみ実行されます (ただし、おそらく OMP_NUM_THREADS=2 を使用しますか?):

Intel Xeon Phi は、「IMCI」命令セット
を使用して提供します。私はそれを使用して、次のように「c = a*b」を実行しました。

そして、パフォーマンスをテストします。N SIZE が 1048576 の場合、
0.083317 秒のコストが必要です。パフォーマンスを自動ベクトル化と比較したい
ので、他のバージョン コードは次のようになります。

このバージョンのコストは 0.025475 秒 (0.002285 以下の場合もありますが、理由はわかりません)
_Cilk_for を #pragma omp parallel for に変更すると、パフォーマンスが低下します。

では、このような答えなら、なぜ組み込み関数を使用する必要があるのでしょうか?
私はどこかで間違いを犯しましたか？
コードを最適化するための良い提案を誰かに教えてもらえますか?

Xeon Phi コプロセッサーで OpenCL を実行したいので、
Intel OpenCL SDK をサーバーにインストールしようとしました
。これで、ホストで OpenCL を正しく実行できますが、次のように MIC を使用するようにコードをコンパイルしようとします。

「libOpenCL.so」が存在し、タグ「-mmic」なしでも問題なく動作します。非常
に気分が悪く、修正するために何かできることはありますか?

最大 240 のスレッドを持つ Intel Xeon Phi コプロセッサーを使用しており、特定のアプリケーションに使用されるスレッドの数を最小化 (またはパフォーマンスを最大化) しながら、最高の実行時間のパーセンテージ内に収まるように取り組んでいます。たとえば、次の測定値があるとします。

• スレッド | 実行時間
• 240 100秒
• 200 105秒
• 150 107秒
• 120 109秒
• 100 120秒

120 から 150 の間のスレッド数を選択したいと思います。これは、そこでの「パフォーマンス曲線」が安定しているように見え、実行時間の短縮がそれほど重要ではないためです (この場合、測定された最良の時間の約 15% です。私はこれを行いました)。徹底的な検索アルゴリズム (1 から 240 のスレッドを測定) を使用していますが、私の問題は、スレッドの数が少ないと時間がかかりすぎることです (明らかに問題のサイズによって異なります)。

測定回数を減らすために、一種の「二分探索」アルゴリズムを開発しました。基本的に、上限と下限 (0 スレッドと 240 スレッドから始まる) があり、中間の値を取り、240 で測定します。両方の値のパーセント差を取得し、15% 以内の場合 (この値は徹底的な検索の結果を分析した後に選択された) 新しい下限または上限を割り当てます。差が 15% より大きい場合、これは新しい下限 (120-240) であり、それより小さい場合は新しい上限 (0-120) であり、実行時間が改善された場合は、次のように保存します。最高の実行時間。

このアルゴリズムの問​​題は、まず第一に、これは必ずしも実行時間の並べ替えられた配列ではないことです。問題のサイズによっては、網羅的な検索結果に 2 つの異なる最小値が表示されるため、たとえば 1 つは 80 スレッドで最高のパフォーマンスが得られ、検索の結果、170 スレッドではなく 80 スレッドを返すことができるようにしたいと考えています。ただし、最小値が 1 つしかない他のケースでは、アルゴリズムは予想される値に非常に近い値を検出しました。

誰かが私を助けることができる既存の検索アルゴリズムまたはヒューリスティックについてより良いアイデアを持っているか知っているなら、私は本当に感謝しています.

Intel Xeon Phi でネイティブ アプリケーションをデバッグしたいと考えています。gdb-mic を提供する MPSS 3.2.3 をインストールしましたが、ネイティブで動作しないようです。一部のドキュメントでは、ファイル「/usr/linux-k1om-4.7/linux-k1om/usr/bin/gdb」について言及していますが、そのディレクトリにはgdbserverではなくgdbserverしかありません。

Intel Xeon Phi でネイティブ アプリケーションをデバッグする方法を知っている人はいますか?