Cortex A73 のそれほど無限ではない並べ替え能力 – チップスとチーズ

Cortex A73 は、Arm の初期の 64 ビット コアが潜在能力をフルに発揮できない原因となっていた電力と熱の問題に対処することを目的としていました。これは、効率性を重視することで、Arm がスマートフォン CPU 市場を獲得するトレンドの始まりとなりました。この取り組みの一部は、独自のアウトオブオーダー リタイアメント メカニズムであるようです。

この機能は、A73 のアーキテクチャを詳しく調べようとする私の以前の試みを妨げました。 ヘンリー・ウォンの方法論 構造のサイズを測定する方法は、容量のスケジュールを除いてほとんど機能しませんでした。 Discord の muffiny_mcmuffinface は、未解決のブランチで廃止をブロックすることを提案し、それがうまくいきました。

順序外退職

従来のアウトオブオーダー実行では、インオーダー フロントエンドが命令をコアに取り込みます。名前変更/割り当てステージでは、バックエンド リソースを命令に割り当てます。次に、バックエンドは、命令が実際に実行する必要があるかどうかを知るまで待たずに、それらの命令の結果を計算します。これらの推測結果は、適切であるとわかるまで、さまざまな内部コア構造に格納されます。レジスタ値は、名前変更されたレジスタ ファイルの推測部分に保持され、メモリに書き込まれる値はストア バッファに保持されます。最後に、命令がすべてのチェックに合格し、その前のすべての命令もチェックに合格すると、命令はリタイア (コアから退出) できます。リタイアすると、レジスタ値がプログラムで認識され、保留中のストア データがメモリ階層に書き出されます。また、リタイアすると、内部コア構造からエントリが解放され、新しい受信命令で使用できるようになります。したがって、CPU が停止した命令をどれだけ先まで進めることができるかは、レジスタ ファイル、ロード/ストア バッファなどの内部構造にいくつのエントリがあるかによって制限されます。

インオーダー リタイアメントは、プログラムとオペレーティング システムが期待するインオーダー実行の幻想を維持するための簡単な方法です。プログラムが対応する物理メモリがマップされていない仮想メモリにアクセスするなど、何かおかしなことが発生した場合、オペレーティング システムは、問題のある命令が実行される前のプログラム状態を維持したまま、その「例外」を処理することを想定しています。その状態を維持することで、オペレーティング システムはディスクへのページングなどによって問題を修正し、何も起こらなかったかのようにプログラムを再開できます。

CPU のバックエンドは、例外が発生した命令以降のすべての命令を破棄 (リタイアではなく) することでこれを実現できます。その後、例外が発生した正確な時点で既知の正常な状態を表示できます。CPU 設計者が賢明に、命令を順序どおりにリタイアさせなかった場合、それより前の命令が例外に遭遇すると、コアは回復不能な状態になる可能性があります。しかし、A73 は特定のケースでまさにそれを実行でき、そのケースの少なくとも 1 つは不完全なロードです。A73 は、ロードが正常に完了することが保証されているタイミングを判断できるのではないかと思います。アドレス変換が完了され、ページ テーブル エントリに対するアクセス チェックが適切であれば、メモリ サブシステムの壊滅的な障害が発生しない限り、ロードが失敗する原因となるものは何もないはずです。

その場合、A73 は不完全なロードの前に命令のリタイアを開始できます。早期にコミットする結果を破棄する必要がないという安心感があるからです。ただし、A73 は不完全な分岐を過ぎてはそうできません。その分岐を正しく予測したかどうかがわからないからです。分岐の予測ミスはソフトウェアによる対応を必要としませんが、コアは回復するために分岐前の命令の結果を保存する必要があります。したがって、Henry Wong の方法論は、キャッシュ ミスに依存する分岐を追加することで A73 用に変更できます。予測ミスが結果に影響を与えないようにするため、分岐は実行されません。

限られた電力とエリアの予算で作業する

この修正された方法論では、A73 の前身と比較して、ほとんどのコア構造が大幅に縮小されることが示されています。

ファイルの登録

A57 では、レジスタ ファイル エントリは、レジスタ ファイル ストレージを可能な限り拡張するために 32 ビット幅でした。初期の 64 ビット Arm コアは、大量の 32 ビット コードを処理することが想定されていたため、64 ビット レジスタの上位半分を無駄にするのは理想的ではなかったと思われます。64 ビット整数レジスタと 128 ビット ベクターは、複数の 32 ビット レジスタを割り当てることによって処理されました。A72 では、レジスタ ファイル エントリが 64 ビット幅になり、FMA パフォーマンスが向上しましたが、これにより、より多くのレジスタ ファイル ストレージとより多くのポートが必要になりました。

