メジャー

MAJC (Microprocessor Architecture for Java Computing) は、1990 年代中期から後半にかけてSun Microsystems が開発したマルチコア、マルチスレッド、VLIW (超長命令語)マイクロプロセッサ設計です。当初 UltraJava プロセッサと呼ばれていた MAJC プロセッサは、 Javaプログラムの実行を目的としており、その「後期コンパイル」により Sun はいくつかの有利な設計上の決定を行うことができました。このプロセッサは Sun の 2 つの商用グラフィック カードに搭載されてリリースされました。マルチコア プロセッサ上のマルチスレッドに関する教訓は、UltraSPARC T1などの後のOpenSPARC実装の基礎となりました。

他の VLIW 設計、特にIntelのIA-64 (Itanium)と同様に、MAJC は、いくつかの高価な操作をプロセッサから関連コンパイラに移動することでパフォーマンスの向上を図りました。一般に、VLIW 設計では、プロセッサ全体のトランジスタ バジェットの比較的大きな部分を占めることが多い命令スケジューラを排除しようとします。CPU のこの部分をソフトウェアに移行することで、それらのトランジスタを他の目的に使用できます。多くの場合、一度に処理できる命令を増やすために機能ユニットを追加したり、はるかに低速なメイン メモリからデータが到着するのを待つ時間を短縮するためにキャッシュ メモリの量を増やしたりします。MAJC はこれらの一般的な概念を共有していましたが、他の VLIW 設計やプロセッサ全般とはいくつかの点で異なっていました。

ほとんどのプロセッサには、特定の種類のデータを処理するように調整された機能ユニットと呼ばれる個別の「サブプロセッサ」が多数含まれています。たとえば、現代の CPU には通常、整数データと論理命令の処理専用の機能ユニットが 2 つまたは 3 つあり、これらはALUと呼ばれています。また、浮動小数点数を処理するユニットはFPUと呼ばれ、マルチメディア データを処理するユニットはSIMD と呼ばれています。MAJC では、代わりにあらゆる種類のデータを処理できる単一の多目的機能ユニットが使用されました。理論上、このアプローチでは、1 つの種類のデータを処理するのに、同じデータをその種類のデータ専用のユニットで処理するよりも長い、場合によってははるかに長い時間がかかります。しかし一方で、これらの汎用ユニットは、プログラムがたまたまその特定の時点で多くの (たとえば) 浮動小数点計算を実行しているために、CPU の大部分が未使用になるということがないことを意味していました。

もう 1 つの違いは、MAJC が可変長の「命令パケット」を許可したことです。VLIW では、このパケットには、コンパイラが同時に実行できると判断した命令が多数含まれます。ほとんどの VLIW アーキテクチャは固定長パケットを使用し、実行する命令が見つからない場合は、代わりに で埋めますが、これは単にスペースを占有するだけです。可変長命令パケットによって CPU の複雑さは増しましたが、コード サイズが削減され、一度にキャッシュ内のコード量が増えることで、 コストのかかるキャッシュ ミスNOPの数も減りました。

主な違いは、MAJC 設計ではコンパイラがインターロックを回避する必要があるという点です。インターロックとは、1 つの命令の結果が次の命令を実行するために処理される間に実行される一時停止のことです。たとえば、プロセッサに命令が与えられた場合C = A + B, E = C + D、2 番目の命令は最初の命令が完了してからでないと実行できません。ほとんどのプロセッサには、このようなインターロックされた命令を停止して再スケジュールするためのロックが設計に含まれており、C の値が計算されている間に他の命令を実行できます。ただし、これらのインターロックはチップの占有面積の点で非常に高価であり、命令スケジューラのロジックの大部分を占めています。

コンパイラがこれらのインターロックを回避するには、各命令が完了するまでに要する時間を正確に把握する必要があります。たとえば、特定の実装で浮動小数点乗算を完了するのに 3 サイクルかかった場合、MAJC コンパイラは、完了までに 3 サイクルかかり、現在停止していない他の命令をスケジュールに入れようとします。ただし、実際の実装を変更すると、この遅延が 2 つの命令にまで短縮される可能性があり、コンパイラはこの変更を認識する必要があります。

