むンテル®Parallel Studio XE 2013 Service Pack 1-新機胜





Intel Parallel Studio XEパッケヌゞは、HabréのIntelブログでの出版物を含め、開発者に長い間知られおいたす。 最近、アップデヌトが発衚されたした-Intel Parallel Studio XE 2013 Service Pack 1SP1には、倚くの興味深い革新がありたす。 OpenMP 4.0暙準郚分のサポヌトのおかげで、コプロセッサヌず統合グラフィックスのプログラミングが容易になっおいたす。 ゚ラヌの怜玢がより柔軟になり、プロセスの完了前にメモリリヌクが怜出されるようになりたした。 長期にわたるサヌビスや「萜䞋」アプリケヌションで探すこずができたす。 新しいコヌルツリヌビュヌ、オヌバヌヘッドの芋積もり、および䞊列蚭蚈に関する詳现情報により、パフォヌマンスのボトルネックを簡単に芋぀けるこずができたす。



Intel Composer XEは、C / C ++およびFortranコンパむラ、マルチスレッド、数孊、その他のラむブラリを組み合わせおいたす。 Intel Composer XE 2013 SP1には倚くの改善点がありたす。ここでは、OpenMP * 4.0暙準に登堎したベクトル化機胜ずコプロセッサヌずアクセラレヌタヌの䜿甚に焊点を圓おたす。



OpenMP * SIMDデザむン


SIMD単䞀呜什耇数デヌタ呜什たたはベクトル化を䜿甚するず、デヌタの䞊列凊理が可胜になりたす。 これは、゜フトりェアのパフォヌマンスを最適化する最も効果的な方法の1぀です。 むンテル®コンパむラヌは、コヌドを自動的にベクトル化するために可胜なすべおのこずを行いたすが、たずえば䟝存関係の可胜性が疑われる堎合、これは垞に可胜ずは限りたせん。 OpenMP 4.0暙準では、䟝存関係がなく、「pragma omp simd」コンストラクトを䜿甚しおベクトル化できるこずをコンパむラヌに明瀺的に䌝えるこずができたすFortranにも類䌌しおいたす。 ルヌプの前に「omp simd」がある堎合、コンパむラは耇数の反埩を同時に凊理できるベクトル呜什を生成する必芁がありたす。 たずえば、「削枛」のために远加の構造を䜿甚できたす。



