IBMのChristian Zoellin氏とChristian Jacobi氏へのインタビュー

Hot Chips 2026: IBMのChristian Zoellin氏とChristian Jacobi氏へのインタビュー George Cozma 2026年8月30日 61 共有 こんにちは、インターネットの皆さん。 今日はHot Chips 2026に来ています！IBMにお邪魔して、彼らが発表したばかりのDual-ISA z/アーキテクチャ + ARMデザインについて、Core Design Team LeaderのChristian Zoellin氏とSystems DevelopmentのCTOであるChristian Jacobi氏にお話を伺います！ 皆さんが楽しめることを願っています！ 以下のトランスクリプトは、簡潔さと読みやすさのために編集されています。 George Cozma: こんにちは、インターネットの皆さん。私たちはHot Chips 2026の期間中、スタンフォードに来ています。そして今年の最初のHot ChipsプレゼンテーションはIBMからで、彼らの次世代z/アーキテクチャについて話していました。そして、そこで彼らが行った本当に、本当にクールなこと、それは後で触れます。しかし、IBMから2人の方に来ていただいています。自己紹介をお願いします。 Christian Jacobi: こんにちは、Christian Jacobiです。私はIBM Fellowで、Systems DevelopmentのCTOを務めています。 Christian Zoellin: 私の名前はChristian Zoellinです。私はDistinguished Engineerで、この世代のコア設計チームのリーダーでした。 George Cozma: 素晴らしいです。では、z、この会話ではz18と呼びますが、次世代zの何がそんなにクールなのですか？ Christian Zoellin: z/アーキテクチャ命令セットとARM命令セットの両方をサポートしていることです。 George Cozma: 私が最後にこのようなものを見たのは、オリジナルのItaniumだったと思いますが。皆さんが行ったことは少し違いました。デコーダーをコアに統合したのですね。デコーダーは単一のユニットで複数のモードを持つのか、それとも2つの別々のデコーダーなのか、教えていただけますか？ Christian Zoellin: それはデコードパイプラインです。そこから始めましょう。デコードパイプラインがあり、デコードパイプラインの多くの詳細は2つの命令セットアーキテクチャ間で共有されています。しかし、z/アーキテクチャの16〜48ビット命令や、ARMアーキテクチャの32ビット命令を実際にデコードする個々のデコーダーは、私たちが構築した別々のデコーダーです。 George Cozma: なるほど、素晴らしいです。私にとって本当に興味深いのは、zはビッグエンディアンISAであるということです。つまり、最上位バイトが最初で、最下位バイトが最後ということです。しかし、ARMはリトルエンディアン、あるいは実際にはバイエンディアンですが、リトルエンディアンモードを持っています。エンディアンのスワップにどう対処しましたか？ Christian Zoellin: ロードストアユニットでは、基本的にデータキャッシュは anyway ワード単位で編成されていますが、任意のバイト境界での非アラインメントアクセスをサポートしています。そのため、キャッシュからのワードアクセスを、ロード命令によって要求された実際のワードにフォーマットする構造があります。そしてその中で、ビッグエンディアンとリトルエンディアンをサポートするために、すべてのスワッピングを追加しています。 George Cozma: なるほど。つまり、ソフトウェアを実装する必要はなく、ハードウェアが自動的に行うということですね？ Christian Zoellin: 正しいです。 George Cozma: 素晴らしいです。そして、ロードとストアユニットについて言えば、zが持つものとして「ストロングオーダリング」として知られているものがあります。ARMは「ウィークオーダリング」ですが。つまり、実装は簡単ですが、すべてのロードおよびストア命令がコアを離れるときにストロングであるということですか？ Christian Zoellin: 正しいです。それらは常に強く順序付けられています。これらの順序境界を越えて投機実行するための多くのインフラストラクチャを持っており、そのため、パフォーマンスの観点からは、これらを効率的かつ迅速に行うためのすべてのハードウェアを持っています。そして、私たちは単にそのハードウェアを再利用し、ストロングオーダリングを維持しています。実際、ARMアーキテクチャにはストロングオーダリングを強制する機能がありますが、私たちにとっては、そのビットは基本的に何も行いません。 George Cozma: それはTSOだと思いますが、正しいですか？ Christian Zoellin: 正しいです。 George Cozma: はい、つまり皆さんは自動的にTSOを持っているということですね。では、この設計にどれくらいの面積/追加のトランジスタが使用されましたか？多かったのですか、それともそれほどでもなかったのですか？ Christian Zoellin: それは間違いなく多くはありませんでした。しかし、デコーダーについてはすでに話しました。それらが別々のデコーダーであることについて。そこには確かにトランジスタがあります。また、z/アーキテクチャにはなかったが、実装する必要があった特定の機能もいくつか追加しました。その一例がBF16およびFP16浮動小数点フォーマットです。それらのために、新しいデータフローも追加しました。そしてそれらは追加のトランジスタです。しかし、全体的なフロアプランを見ると、これらのものは、私たちの巨大なBTB（Branch Target Buffer）予測構造や、大規模な命令キャッシュおよびデータキャッシュと比較すると、小さく、ほんのわずかな点です。 George Cozma: そして、共有および再利用できるものについて言えば、どのくらいの構造が再利用されていますか？大多数だと思いますが、正しいですか？ Christian Zoellin: 特にそれらの大きなものはすべてです。それが鍵です。TLB（Translation Lookaside Buffers）、キャッシュ、GPR（General Purpose Registers）およびベクトルレジスタの物理レジスタファイルはすべて全く同じで、そのまま使用されています。 George Cozma: クールです。では、ビジネスケースの使用に移りましょう。なぜARMをzに追加したのですか？ Christian Jacobi: ARMソフトウェアエコシステムは、過去約10年間で非常に急速に成長しました。これは、ハイパースケーラーがデータセンターでARMを展開したことが大きな要因です。私たちにとって、これは、クライアントが実行しているミッションクリティカルなデータやトランザクションに、そのソフトウェアをすべて近づけるための大きな機会です。つまり、クライアントがそのワークロードを配置する場所の柔軟性が大幅に拡大します。多くの場合、レイテンシの観点からそのワークロードをデータやトランザクションの近くに配置することが理にかなっていますが、同じ運用環境内でも、セキュリティや可用性の観点から、すべてが連携するようになります。それが、重要なユースケースの1つと言えるでしょう。 もう1つの重要なユースケースは、大規模なワークロード統合プロジェクトを行っているクライアントです。特にLinuxONEでは、単一のメインフレームフットプリント、LinuxONEフットプリントで、例えば数千のMongoDBデータベースを実行している場合があります。しかし、これらのプロジェクトを見ると、それらはデータベースだけではありませんよね？エンドポイントセキュリティソフトウェア、バックアップソフトウェア、監視、オブザーバビリティなど、トータルソリューションスタック内の多くのソフトウェアが含まれています。 そして、ISV（Independent Software Vendor）と協力してソフトウェアを、元々どこでコード化されたものであれLinux on zにポートする素晴らしいエコシステムチームがいますが、もちろん、世の中には非常に多くのソフトウェアがあり、非常に多くのISVがいるため、すべてのISVがプラットフォームに来るとは限りません。そのため、クライアントがそのような大規模な統合プロジェクトを行いたい場合に、ISVにプラットフォームをサポートしてもらうのは、時に複雑でした。ARMエコシステムがネイティブにプラットフォームで利用可能になったことで、その多くが解決されます。ARMテクノロジーをプラットフォームに採用したことで、より完全なソフトウェアエコシステムが得られるため、さらに多くの大規模な統合シナリオが見られるようになると考えています。 George Cozma: そして、それについて言えば、サードパーティのISAを追加することは検討しましたか？多くの人がRISC-Vについて話しているのを聞きました。それは昨日、チュートリアル中に大きな話題でした。しかし、POWERはどうですか？POWERをサードパーティISAとして実装することについてはどうですか？ Christian Jacobi: ええ、まあ、現時点ではARMを統合するプロジェクトに取り組んでいます。この経験から多くのことを学びました。しかし、さまざまなエンタープライズシステムでのユースケースを見ると、IBMにはPower Systemsがあり、IBMにはMainframe Systemsがあります。それらは、異なる種類のワークロードを対象とする、別々のスイムレーンにあります。Powerアーキテクチャをメインフレームに持ち込み、Power Systemsで自社と競合しようとする、私たちにとって良いビジネスケースは本当にありません。それは私たちにとってあまり意味をなしません。 George Cozma: 全くです。そして、プレゼンテーション中に、ARMの命令数についてコメントされたと思います。ハードウェアに立ち返ると、CISCとRISCの本当の違いは何ですか？なぜなら、おっしゃったように、それらは誤解を招く言葉だからです。 Christian Zoellin: では、最も極端なCISC命令についてすぐに説明しましょう。命令の一部として、メモリ内に15個の異なるパラメータブロックを持つCISC命令があります。