プログラマーの厳しい目の下でのインテルVTuneアンプXE 2011ベータ

写真1

新しいインテルVTuneアンプXE 2011ベータ版を見て、使用例に関する記事を書くことにしました。 確かに、執筆プロセスでは、Amplifierの使用からテストへと重点が部分的にシフトしました。 しかし、これも良いことです。インテルの開発者が希望を考慮し、ツールの次のバージョンに変更を加えることを願っています。 そして一般的に私は自分自身と皆を批判します。 :)







私は遠くから少し始めましょう、さもないと疑問が生じます。なぜ最適化する必要があるコードが必要なのでしょうか。 C ++の静的コードアナライザーの開発中に、非常にエキゾチックなコードフラグメントを処理する必要があります。 プログラマーだけが思いつかないもの。 そして、Visual C ++やIntel C ++のようなそのようなコンパイラでさえ、いやいや、そしてそれらは次の「波紋」に落ちるでしょう。



PVS-Studioスタティックアナライザーには、オブジェクトのタイプの決定に関してあまり良くない場所が1つあります。 たとえば、次の構造があります。

  typedef int A;
 typedef AB;
 B myValue; 


そして、それがintに他ならないことを知るために、タイプBを「計算」する必要があります。 もちろん、このような例では、困難はなく、すべてが機能します。 ただし、非常に複雑な状況があります。 さまざまな問題が発生し始める場所を示すコードの例を示します。

写真2

変数Xの型を見つけようとするとき、名前空間Bでその型を調べますが、そこでは検出されません。 次に、名前空間Cで何を調べる必要があるかを確認します。それも見つかりません。 次に、ネームスペースB ...永遠のサイクルを見る必要があります。 もちろん、これは単純なケースであり、問​​題もありません。 ただし、ここにtypedef、テンプレート、継承されたクラスを追加します。 時々、驚くほど複雑なことが出てきますが、具体的にはそうではありません。 これは、テンプレートを使用したコードで特に顕著です。



残念ながら、PVS-Studioツールは、特に「成功したデザイン」で永遠のサイクルに入り、5分後に自殺し、他のファイルの処理を継続できるようになりました。 非常にまれな状況ですが、不快です。 もちろん、エラーは修正され修正されますが、新しい状況が見つかります。 さらに、ユーザーがどのようなコードを持っているかを常に把握できるとは限りません。 タイマーによってアナライザーを完全に中断するのではなく、ループが発生した場合、何らかのオブジェクトのタイプの受信を拒否することが決定されました。 ファイル全体よりも1つの変数をスキップすることをお勧めします。



理論と実践の非互換性における非常に興味深い点を示しています。 理論的には、エラーがないように記述する必要があります。 あなたも私たちをchiすことができます。 静的アナライザーの開発者、記事の執筆者はエラーなしで書く方法、そして彼ら自身は変数のタイプの正しい分析を行うことができません。 しかし、それはできません。 そして私たちだけではありません。 C ++コードのコンパイルに関連するタスクは非常に複雑です。 そして、念のために、高度で美しい議論からパッチの作成に進む必要があります。



シンプルだが効果的な停止メカニズムが作成されました。 オブジェクトの型を受け取ったときに、以前に使用したことがあるエンコードされた型へのポインターを取得したら、停止します。 開始するには、std :: set <const void *> * m_pGuardPointersに多くのポインターを含むクラスを作成しました。 セットに既にポインターがある場合は、停止します。



このような変更後のプログラムのパフォーマンスが何度も低下したとき、私は驚きませんでした。 私は同様の効果を期待していました。 私も速度を測定しなかったので、それは非常に遅いことは明らかであり、理由は明らかです。 通常、このタイプの「結論」の深さはそれほど大きくなく、そのような場合に重砲を使用するのは単純に愚かです。

  typedef long LONG; LONG x; 


すぐに、次の形式のクラスが作成されました(省略形で与えられます):

 クラスCPointerDuplacateGuard
 {
   static const size_t QuickMaxSize = 10;
   const void * m_ptrs [QuickMaxSize];
   size_t m_index;
   std :: set <const void *> * m_pGuardPointers;
公開:
   CPointerDuplacateGuard();
   CPointerDuplacateGuard(const CPointerDuplacateGuard *親);
   ...
 }; 


最初に、10個の要素の通常の配列にポインターを保存して検索します。その後、セットを作成して使用を開始します。 それははるかに良くなりましたが、すべてがこのメカニズムなしよりも数倍遅いです。