レジスタファイル領域は、エントリあたりの記憶セルの数ではなく、アクセスポートの幅と数によって主に制限されます。

Hot Chips 2023 における AMD、カイ・トロスター氏

A73 ではそのアプローチを捨て、整数レジスタ ファイルと浮動小数点レジスタ ファイルを別々に採用しています。整数レジスタ ファイルには 64 ビットのエントリがあり、そのうち 41 が推測結果に使用できます。FP/ベクター レジスタは 128 ビット幅で、38 のエントリが推測結果に使用できます。専用レジスタ ファイルを使用すると、各レジスタ ファイルからのポート数を減らすことができます。Zen 4 の FP/ベクター レジスタ ファイルを構築する際、AMD は 512 ビットのエントリを使用して面積の増加を最小限に抑えることができました。これは、ポート数と幅が各エントリの幅よりもレジスタ ファイル領域に大きな影響を与えたためです。Arm は A73 でも同様の観察を行った可能性があります。小さなエントリを持つ統合レジスタ ファイルを使用すると、ストレージ セルの容量を最大限に活用できますが、面積効率の観点からは間違った方法でした。おそらく電力効率の観点からも間違った方法だったでしょう。

Cortex A72 には比較的多くの実行ポートがあり、それらはすべて 1 つのレジスタ ファイルからの入力を必要としました。確かに、レジスタ ファイルの 2 つの複製を使用して読み取りポートの数を増やすなど、電力と面積の爆発的な増加を防ぐテクニックはありますが、ソフトウェアからそのような詳細を把握することは不可能です。

A73 のレジスタ ファイル設定は、面積効率が高いだけでなく、ベクター コードでも有利です。128 ビットの結果に対して、A72 では 31 個だったのに対し、A73 では 35 個のベクター レジスタ ファイル エントリが利用可能です。スカラー整数演算とベクター演算が同じレジスタ ファイル内で容量を争うことがないため、A73 の利点は実際にはさらに顕著になります。

しかし、A73 は両方のレジスタファイルにすべてのエントリを完全に割り当てることはできず、スカラーレジスタとベクターレジスタに書き込む操作が均等に混在する 66 のインフライト命令で上限に達します。他の CPU にも同様の制限があります。Intel CPU には「物理レジスター再利用テーブルe” は、命令が終了したときにどのレジスタを解放するかを追跡します。この構造体のエントリが不足すると、すべてのレジスタ ファイル エントリが使い果たされる前に停止が発生する可能性があります。A73 も同様の構造を持つ可能性があります。

メモリアクセスと分岐?

A73 は 50 のインフライト ロードを持つことができますが、これは他の構造に比べて非常に大きなものです。実際、50 のインフライト ロードは、整数とベクトルの両方の宛先レジスタを使用することによってのみ実現できます。そうしないと、ロードされたデータを保持するために予約できるレジスタ ファイル容量によって、並べ替え容量が制限されます。これは、A72 の 32 エントリ ロード キューに比べて大幅に改善されており、実際には関連する制限となる可能性は低いです。

ストアは別の話です。Cortex A73 は、未解決の分岐の後に実行中のストアを 11 個しか持つことができません。これは、A72 のすでに小さい 15 エントリのストア キューからの後退です。興味深いことに、独立した分岐は同じ 11 エントリのリソースを共有しているようです。このリソースがいっぱいになると、スケジューラ容量が利用可能であっても、後続の分岐はコアに入ることができません。これにより、A73 では実行中の不完全な分岐が完全な分岐よりも多くなるというおかしな状況が生まれます。

おそらく、ストアとブランチは、何らかの 11 エントリ検証キューに少なくとも 1 つのスロットを予約する必要があります。スロットが利用できない場合、スケジューラ エントリが空いていても、着信命令はバックエンドに入ることができません。ブランチとストアはどちらも、結果をコミットする前に特別な注意が必要です。ブランチは予測を誤る可能性があります。ストアをコミットすると、そのデータがキャッシュに書き込まれ、他のコアから見えるようになります。いずれにせよ、この 11 エントリ バッファーは非常にホットな構造である可能性があります。ストアでのみ使用される場合でも、容量は低くなります。ブランチは、これらの 11 エントリへの圧力をさらに高めます。

メモリ順序の問題