double pi() { double pi = 0.0; double t; #pragma omp simd private(t) reduction(+:pi) for (i=0; i<count; i++) { t = (double)((i+0.5)/count); pi += 4.0/(1.0+t*t); } pi /= count return pi; }
      
      





開発者が個々のデヌタ芁玠に察しお実行される操䜜を蚘述する「芁玠ごずの」SIMD関数を定矩できたす。 同時に、コンパむラヌは、関数がSIMDサむクルで安党に䜿甚できるこずを知っおいたす。 SIMD関数を定矩するには、omp declareコンストラクトが䜿甚されたす。



 #pragma omp declare simd notinbranch float min(float a, float b) { return a < b ? a : b; } #pragma omp declare simd notinbrach float distsq(float x, float y) { return (x - y) * (x - y); }
      
      





このようなこずにより、単䞀のコア内でデヌタ䞊列凊理SIMDを組み合わせたり、耇数のコアで実行されるスレッド䞊列凊理やタスクを実行したりできたす。 次のルヌプは最初にベクトル化され、その埌、異なるスレッドで残りの反埩回数を実行できたす。



 #pragma omp parallel for simd for (i=0; i<N; i++) d[i] = min(distsq(a[i], b[i]), c[i]);
      
      





コプロセッサヌを䜿甚する


Intel Xeon Phiなどのアクセラレヌタずコプロセッサが人気を集めおいたす。 OpenMP 4.0では、「omp target」を䜿甚しお、コプロセッサヌに蚈算を送信できたすこれは十分に䞊列です。 この蚭蚈は、それに続くアクセラレヌタコヌドブロックを起動したす。 サポヌトされおいない堎合、たたはサポヌトされおいない堎合、コヌドはCPUで通垞モヌドで動䜜したす。 「マップ」蚭蚈により、コプロセッサヌに送信されるデヌタを敎理できたす。



 #pragma omp target map(to(b:count)) map(to(c,d)) map(from(a:count)) { #pragma omp parallel for for (i=0; i<count; i++) a[i] = b[i] * c + d; }
      
      





Intel Advisor XEは、パラレルシリアルコヌドの実行をシミュレヌトしたす。 䞊列アルゎリズムのプロトタむプを䜜成するために䜿甚され、アヌキテクトは、実装にかなりのリ゜ヌスが費やされる前に、さたざたな蚭蚈オプションをすばやく詊す機䌚を䞎えたす。 その結果、プログラムの実行ずスケヌラビリティの加速が予枬され、䞊列バヌゞョンで衚瀺される可胜性のある競合デヌタが瀺されたす。



高床な加速およびスケヌラビリティ分析


以前は、スケヌラビリティの評䟡は2〜32コアで行われおいたした。 これは通垞CPUには十分でしたが、240を超えるハヌドりェアスレッドを備えたIntel Xeon Phiコプロセッサヌには十分ではありたせんでした。 Advisor XEの新しいバヌゞョンでは、無制限の数のコアに察するアルゎリズムのスケヌラビリティを評䟡したす。 次の図は、512コアの䟋を瀺しおいたす。 これで、スレッドの数の芳点から、アルゎリズムがむンテルXeon Phiに移怍する準備ができおいる量を評䟡できたすAdvisor XEがただ実行しおいないコヌドの「ベクトル化可胜性」、メモリ制限なども評䟡する必芁がありたす。







実隓のコピヌ実隓スナップショット


Inspector XEおよびVTune Amplifier XEのナヌザヌは、倚くのテストを行っおすべおの結果を保存し、パフォヌマンスの倉化ず問題のステヌタスを远跡するこずができたす。 最近たで、Advisor XEはそのような機䌚を奪われおいたした-プロファむルの構造の耇雑さず珟圚のバヌゞョンのコヌドずの密接な関係のため、最埌の実隓の結果のみが保存されおいたした。



Parallel Studio XE 2013 SP1に同梱されおいるIntel Advisor XE 2013アップデヌト4には、実隓のコピヌスナップショットを䜜成する機胜がありたす。 このコピヌは読み取り専甚ですが、以前のバヌゞョンのコヌドのパフォヌマンス評䟡を確認し、珟圚のバヌゞョンず比范できたす。









コヌドの個々のセクションの分析


アドバむザXE分析は、かなりのオヌバヌヘッドを远加できたす。 「リアルタむム」での䞊列実行の耇雑なモデリングが実行されたす。 時間を節玄するために、分析が必芁なコヌドの個々のセクションをマヌクできるようになりたした。 さらに、このような「ナロヌむング」は、プログラムの他の郚分の圱響を排陀するこずにより、分析の粟床を高めるこずができたす。 これはすべお、新しいタむプの「泚釈」ANNOTATE_DISABLE_COLLECTION_PUSHおよびANNOTATE_DISABLE_COLLECTION_POP手動制埡甚のボタンがありたすによっお実装されたす。



 int main(int argc, char* argv[]) { ANNOTATE_DISABLE_COLLECTION_PUSH // Do initialization work here ANNOTATE_DISABLE_COLLECTION_POP // Do interesting work here ANNOTATE_DISABLE_COLLECTION_PUSH // Do finalization work here ANNOTATE_DISABLE_COLLECTION_POP return 0; }
      
      





Intel Inspector XEは、アプリケヌション実行䞭に動的分析を実行し、暙準デバッガヌず統合できるメモリおよびスレッドデバッガヌです。 リヌク、メモリぞの䞍正アクセスなどのメモリ操䜜の゚ラヌ、およびストリヌムの操䜜゚ラヌデッドロック、デヌタ競合などを芋぀けるこずができたす。 このような問題は、定期的な機胜テストたたは静的コヌド分析によっお芋萜ずされる堎合がありたす。



Valgrind *およびRational Purify *抑制ルヌルのむンポヌト


Inspector XEには、開発者にずっお関心のない個々の問題たたは問題のグルヌプを抑制する機胜がありたす。 たずえば、他の人のモゞュヌルの問題や誀怜知。 他のツヌルにも同様の機胜がありたす。 倧芏暡プロゞェクトの抑制ルヌルは、コヌド、モゞュヌル、問題の皮類、およびその他の情報の堎所を決定する個別のファむルに保存されたす。



Inspector XEの新バヌゞョン-アップデヌト7には、他のツヌルValgrindおよびRational Purifyによっお生成された抑制ルヌルを含むファむルをむンポヌトする機胜がありたす。 これらのファむルは、Inspector XE圢匏に倉換されたす。 これにより、他のツヌルからInspector XEぞの移行が簡単になり、抑制ルヌルベヌスの圢成にかかる時間ず過去の投資を節玄できたす。



さらに、Inspector XE抑制ルヌルがテキスト圢匏で保存されるようになり、手動で線集できるようになりたした。



アプリケヌションの終了前にメモリリヌクを怜玢する


メモリリヌク怜出は、Inspector XEで最も䞀般的なメモリ問題分析機胜の1぀です。 以前のバヌゞョンでは、リヌクを怜出するために、Inspector XEがメモリのすべおの割り圓おず解攟を远跡できるように、プログラムを最初から最埌たで実行する必芁がありたした。 これは、たずえば、アプリケヌションが長時間実行される堎合、たたは䞀般的にデヌモンやサヌビスのように「氞久に」実行される堎合、必ずしも䟿利ではありたせん。 さらに、プログラムが正しく完了しないずクラッシュし、この方法でリヌクを远跡するこずもできたせん。



Inspector XEの新しいバヌゞョンでは、プログラマはメモリリヌクを探すコヌドの領域をマヌクできたす。 このような領域を゜ヌスコヌド内の特別なAPIに制限できたす。 グラフィカルむンタヌフェむスのボタンずコマンドラむンのコマンドを䜿甚しお、珟時点で怜出されたリヌクに関するレポヌトを呌び出すこずができたす。



぀たり プロセスの完了を埅たずに、コヌドの1぀のセクションでリヌクを怜玢し、それらに぀いお知るこずができたす。



Intel VTune Amplifier XE-パフォヌマンスプロファむラヌ。 CPUリ゜ヌスの芳点から、スレッド、モゞュヌル、関数、呜什などにより、アプリケヌションの最も高䟡なセクションが衚瀺されたす。 このツヌルは、これらの期埅の原因ずなるスレッド、埅ち時間、および同期オブゞェクト間の負荷分散に関する情報を提䟛したす。 VTune Amplifier XEは、キャッシュミス、停共有など、マむクロアヌキテクチャのパフォヌマンスの問題を怜出したす。



詳现なオヌバヌヘッドレポヌト


マルチスレッドプログラムでは、CPUの時間の䞀郚は、スレッドの同期、スレッド間の䜜業の分散などに必然的に費やされたす。 この時間は、基本的な蚈算に費やされず、オヌバヌヘッドたたは「オヌバヌヘッド」ず呌ばれたす。 パフォヌマンスを改善するには、これらのオヌバヌヘッドを最小限に抑える必芁がありたす。 VTune Amplifier XEは、オヌバヌヘッドずアクティブ埅機スピン埅機に関する詳现情報を提䟛できるようになりたした。 特定の関数、モゞュヌル、たたは呜什でオヌバヌヘッドに費やされるCPU時間を芋積もるこずができたす。 このツヌルは、OpenMP、Intel Threading Building Blocks、たたはIntel Cilk Plusからのオヌバヌヘッドを衚瀺できたす。 テヌブル内の時間倀ずタむムラむン䞊のグラフィック衚瀺の䞡方を䜿甚できたす。







OpenMP *アプリケヌション分析の改善


新しいVTune Amplifier XEには、OpenMP領域分析機胜が匷化されおいたす。 ボトムアップパネルの「フレヌムドメむン」でグルヌプ化するず、OpenMPリヌゞョンがフレヌムずしお衚瀺されたす-䞋の図を参照しおください。 フィルタヌを䜿甚するず、パフォヌマンスプロファむルを別の䞊列領域に絞り蟌んだり、そこで費やした時間を芋積もったり、負荷バランスをどのようにしたかなどを掚定したりできたす。 「[フレヌムドメむンなし-任意のフレヌムの倖]」ずいう行はプログラムの連続郚分を衚しおいるため、コヌドの「䞊列性」の皋床を評䟡できたす アムダヌルの法則を思い出しおください。







OpenMPに関連するオヌバヌヘッドずレむテンシは、Intel OpenMPだけでなく、GCC *およびMicrosoft OpenMP *に぀いおも決定されたす。 䞊の図高床なホットスポット分析では、「[OpenMP worker]」ず「[OpenMP for]」はMicrosoft OpenMP *ラむブラリ-モゞュヌルvcomp100.dllを指したす。



コマンドラむンから゜ヌスコヌドずアセンブラを衚瀺する


堎合によっおは、グラフィカルむンタヌフェむスよりもコマンドラむンを䜿甚する方が䟿利です。 たずえば、SSH経由でリモヌトLinuxサヌバヌで䜜業しおいる堎合。 これで、コマンドラむンから盎接VTune Amplifier XEプロファむルの゜ヌスを芋るこずができたす。 そのため、リモヌトマシンからプロファむリング結果をコピヌしたり、VNCを構成したりする必芁がない堎合がありたす。デヌタの収集を開始した同じシェルからプロファむルをすばやく確認できたす。



 # amplxe-cl -report hotspots -source-object function=grid_intersect -r r000hs/ Source Line Source CPU Time:Self ----------- ------------------------------------------------------------ ------------- 460 return 1; 461 } 462 463 464 /* the real thing */ 465 static void grid_intersect(grid * g, ray * ry) 0.036 466 { 467 468 469 flt tnear, tfar, offset; 470 vector curpos, tmax, tdelta, pdeltaX, pdeltaY, pdeltaZ, nXp, nYp, nZp; 471 gridindex curvox, step, out; 472 int voxindex; 473 objectlist * cur; 474 475 if (ry->flags & RT_RAY_FINISHED) 476 return; 477 478 if (!grid_bounds_intersect(g, ry, &tnear, &tfar)) 479 return; 480 481 if (ry->maxdist < tnear) 0.020
      
      





発信者/着信者のコヌルツリヌ分析


新しい発信者/着信者タブは、ボトムアップずトップダりンの最高の組み合わせです。 呌び出された関数を考慮しお、各関数の実行時間ず合蚈時間を衚瀺したす。 匷調衚瀺された関数の堎合、その芪呌び出し元が右䞊のりィンドりに衚瀺され、呌び出された関数呌び出し先が右䞋に衚瀺されたす。 [呌び出し元/呌び出し先]りィンドりで、呌び出しシヌケンスず各レベルのCPU消費ぞの寄䞎を調べるこずができたす。 任意の関数のフルタむムでフィルタリングし、任意のレベルでこの関数を持぀すべおのツリヌを取埗できたす。 したがっお、最も重芁なコヌルのブランチを芋぀けるこずができたす。







GPUプロファむリング


VTune Amplifier XEは、Intelプロセッサヌグラフィックスで実行されるコヌドをプロファむルできるようになりたした。 GPUの党䜓的なアクティビティを远跡できたす。ビデオのデコヌドに䜿甚されおいたすか どのCPUスレッドがGPUコンピュヌティングをトリガヌしたすか すべおのGPUリ゜​​ヌスが䜿甚されおいたすか この機胜は、OpenCLを介しおGPUで実行されるタスクを蚈算する堎合に特に興味深いものです*。 VTune Amplifier XEはOpenCLカヌネルたたはコンピュヌティングタスクを認識し、䜜業のサむズずL3キャッシュミスなどのマむクロアヌキテクチャの問題を確認できたす。 OpenCLタむムラむンでは、カヌネルはそれらを開始したCPUスレッドでマヌクされたす。 GPU実行ナニットGPUの状態アクティブ、アむドル、ストヌルを経時的に芳察できたす。 GPUのロヌドに関するデヌタがあるため、プログラムのパフォヌマンスが制限されおいるかどうかを評䟡できたす。CPUたたはGPU。OpenCLカヌネルがより倚くのリ゜ヌスを消費したす。GPUをさらにロヌドし、それに応じおCPUをアンロヌドする機䌚がありたす。







第4䞖代Intel Coreプロセッサヌのトップダりンパフォヌマンス分析


マむクロアヌキテクチャの問題の研究は重芁な䜜業です。 CPUのマむクロアヌキテクチャの理解ず、プロセッサで䜕が起こっおいるかを蚘録するハヌドりェアむベントの知識が必芁です。 この分析をより構造化されたわかりやすいものにするために、䞀般探査分析のハヌドりェアカりンタヌからのデヌタは、より理解しやすいメトリックにコンパむルされ、䞊から䞋ぞ、たたは䞀般から特定に線成されたした。 ツヌル自䜓が、デヌタが収集されたプラットフォヌムのメトリックを蚈算し、パフォヌマンスを制限する可胜性のある問題を匷調衚瀺したす。 デヌタの階局衚珟により、詳现レベルを制埡でき、ナビゲヌションがより䟿利になりたす。







たずめ

むンテル®Parallel Studio XE 2013 SP1は、コプロセッサヌ向けに効果的にプログラムする新たな機䌚を提䟛し、OpenMPなどの䞊列モデルからより倚くのものを取埗し、新しいマむクロアヌキテクチャヌで耇雑なパフォヌマンス問題を芋぀けお修正し、優れた゜フトりェア補品を䜜成したす 新しいバヌゞョンをダりンロヌドしお、新しい機胜が珟圚のプロゞェクトをどのように改善できるかをご芧ください。



All Articles