X10の問題のデバッグ

X10 アクセラレータ バックエンドは、グラフベースの並列計算に対して大幅に高いスループットを提供できますが、その遅延トレースとジャストインタイム コンパイルにより、場合によっては明らかではない動作が発生する可能性があります。これには、グラフやテンソルの形状変更によるトレースの頻繁な再コンパイル、またはコンパイル中にメモリの問題を引き起こす巨大なグラフが含まれる場合があります。

問題を診断する 1 つの方法は、X10 が提供する実行メトリックとカウンターを使用することです。モデルが遅い場合に最初に確認することは、メトリクス レポートを生成することです。

メトリクス

メトリクス レポートを印刷するには、プログラムにPrintX10Metrics()呼び出しを追加します。

import TensorFlow

...
PrintX10Metrics()
...

これにより、さまざまなメトリクスとカウンターがINFOレベルで記録されます。

メトリクスレポートを理解する

レポートには次のような内容が含まれます。

  • XLA コンパイルをトリガーした回数とコンパイルに費やされた合計時間。
  • XLA 計算を開始した回数と実行に費やした合計時間。
  • 作成/破棄するデバイス データ ハンドルの数など。

この情報はサンプルのパーセンタイルとして報告されます。例は次のとおりです。

Metric: CompileTime
  TotalSamples: 202
  Counter: 06m09s401ms746.001us
  ValueRate: 778ms572.062us / second
  Rate: 0.425201 / second
  Percentiles: 1%=001ms32.778us; 5%=001ms61.283us; 10%=001ms79.236us; 20%=001ms110.973us; 50%=001ms228.773us; 80%=001ms339.183us; 90%=001ms434.305us; 95%=002ms921.063us; 99%=21s102ms853.173us

また、内部ソフトウェアのステータスを追跡する名前付き整数変数であるカウンターも提供します。例えば：

Counter: CachedSyncTensors
  Value: 395

既知の注意事項

X10 によってサポートされるTensorは、デフォルトの Eager モードTensorと同様に意味的に動作します。ただし、パフォーマンスと完全性に関していくつかの注意事項があります。

  1. 再コンパイルが多すぎるため、パフォーマンスが低下しました。

    XLA コンパイルは高価です。 X10 は、新しい形状が見つかるたびに、ユーザーの介入なしでグラフを自動的に再コンパイルします。モデルは、いくつかのトレーニング ステップ内で安定した形状を確認する必要があり、その時点からは再コンパイルは必要ありません。さらに、同じ理由により、実行パスはすぐに安定する必要があります。X10 は、新しい実行パスが見つかったときに再コンパイルされます。要約すると、再コンパイルを避けるためには次のようになります。

    • 非常に変化しやすい動的形状は避けてください。ただし、異なる形状の数が少なくても問題ありません。可能であれば、テンソルを固定サイズにパッドします。
    • トレーニング ステップ間で反復回数が異なるループを避けてください。現在、X10 はループをアンロールしているため、ループ反復数が異なると、異なる (アンロールされた) 実行パスに変換されます。

  2. 少数の操作はまだ X10 でサポートされていません。

    現在サポートされていない演算がいくつかあります。これは、XLA と静的形状 (現在はnonZeroIndicesのみ) を介して演算を表現する良い方法がない、または既知のユースケース (いくつかの線形代数演算と多項初期化) が不足しているためです。 。 2 番目のカテゴリは必要に応じて簡単に対処できますが、最初のカテゴリは CPU との相互運用性 (非 XLA 実装) を通じてのみ対処できます。相互運用性を頻繁に使用すると、ホストのラウンドトリップや複数のトレースで完全に融合されたモデルが断片化されるため、パフォーマンスに重大な影響が生じます。したがって、ユーザーはモデル内でそのような操作を使用しないことをお勧めします。

    Linux では、 XLA_SAVE_TENSORS_FILE (次のセクションで説明) を使用して、サポートされていない操作を呼び出した Swift スタック トレースを取得します。関数名は、 swift-demangleを使用して手動でマングルリングを解除できます。

トレースの取得とグラフ化

グラフのトレース方法に問題があると思われる場合、またはトレース プロセスを理解したい場合は、ログアウトしてトレースを視覚化するツールが提供されています。 XLA_SAVE_TENSORS_FILE環境変数を設定することで、X10 が見つけたトレースをログアウトさせることができます。

export XLA_SAVE_TENSORS_FILE=/home/person/TraceLog.txt

これらのトレース ログには、 text 、 hlo 、およびdotの 3 つの形式があり、形式は環境変数 XLA_SAVE_TENSORS_FMT で設定できます。

export XLA_SAVE_TENSORS_FMT=text

アプリケーションを実行すると、ログアウトされたtext表現には、X10 で使用される高レベルのテキスト表記で個々のトレースが表示されます。 hlo表現は、XLA コンパイラーに渡される中間表現を示します。これらのログが大きくなりすぎないように、トレーニングまたは計算ループ内の反復回数を制限することもできます。また、アプリケーションを実行するたびにこのファイルが追加されるため、実行の間にこのファイルを削除することもできます。

変数XLA_LOG_GRAPH_CHANGESを 1 に設定すると、グラフ内の変更が発生した場所がトレース ログ内に示されます。これは、再コンパイルが発生する場所を見つけるのに非常に役立ちます。

トレースを視覚的に表現するには、 dotオプションを使用して Graphviz 互換のグラフをログアウトします。次のようなトレースの部分を抽出すると、

digraph G {
    ...
}

独自のファイルに書き込むと、Graphviz (インストールされていると仮定して) を介して視覚的な図を生成できます。

dot -Tpng trace.dot -o trace.png

XLA_SAVE_TENSORS_FILE環境変数を設定すると、特にXLA_LOG_GRAPH_CHANGESと組み合わせて使用​​した場合、パフォーマンスに大きな悪影響を及ぼすことに注意してください。これらはデバッグ時にのみ使用し、通常の操作では使用しないでください。

追加の環境変数

デバッグ用の追加の環境変数には次のものがあります。

  • XLA_USE_BF16 : 1 に設定すると、すべてのFloat値が BF16 に変換されます。自動混合精度が提供されているため、デバッグのみに使用してください。

  • XLA_USE_32BIT_LONG : 1 に設定すると、S4TF Longタイプが XLA 32 ビット整数タイプにマップされます。 TPU では、64 ビット整数の計算は高価であるため、このフラグを設定すると役立つ場合があります。もちろん、ユーザーは値が 32 ビット整数に収まることを確認する必要があります。