ストアは、小さな構造で貴重なスペースを占有するだけでなく、A73 にとって別の問題を引き起こします。A73 には、ロードが以前の実行中のストアに依存するかどうかを推測する方法がありません。つまり、以前のストア アドレスがすべてわかるまで、ロードを実行できません。

メモリ依存予測は新しいものではありません。Intel が最初に実装したのは 2006 年頃の Core 2 で、AMD は 2011 年に Bulldozer で実装しました。ほとんどのロードが以前のストアと重複しないため、これは大きな利点です。キャッシュにヒットしないロードは、CPU が処理しなければならない最もレイテンシの高い命令の 1 つです。A73 はメモリ依存予測を実行できないため、メモリ操作が正しい順序で実行されるようにするために遅延が必要ない場合であっても、ロードが遅延します。その結果、コアの限られた並べ替え能力にさらに負担がかかります。

ROBのような構造はありませんか?

ほとんどのアウトオブオーダー CPU は、順序どおりのリタイアメントを保証するためにリオーダー バッファ (ROB) を使用します。ROB は、バックエンドで追跡されている実行中の命令のリストであり、プログラム順序で保持されます。他のリソースが先に使い果たされていない場合、リオーダー容量は ROB のサイズによって制限されることがあります。

A73 にはそのような構造はないようです。NOP はレジスタ ファイル、ロード/ストア キュー、またはその他のより具体的なリソースでスペースを占有しないため、ROB 容量を見つけるのに適した方法です。NOP は何も行わず、ROB スロットを占有するだけの命令です。ただし、NOP は未解決の分岐を過ぎても基本的に無限の並べ替え容量を持っています。

また、ストアを混在させることで整数および FP レジスタ ファイルへのインフライト書き込みを組み合わせる Henry Wong の手法も拡張しました。その時点で、A73 は 76 個のインフライト命令を追跡できます。これは、3 つの個別の基礎リソースを最大限に活用しても、並べ替えの容量制限に達しないことを示しています。ストア キューとレジスタ ファイルが最大容量まで利用されている場合、約 76 個の命令が実用的な制限となります。

最後の言葉

アウトオブオーダー リタイアメントは、より小さなコア構造で良好なパフォーマンスを維持するための Arm の戦略の一部です。ある意味では、その目標は Skymont の 16 ワイド リタイア ステージの目標に似ています。両方のコアはリソースをより速く割り当て解除しようとしており、より小さな内部コア構造で一定レベルのパフォーマンスを達成しています。前の記事で述べたように、これが A73 を魅力的なアーキテクチャにしています。

しかし、A73 がコア構造に頼らなければならない場合、A72 や A57 と比べて不利になることがよくあります。そこで問題となるのは、順序外リタイアメントが A73 のパフォーマンスを競争力のあるものにするのに十分効果的であるかどうかです。確かに、場合によっては A73 の戦略がうまく機能し、A57 に非常に近いパフォーマンスが得られます。特定の場所で A73 の構造がどれだけ小さいかを考えると、これは印象的な偉業です。libx264 エンコーディングはその一例です。ただし、他のケースはそれほど明確ではなく、ファイル圧縮は反例です。

しかし、IPC は全体像の一部に過ぎません。IPC に焦点を絞りすぎて全体像を見失ってしまうことはよくあります。クロック速度は重要であり、A73 は消費電力が低いため、A57 よりも高いクロック速度を実現できます。Amlogic S922 の 4 つの A73 コアは 2.2 GHz で動作し、パッシブ冷却でその速度を維持できます。Tegra X1 の 4 つの A57 コアは 1.8 GHz で動作し、Nintendo Switch にアクティブ冷却機能があってもそれ以上高速化しません。

したがって、A73 は、より低い電力で同等のパフォーマンスを提供できます。これは、より小型で幅の狭いコアをより高いクロックで実行することによって実現されます。A73 は、より高い IPC アーキテクチャを構築することが常に最善の方法ではないことを思い出させてくれます。同じことは、より高いクロック速度を目標にする場合にも当てはまります。エンジニアがコアをアプリケーションに合わせてバランス調整する程度によって、どちらの戦略もうまくいく場合もあれば、失敗する場合もあります。

私たちの記事やジャーナリズムを気に入っていただき、私たちの取り組みをサポートしたいとお考えの方は、ぜひ私たちの パトレオン または私たちの ペイパル チップス＆チーズのスタッフや舞台裏の人たちと話したいなら、ぜひ私たちのチームに参加してください。 不和。

関連記事