これは、コンパイラが MAJC 全体に関連付けられているのではなく、 MAJC の特定の実装、つまり MAJC 設計に基づいた各 CPU に関連付けられていることを意味します。通常、これは深刻なロジスティックス上の問題になります。たとえば、Intel IA-32設計のさまざまなバリエーションを考えてみましょう。それぞれに専用のコンパイラが必要になり、開発者はそれぞれに対して異なるバイナリを作成する必要があります。しかし、Java 市場を牽引しているのはまさにこの概念です。実際、ISAごとに異なるコンパイラがあり、開発者のマシンではなくクライアントのマシンにインストールされます。開発者はプログラムのバイトコードバージョンを 1 つだけ出荷し、ユーザーのマシンはそれを基盤となるプラットフォームにコンパイルします。

実際には、このように命令をスケジュールすることは非常に難しい問題です。実際の使用では、実行時にこのスケジュールを実行しようとするプロセッサは、必要なデータがキャッシュ外にあり、プログラム内にそのようなデータに依存しない他の命令がないというイベントに数多く遭遇します。このような場合、プロセッサはメイン メモリを待機して長時間停止する可能性があります。この点では、VLIW アプローチはあまり役に立ちません。コンパイラは実行する命令の検索に多くの時間を費やすことができるかもしれませんが、実際に命令を見つけられるとは限りません。

MAJC は、現在のスレッドがメモリ上で停止した場合に他のスレッドからコードを実行する機能によってこの問題に対処しようとしました。スレッドの切り替えは通常、コンテキスト スイッチと呼ばれる非常にコストのかかるプロセスであり、通常のプロセッサでは、スイッチによって節約効果が打ち消され、一般的にマシンの速度が低下します。MAJC では、システムは最大 4 つのスレッドの状態を同時にメモリに保持できるため、コンテキスト スイッチを数命令の長さに短縮できます。この機能はその後、他のプロセッサにも搭載され、Intel はこれをHyperThreadingと呼んでいます。

MAJC はこのアイデアをさらに一歩進め、スレッドが停止している間に必要なデータと命令をプリフェッチしようとしました。ほとんどのプロセッサには、命令ストリームの一部に同様の機能が含まれています。これは投機的実行と呼ばれ、プロセッサは分岐の可能な結果の両方を実行し、決定変数の計算を待機します。MAJC は代わりに、スレッドが停止していないかのようにスレッドの実行を継続し、この実行を使用して、スレッドが停止しなくなったときにすぐに必要になるデータや命令を見つけてロードします。Sun はこれをSpace-Time Computing (STC) と呼び、投機的マルチスレッド設計です。

これまでのプロセッサは、単一スレッドで並列処理を行おうとしていましたが、この手法は、収穫逓減の点で限界に達していました。一般的な意味では、MAJC 設計は、単一スレッドで並列処理を行おうとするのではなく、複数のスレッド (およびプログラム) を実行することでストールを回避しようとしていたようです。コンパイル時に実行時の動作を理解するのが難しいため、ストールの点では VLIW の方がやや悪いと一般に予想されており、この問題に対処する MAJC のアプローチは特に興味深いものとなっています。

Sun は MAJC の単一モデル、2 コアのMAJC 5200 を製造しました。これは Sun の XVR-1000 および XVR-4000ワークステーショングラフィックス ボードの心臓部でした。しかし、マルチコアおよびマルチスレッド設計のアイデアの多くは、特に複数のスレッドを使用してストール遅延を減らすという点で、Sun SPARCプロセッサ ラインだけでなく、他社の設計にも取り入れられました。さらに、命令ではなく、できるだけ多くのスレッドを実行するようにプロセッサを設計するという MAJC のアイデアは、後のUltraSPARC T1 (コード名Niagara ) 設計の基礎となっているようです。

• スレッドレベルの並列処理
• ピコJava

• Case, Brian (1999 年 10 月 25 日)「Sun がミラー付きの MAJC を実現」。マイクロプロセッサ レポート。
• Gwennap, Linley (1999 年 9 月 13 日)。「MAJC が VLIW に新たな工夫を加える」。マイクロプロセッサ レポート。
• Halfhill, Tom (1999 年 8 月 24 日)。「Sun が「マジック」の秘密を明かす」。マイクロプロセッサ レポート。

• SunのMAJCとIntelのIA-64