そして、ここで、Intel VTune Amplifier XE 2011ベータ版を検討する時が来たと判断しました。 非常に正当な理由。 ここで、プロファイラは大歓迎です。 質問に答えるのに役立ちます。std:: setの使用にのみ関連するパフォーマンスの低下、または定数ポインターチェックの使用によりスローダウンが発生します。 主なパフォーマンスの低下がstd :: setによるものである場合、QuickMaxSizeの値を増やす必要があります。 これにより、最も極端な場合にstd :: setの使用が遅延します。 アルゴリズムの速度が低下した場合は、さらに考えてください。



インテルVTuneアンプXE 2011ベータ版で適切に動作する忍耐を持っていなかったとすぐに言わなければなりません。 彼は仕事に想像を絶するブレーキを導入します。 私はかなり強力なシステム(4コア、8 GBのメモリ)を持っていますが、Intel VTune Amplifier XE 2011ベータウィンドウが開いている場合、労力とジャークでコードを簡単に移動できます。 さらに、Intel VTune Amplifier XE 2011自体は何もしません。 むしろ、プロセッサーをロードしますが、実行内容を書き込みません。 根拠がないように、デモのスクリーンショットを提供します。



わかりやすくするために、devenv.exeを4番目のコアに添付しました。

写真3

だから、今私はプロジェクトを開いていますが、何も起こりません。 図は、4番目のコアの負荷がゼロに近いことを示しています。

写真4

現在、Intel VTune Amplifier XE 2011を起動しています。起動したばかりです。 私はプロジェクト分析を行わず、何もしません。 しかし、4番目のコアはすでに完全に占有されています。

写真6

すぐに仕事が不快になります。 環境は可能な限り減速し始めます。 Intel VTune Amplifier XE 2011ウィンドウを閉じると、ブレーキがすぐに消え、カーネルの負荷が再びゼロに近くなります。 おそらく、発売されたIntel VTune Amplifier XE 2011は、いくつかの有用な作業を行います。 しかし、これは明らかではありません。 もしそうなら、少なくとも見せなければなりません。 ある種の間違いについて感じました。



ブレーキングは私を止めませんでした、そして私はプログラムを勉強し始めました。 まず、分析モードを選択しました。このモードでは、コールスタックに関する情報は収集されませんが、どの関数が最も時間を費やすかを理解できます。

写真8

分析は驚くことなく実行されました。

写真9

そして、私は有用な結果を得ました:

写真10

ほとんどの時間は、メモリの割り当てと解放の機能であるstd :: _ Treeに費やされます。 主な減速がstd :: setの使用に関連していることは、プログラマーにすぐに明らかになります。



Amplifierをホットスポットモードで実行すると、問題のある領域がより明確になります。

写真12

この起動後、コールスタックを表示できるようになりました。 確かに、このモードでの最初の起動は失敗しました。 「正確なCPU時間を収集する」チェックボックスをオンにすると、すべてが遅くなると警告されました。 しかし、どういうわけか遅すぎることが判明しました。 最初の機能でスタック拡張ボタンを押したとき、結果を待ちませんでした(15分間待ちました)。



チェックマークなしで起動すると、必要な情報が表示されました。 しかし、ここでは軟膏にハエを追加することはできません。 機能的には、ツールは素晴らしいですが、インターフェースは見苦しいです。 常に、何かが再描画ではなくバラバラになり、何かが不鮮明になっています。 使用は不便で不快です:

写真13

ただし、見た目だけではありません。 何らかの理由で、必要なコードの間違ったセクションにスローされる場合があります。



しかし、私はまだ望ましい結果を達成しました。 配列の値を64に設定すると、パフォーマンスはほぼ同じレベルに戻ることが判明しました。 新しいサブシステムは、実際には作業を遅くしません。 訂正:



static const size_t QuickMaxSize = 64;



これはアンプによって確認されます。 strncmpなどの完全に異なる機能が前面に出ました。

写真15

結論



プログラムの世界には幸せはありません。 エラーと欠点の周辺。 PVS-Studioで、そしてどこでも。 これは、あなたが彼らと戦う必要がないことを意味するのではなく、少なくともプログラムの非常に複雑さを認識し、エラーがあることを認識するための大きな一歩です。



この投稿は、Intel VTune Amplifierツールに関して多少重要​​であることが判明しました。 どうやらこれは開発者の苦痛のようです。 彼らは、世界を改善する別のプログラムを試してみることを提案し、それを使い始めたとき、品質管理よりもマーケティングや美しい写真に多くを費やしたことを理解します。 さて、どのようなプロファイラーが遅くなりますか? ブーツなしの靴屋。 :)



リリースで、または少なくとも多くが修正されることを願っています。 ツール自体は非常に強力です。 しかし、残念ながら、まだ使用することはお勧めできません。 もちろん、Intelでそのようなブログを書くことは、どういうわけか良くありませんが、正直です。 開発者が感謝することを願っています。



All Articles