仮想環境で開催された今年のWWDC 2020カンファレンスにおいて、Appleは、将来的にApple SiliconベースのMacをリリースすると発表して、来るハードウェア転換への用意を始めるよう、開発者たちに促した。Apple SiliconはARMベースのプロセッサだが、ハイエンドのiPad Proで現在使用されているチップとは違うものだ。
新アーキテクチャへの移行がユーザに影響することはない、とAppleは主張する。ソフトウェアがXcodeを使って簡単にARM用に再コンパイルできること、それが不可能な場合は、Rosetta 2と呼ばれるインストール時変換プロセスによるエミュレーションが可能であることがその理由だ。Rosetta 2は、大部分のx86_64インストラクションを等価なARM/12Xインストラクションに変換するため、新しいバージョンを購入しなくても、現在使っているアプリケーションを引き続きエンジョイすることができる。この変換は、JITコンパイラの生成するコードをオンザフライで変換することにより、実行時にも適用される。ただし、すべてのインストラクションがサポートされている訳ではない。x86_64コードのAVXインストラクションを使用しているものについては動作しないが、Accelerateフレームワークとリンクされたアプリケーションは、プラットフォームに準じたネイティブなインストラクションセットを自動的に使用するようになる。
Rosettaという変換ソフトウェアも、全般的なチップ移行も、Appleにとって初めてのことではない。macOS上の大部分のソフトウェアがAppleの提供するフレームワークと動的にリンクされており、それらのフレームワークが複数のアーキテクチャ用の実装を提供していることから、実行するホストに関らず、そのローカルアーキテクチャのメリットを活かしてアプリケーションを実行することが可能なはずである。2000年代初めに実施されたPowerPCからIntelへの移行では、Rosettaと呼ばれる実行時変換ツールが活用されると同時に、macOSアプリケーションとライブラリ/フレームワークは、macOSのファットバイナリを利用することによって、同一バンドルで複数のアーキテクチャに対応することができた。当時のAppleのコードはpowerpc+intel32、intel32+intel64だったが、今回はintel64+arm64だ。旧環境から新環境への段階的な移行パスを提供することで、Appleは、ユーザと開発者をつなぎ留めようと考えている。
ARMへの移行計画は数年前から始まっている。異なるアーキテクチャ間の移行に対するAppleのアプローチは、新環境でのみ使用可能な新機能を実現することだ。Carbon(Cベースの互換ライブラリ層)を段階的に廃止してCocoa(Next由来のObjective-C層)へ移行した時は、多くの新フレームワークを最終的に新環境でのみ使用可能とし、廃止レベルを徐々に上げ、最後は次のメジャーOSリリースでCarbonのサポートを停止するとして、Adobeなど動きの遅い企業をCarbonから移行させたのだった。同じような騒動は、Appleが32ビットmacOSソフトウェアの廃止を予告した時にもあり、古いアプリが将来のリリースではサポートされないということが、ユーザに対して明示的に強調されていた。現在のような64ビットへの移行をこの時必須とした理由は、将来的なmac/armデバイスを64ビットオンリーにするために、まずは非64ビットのアプリやライブラリを追放する必要があったからだ。
では、Apple Siliconがもたらすのは何か？現時点では年賦で使用可能な開発者テストキット(500ドル/年、この種のものとしては高価)のみだが、期待される最終的なパフォーマンスはこれではない。しかしながら、同様のシステムを持つiPad Proを見れば、最終的にどのようなものになるかを想像することはできる — 長時間持続可能なバッテリ、高い処理能力、ハイパワーとローパワーを併せ持ったコアなどが期待できるだろう。
Appleは、新しいApple Silicon macのコアでbig.LITTLEアプローチを採用するということを、WWDCでApple Siliconを紹介したビデオで、ドキュメントとして明確に示している。コアのいくつかはローパワーで、要求の厳しくないバックグラウンドタスクに適しているのに対して、他はハイパワーで、ユーザとのインタラクションや重い処理向きとなっている。GPU機能も備えており、Metalアプリケーションを記述する開発者が自由に使用できるようになる。"動作は高速に、停止は迅速に"(run-fast-and-sleep-quickly)という目標により、バッテリ動作時の消費電力低減と、電源接続時の熱損失の低減が可能になる。
講演で明らかになったもうひとつの興味深い点は、Apple Siliconハードウェアでは、GPUとCPUがメモリを共有するようになることだ。結果として、バルクアップロードやテクスチャ処理を実行する重いグラフィック操作時に、CPUとGPUの間で、明示的にデータのやり取りをする必要はなくなる。現行のIntel Macでは、CPUとGPU用に２つの異なるメモリシステムが存在している。このため、バルクローディングを必要とするオペレーション — 重いグラフィック処理やニューラルデータ処理などが考えられる — では、入力データや出力データのコピーを省略することが可能になる。
システムの完全なコントロールを掌握するというAppleの目標は、このような判断を自らが下せるようになることだ。これによって同社は、グラフィックカードと合わせるために特定の標準化されたIntelやPCIなどのアーキテクチャに束縛される、ということがなくなる。システムがメモリを共有できることで、メモリ要件に応じてCPUとGPUの負荷を調整することが可能になるのだ。
アーキテクチャ上のもうひとつの大きな違いは、デバイスドライバのパーティショニングと、エクスプロイト防止の手順である。Intelプロセッサでは、すべてのデバイスドライバが単一のIOMMUを共有しており、これがクロスデバイスターゲティングやリークの可能性につながっていた。Apple Siliconのハードウェアでは、各デバイスドライバが独自のIOMMUを持つ。ただし、ドライバ間のトラフィックはコマンドチャネル経由で許可されており、他のメモリを読み書きする場合の調停は必要ではない。システムアーキテクチャの進化の方向性の問題から、Intelマシンでこれを実現するのは不可能である。これはスタック全体を自身で提供していることの強みなのだ。
その他にApple Siliconハードウェアが行うのは、ポインタ認証の実施、R^Xプロテクション、完全な読み取り専用/サイン付きパーティションへのカーネルのマッピングなどだ。ブートローダプロセスにはトラストチェーン(a chain of trust)を使うことで、最新の署名入りAppleカーネルのみを起動可能としているため、マルウェアやその他の悪意を持ったアクタがカーネル処理に介入することはできない。このカーネルの読み取り専用ビューによるコード実行の防止と、ARMのポインタ認証によるエクスプロイトの範囲の削減は、すべてのエスケープを防止できるということではない、とAppleは述べている。これらのプロテクションの多くはiOSデバイスですでに使用可能になっており、iOSデバイスはmacOSデバイスより安全なのだが、それでも脆弱性がまったくない訳ではない、というのも確かに事実ではある — しかしARMへの移行はAppleにとって、ハンドヘルドデバイスと同じ手法でmacOSのセキュリティを強化するチャンスなのだ。ブートプロトコルに関するこれらの変更により、Windowsをネイティブに実行するBootCampはもはや使用できなくなる。ただしAppleは、ARMハードウェア上でx86 LinuxマシンをエミュレートするParallelsデスクトップをデモしているので、新しいハードウェア上でWindowsベースのアプリケーション実行を希望する人たちのための、低速なエミュレーションならば動作するかも知れない。
業界にはどのような影響を与えるだろうか？Microsoftは少し前からARM用Windowsを提供しているが、現時点でのおもな利用は、おそらくRaspberry Piデスクトップ上であろう。しかし、それよりも重要なのは、Amazonが64ビットARMマシンのGravitonプロセッサをローンチしたことだ。開発者には新マシンを警戒する傾向があるが、Amazonが従来より少ない冷却と電力でこれらのマシンを運用して、大幅なコスト削減に成功しているという実績がある — さらに、JavaやPython、Node.JSといった、ARMへ移植済の高レベルランタイムを使用しているのであれば、新たなプロセッサに移行するのみで、クラウド内でより安価なハードウェアで動作するというアドバンテージを得ることができるのだ。
Appleが提案するのは、ARMで記述されたネイティブコードをデバッグ可能な、快適で高性能なデスクトップマシン(あるいはラップトップ)を使う方法だ。これがあれば、Intel(メモリオーダリング(memory ordering)が比較的強い)からARM(メモリオーダリングが比較的弱い)への移植作業が容易になる。移植により、x86上では正常に動作していた隠れたレースコンディションが、ARMベースのシステムでは明らかなエラーになるような状況も考えられる。これらをクラウド内で動作するARMサーバ上のリモートウィンドウを通じてではなく、パワフルなデスクトップ上でデバッグできれば、問題の発見や修正がはるかに早くできるようになるだろう。先日のOpen Source Summitで、Dirk Hondel氏がLinus Torvalds 氏に、ARMハードウェアの可用性について質問して、次のような回答を得た。
10年位の間、私はずっと、開発に使用できるARMハードウェアを見つけるのが本当に、本当に難しいという事実について不満を持っていました。あることにはあるのですが、まったくx86に対抗できるようなレベルではないのです。
IntelからARMへの移行は一晩で達成できるようなものではないが、その方向性は間違いなく明確であり、アーリーアダプタたちは安価なランタイムを求めてクラウド内のARMプロセッサに押しかけている。今後数年間でARM macの可用性が向上すれば、ライブラリやサーバ向けのARM開発作業に多くの開発者が使用するようになり、サーバでのARMプロセッサ採用にも拍車がかかることになるだろう。10年後には、ARMプロセッサがデータセンタ内のサーバの主流になっているかも知れない。