それはリークされており、最も重要な噂の 1 つでした。Appleが自社の Mac で新しいハードウェアの移行を発表するというものでした。 3番目。最初は 1994 年に Motorola の 68000 シリーズ プロセッサから IBM PowerPC に移行しました。わずか 11 年後、Apple は PowerPC から Intel への新たな移行を発表しました。そして 15 年後の今年 2020 年は、Apple が Mac から商業的にApple Siliconと呼ばれるものに移行するという最後のステップを迎えました。
これをよりよく理解するために、移行とは、企業が別のブランドだけでなく、自社のプロセッサーを変更することを決定することです。プロセッサーは、別の異なる互換性のない命令セットを使用して他のブランドに変更されます。そして、これには明らかに、古い命令セットですでに動作していたすべてのソフトウェアを新しい命令セットに移行および変換する必要があります。
歴史的背景: 現在の移行を理解するための以前の移行がどのようなものであったか
1994 年に、Motorola 自体が、Motorola、IBM、Apple が参加する AIM アライアンスによって作成された PowerPC チップに向けた 680×0 アーキテクチャの使用を中止しました。これにより、PowerPC RISC アーキテクチャを使用するようになりました。別の一連の異なる命令は、新しいプロセッサでの古いプロセッサのエミュレーションを通じて解決されました。次の RISC PowerPC から Intel x86 への移行は、より複雑でした。
PowerPC から Intel への移行は、大きな技術的課題でした。各アーキテクチャの低レベルの命令と動作は、データバイトの表現方法に至るまで、まったく異なりました。
PowerPC では、バイト シーケンスを表す場合、バイト シーケンスは左から右の順にメモリに格納されます。0A0B0C は、最初の位置に 0A、2 番目の位置に 0B、3 番目の位置に 0C として格納されます。いわゆるビッグエンディアン。しかし、Intel はバイトの逆読み取りに基づいて逆の処理を行い、最初の位置に 0C、2 番目の位置に 0B、最後に 0A を格納します。リトルエンディアン方式。これは、Intel 上で実行される PowerPC プログラムによって提供されるデータはすべて、メモリ内のバイトの順序をリアルタイムで逆にする必要があり、これがパフォーマンスの問題を引き起こすことを意味しました。
PowerPC から Intel への移行は、両方のアーキテクチャ間に大きな違いがあるため非常に複雑でしたが、Apple は両方のアーキテクチャ間で先駆的なリアルタイム コード変換ソフトウェア、Rosetta を使用して良好な結果を達成しました。
既存のすべての PowerPC プログラムを Intel 上で実行するために、 Apple は Rosetta と呼ばれる当時の先駆的なソフトウェアを作成しました。この目的は、Intel 上で実行する PowerPC ソフトウェアをエミュレートまたは仮想化することではありません (新しいコンピュータではパフォーマンスが大幅に低下する可能性があります)。ロゼッタは、PowerPC によって実行される低レベル コードをインテル上の同等の命令に自動的かつ透過的に変換します。そして、メモリに格納するときのバイトの順序をビッグエンディアンからリトルエンディアンに変更しました。
ロゼッタ、これを理解することは非常に重要です、それは翻訳者です。名前の由来となった石と同様に、この石にはエジプトの象形文字、デモティック文字、古代ギリシャ語の同じテキストが含まれており、学者が古代エジプトの象形文字を理解して翻訳し、その意味を理解できるようになりました。
以前の Motorola の PowerPC への移行で使用されていたエミュレーションとは対照的に、Rosetta は PowerPC G3、G4、および AltiVec の低レベル命令 (SIMD 浮動小数点演算) を Intel に変換しました。ただし、macOS 9 以前のアプリや、G5 命令やカーネル拡張機能を使用するアプリはサポートされていませんでした。
変換はアプリの実行時に行われるため、当時の Intel プロセッサと PowerPC プロセッサの能力差をほぼ完全に想定できるほどの機器のパフォーマンス コストが発生しました。このように、Rosetta を使用して実行するたびにリアルタイムで翻訳できるアプリは、アプリやその複雑さに応じて、元のパフォーマンスの 70 ～ 90% のパフォーマンスを発揮しました。
PowerPC から Intel への移行期の Rosetta は、古いアーキテクチャのバイナリのみを含むアプリケーションの実行中に、この処理を命令ごとに実行するリアルタイム トランスレータでした。
話のこの部分から学ばなければならない重要なことは、Rosetta は PowerPC アプリが実行されているときはいつでも機能し、リアルタイムで翻訳されるシステム サービスだったということです。さらに、システムの下位レベルで動作する最も複雑なアプリでは問題が発生する可能性があり、より複雑なバイナリへの変換が必要になるため、すべてのソフトウェアをサポートしていませんでした。また、カーネル拡張機能の翻訳もサポートしていませんでした。
Apple Silicon 上のアプリ、実行できるアプリとその実行方法
この移行がどのようなものになるかについては WWDC の前にすでにお話ししましたが、現在はこれ以上の憶測はなく、現在の移行に完全に移行しています。さらに、すべてを確認することで、あの製品とこの製品の違いや、互換性の向上や開発者にとっての使いやすさに加えて、Apple がどのように非常に重要な教訓を学び、プロセスに大幅な改善を適用したかをよりよく理解できるようになります。
まず理解しなければならないのは、 Big Sur は Apple Silicon または Intel 上で完全にネイティブに実行されるということです。つまり、Apple には、オペレーティング システム全体とその依存関係のそれぞれについて、翻訳や調整を行わずにネイティブにコンパイルされた 2 つのバージョンがあります。
これらすべてに加えて、Apple 内で非常に注目すべきマイルストーンが達成されました。iOS、iPadOS、tvOS、watchOS、macOS にサービスを提供するすべてのライブラリが Apple Silicon で同じになりました。各システムにバージョンはなく、まったく同じです。
違いは、各システムでの動作が異なる可能性があることですが、命令とその呼び出し方法は同じであるため、あるシステム用に作成されたアプリを別のシステムでも簡単に実行できるということです。 Metal グラフィック ライブラリから始まり、SwiftUI アプリ API、CoreData (データベース)、CoreLocation (ローカリゼーション)、CoreML (機械学習)、および仕様が同じで各システムの特定の動作を作成する他の数百ものライブラリを通過します。 。
Apple は、Apple Silicon 用のさまざまなシステムのすべての開発ライブラリと依存関係の単一バージョンを作成することに成功しました。これにより、すべてのコンポーネントを均一な方法で独自に進化させることができます。
たとえば、アプリのボタンを作成する場合、命令、パラメータなどは同じですが、Mac で実行するとデスクトップ システムの外観でボタンが作成され、iOS の場合は強調表示された青いテキストとして表示されます。 tvOS ではその外観を持つ要素として、watchOS ではその特徴的な要素として。同じ命令でも、異なる動作が各システムに適応されます (この変更が存在する可能性がある場合) 。
これは、システム ライブラリに対するネイティブ開発の大部分は、このタイプのチップを搭載したコンピュータ上で Xcode 12 を使用してプロジェクトを開き、対応するユニバーサル バイナリを生成することによって Apple Silicon に「移植」されることを意味します。実際、Apple はすでにすべてのアプリをこの新しいシステムにネイティブに移植しています。これには、メモ、写真、メールなどのシステムに含まれるアプリだけでなく、iWork スイート (Pages、Keynote、Numbers) とその 3 つのプロフェッショナルも含まれています。優れたアプリ: Final Cut Pro X、Logic Pro X、Xcode。 Apple 独自のソフトウェア、コンポーネント、ライブラリなどはすべて、変換せずに Apple Silicon 上でネイティブに動作します。
Mac 上のアプリは再びユニバーサルになります。Intel を搭載した Mac と Apple Silicon を搭載した Mac のバイナリが 1 つのファイルに含まれるようになります。しかし、Mac App Store からダウンロードした場合、彼らは私たちのコンピュータからバイナリを入手するだけになります。
しかし、残りのアプリはどうなるでしょうか? Intel ベースの Mac ですでに使用しているアプリは、新しい Apple Silicon ベースの Mac でも動作しますか?答えは「はい」ですが、微妙な違いがあります。
依存関係: アプリをより適切に移行するための鍵
すでに述べた新しい概念: 依存関係。この概念は、アプリが Apple Silicon 上でどのように動作するかを理解するために、さらには新しい Mac 上で何も変更せずに実行できる iPhone および iPad アプリについても理解するのに不可欠です。依存関係は、私たちが作成したものではなく、特定の機能を提供するライブラリであり、意味がない場合や開発作業を容易にする場合に、すべての作業を最初から実行する必要がないようにするために使用されます。
たとえば、Facebook と統合したい場合は、独自の統合を作成して実行することも、それを実行するためのすべての機能がすでに提供されている会社のライブラリを使用することもできます。複雑な数学的演算を実行したい場合は、ライブラリを作成するか、探している関数を提供するライブラリを探すことができます。他の場合には、Apple API の動作をより簡単な方法で管理するのに役立つ依存関係 (ラッパー) を探したり、Apple が提供しているが別の会社のソリューションを使用したい何かを実行するための代替方法を探したりします。
アプリの依存関係は、Apple Silicon への移行が簡単かどうかの鍵となります。 Apple 外部の依存関係を使用しない場合は、すべてが非常に簡単になりますが、Apple 以外の依存関係を使用すると、場合によっては事態が複雑になる可能性があります。
たとえば、データを暗号化したい場合は、Apple のネイティブ API (ライブラリ)、CryptoKit または CommonCrypto を使用できますが、サードパーティによって作成された CryptoSwift を使用することもできます。データベースを使用したい場合は、Apple のネイティブ データベースである Core Data を選択するか、非常に効率的で実用的なソリューションとなる Realm (現在は MongoDB が所有) を使用することができます。私のアプリが Apple ライブラリを使用している場合、私のアプリの依存関係はネイティブであり、これらはすべてすでに翻訳されており、Apple Silicon 上でネイティブに動作します。しかし、Realm を使用するとどうなるでしょうか?
そうですね、2 つのことが起こります。依存関係がソース コードとして共有されている (オープン ソースである) 場合、Swift、Objective-C、C、C++ およびその他の言語との互換性は変わらないため、ほとんどの場合、正しくコンパイルされます。 Xcode 。したがって、アプリを Xcode 12 でユニバーサル バイナリとしてコンパイルすることができ、問題なく動作します。
ただし、依存関係はバイナリにすることもできます。つまり、知的財産やその他の理由でコードを確認できないように事前にコンパイルされています。この場合、問題があります (または問題がありません)。ライブラリのコンパイル済みバージョンには、x86_64 (Intel) および arm64 (Apple Silicon) アーキテクチャ用の実行可能ファイルがバイナリに含まれている必要があるためです。そうであれば問題ありません。しかし、バイナリが x86_64 のみの場合は状況が変わります。 arm64 用にコンパイルされたバージョンを提供するよう開発者に依頼する必要があります。
すべてのコードとその依存関係が ARM 上でコンパイルできる場合にのみ、Apple Silicon 上のネイティブ バイナリを使用してユニバーサル アプリを作成できます。そうでない場合は、Rosetta 2 の翻訳版を作成する必要があります。
それが存在しない場合はどうなりますか?アプリ全体がアーキテクチャを完全にサポートする必要があるため、Apple Silicon でネイティブ コーディングを使用してアプリのユニバーサル バージョンを作成することはできません。唯一の解決策は、Rosetta 2 で翻訳版を作成することです。
ここに、Rosetta 2 と Rosetta の新しく重要な違いが生じます。 PowerPC から Intel への移行における Rosetta は、アプリの実行中にリアルタイムで変換するプロセスでしたが、 Rosetta 2 はアプリのコンパイル時またはインストール時に変換します。したがって、手順が翻訳されると、新しいアプリは「ネイティブであるかのように」動作します。
コードの低レベルの最適化は、ネイティブに生成された場合と翻訳された場合で同じではないため、同じパフォーマンスが得られないことは明らかですが、重要なことは、Rosetta 2 プロセスが実行されるときに完了するということです。そのアプリをコンパイルします。この後、アプリは Apple Silicon のネイティブであるかのように実行されます。 Rosetta 2 は、macOS アプリ、iPadOS から移植された Catalyst アプリ、ゲーム (グラフィック ライブラリとして Metal を使用する)、ブラウザ、コンパイル、インストール、または最初の実行で (場合によっては) JIT コンパイラー (ジャストインタイム) を変換できます。 ）JavaScript などのスクリプト言語、GPU に対する低レベルの Metal グラフィックス プログラミング、プロセッサのニューラル エンジンを使用した Core ML による機械学習コードなどを使用します。
Rosetta 2 は、コンポーネントのいずれかが arm64 アーキテクチャを使用していない場合、アプリを Apple Silicon に変換します。ただし、これはアプリのインストール時または最初の実行時に実行されるプロセスです。一度完了すると、Rosetta 2 は再びアプリに介入しなくなります。
すでに述べたように、 Rosetta 2 は瞬間に応じて異なるタイミングで翻訳します。開発者は、適応したアプリをアップロードした可能性がありますが、ARM にすべての依存関係があるわけではないため、Rosetta 2 で翻訳されたアプリとしてアップロードしました。その場合、アプリはすでに変換されており、すぐに開始またはインストールされます。ただし、開発者によって移植されておらず、Intel 上にのみ存在するアプリを Mac App Store からダウンロードした場合、アプリのインストール時に関連する変換が Apple Silicon に行われます。 Web サイトからアプリをダウンロードし、それも適応されていない場合、最初に実行するアプリが翻訳され、起動に通常より少し時間がかかります。
ただし、Rosetta 2 は、Intel の AVX、AVX2、または AVX512 スイートからの低レベル命令を使用するアプリを変換して実行することはできません。そのような場合、Apple Silicon を使用しているときにそれらを使用しないように、それが実行されているシステムについて問い合わせる必要があります。これらの命令は、データの種類に応じて受け取ったデータを管理する方法と、データがチップの動作方法 (プロセスではなく) にどのように影響されるかを CPU に指示するものであり、Apple Silicon には同等のものはありません。 Intel 上で実行される仮想マシンは (仮想化命令のセットも翻訳不可能なため) 動作せず、カーネル拡張機能も動作しません。カーネル拡張機能は非常に特殊な要素であり、これを使用する開発者はコードを適応する必要があります (制限事項)。すでにロゼッタを持っていました）。
Rosetta 2 に関する最後の非常に重要な注意事項: トランスレータはシステムによって更新される可能性があります。そのため、Apple は後続のバージョンで翻訳プロセスを最適化および改善することができ、翻訳されたアプリを再度実行すると、コードを改善してより最適化および効率化することで、他に何もすることなく「再翻訳」されます。さらに、アプリはデジタル署名の整合性を保持し、翻訳後にセキュリティ上の問題が発生しないことを保証します。
信じられないほどの変遷
これは私の個人的な意見であり、開発者としての長年の経験とシステムの知識に基づいたものです。そしてApple は、場合によっては再コンパイル作業など、開発者の作業をはるかに容易にする素晴らしい仕事をしてくれたと思います。 Rosetta 2 へのすべての翻訳と新しいアーキテクチャでのアプリのテストは、Apple Developer Transition Kit ( A12Z を搭載した Mac mini ) を使用してのみ実行できることに注意することが重要です。
ネイティブ開発に注力すればするほど、移行は容易になります。 Rosetta 2 には、インテルで既に使用しているアプリの大部分を問題なく引き続き楽しめるようにするという目的があることを忘れないでください。
私はとても興奮しており、新しいデバイスを試して、Apple が言うように本当に良いものであるかどうかを確認するのが待ちきれません。すぐにわかります。
