ブログ投稿のやや遅れた翻訳で、マーケティングの殻なしで実際にiPhoneで64ビットプロセッサを提供するものに興味がありました。 テキストがわかりすぎている場合は、「基本的な長所と短所」セクションをスキップしてください。



iPhone 5Sが発表されるやいなや、テクニカルメディアは不正な記事で一杯になりました。 残念ながら、良い記事を書くには時間がかかり、技術ジャーナリズムの価値観の世界は信頼性よりもスピードが速い。 今日、読者の何人かの要望に応じて、パフォーマンス、機能、開発の観点から、iPhone 5Sで64ビットARMを提供するものについて簡単に説明します。

64ビット

最初に、実際には64ビットの意味を見てみましょう。 この用語には多くの混乱がありますが、これは主に単一の十分に確立された定義がないという事実によるものです。 ただし、この用語には共通の理解があります。 「ビットネス」は通常、数値レジスタのサイズまたはポインターのサイズのいずれかを意味します。 幸いなことに、最新のプロセッサのほとんどは、サイズが同じです。 したがって、64ビットとは、プロセッサに64ビット数値レジスタと64ビットポインターがあることを意味します。



また、64ビットが意味するものではないことに注意することも重要です。 そして多くの誤解があります。 したがって、64ビットは以下を決定しません。

1. アドレス可能なメモリのサイズ。 ポインターで実際に使用されるビット数は、プロセッサーのビットとは関係ありません。 ARMプロセッサは26〜40ビットを使用しますが、この数はプロセッサビットとは異なる場合があります。
   
   
2. データバスの幅。 RAMまたはキャッシュから要求されるデータの量もビットレートに関係しません。 個別のプロセッサ命令は任意の量のデータを要求できますが、実際に要求されたデータの量は異なる場合があり、要求を部分に分割するか、必要以上に要求します。 すでにiPhone 5では、要求されたデータブロックのサイズは64ビットですが、PCは192ビットに達します。
   
   
3. 浮動小数点計算に関連するすべて。 FPUレジスタはアーキテクチャ関連ではなく、ARMプロセッサはARM64よりもずっと前に64ビットレジスタを使用していました。
   
   

基本的な長所と短所

同一のプロセッサを32ビットCPUと64ビットCPUで比較すると、大きな違いは見られないため、Appleから64ビットARMへの移行の重要性はいくぶん誇張されています。 これは重要なステップですが、主にARMの機能とアップルのプロセッサを使用する特性のために重要です。 ただし、いくつかの違いがあります。 最も明らかなのは、64ビット数値レジスタが64ビット数値でより効率的に機能することです。 64ビットの数値と32ビットプロセッサで作業できますが、通常は2つの32ビットパーツで作業することになり、動作が大幅に遅くなります。 原則として、64ビットプロセッサは、32ビットの演算と同じくらい高速に64ビットの演算を実行するため、64ビットの演算を積極的に使用するコードは非常に高速に動作します。



64ビットはアドレス可能なメモリの量に直接関係しないという事実にもかかわらず、単一のプログラムで大量のRAMの使用を大幅に促進します。 32ビットプロセッサで実行されているプログラムは、4GBを超えるアドレス空間をアドレス指定できません。 メモリの一部はオペレーティングシステムと標準ライブラリに割り当てられ、プログラム自体に1〜3 GBが残ります。 32ビットシステムに4GB以上のRAMがある場合、このアドレススペースをすべてプログラムに使用するのははるかに複雑です。 RAMのさまざまな部分を仮想アドレス空間の一部に順番にマッピングしたり、1つのプログラムを複数のプロセスに分割したりするような詐欺に対処する必要があります。



このようなトリックは非常に時間がかかり、システムの速度を大幅に低下させる可能性があるため、実際に使用するプログラマーはほとんどいません。 実際には、32ビットプロセッサでは、各プログラムは最大1〜3 GBのRAMを使用します。物理RAMを増やすことのすべての価値は、より多くのプログラムを同時に実行できることと、ディスクからより多くのデータをキャッシュできることです。



アドレス空間の増加は、RAMが少量のシステムにも役立ちます。これは、サイズが使用可能なRAMよりも大きい可能性があるメモリマップファイルです。 オペレーティングシステムは、実際にアクセスされたファイルの部分のみをダウンロードし、さらに、ダウンロードしたデータをファイルに「絞り出す」ことができ、RAMを解放します。 32ビットシステムでは、1〜3 GBを超えるファイルは表示できません。 64ビットシステムでは、アドレススペースがはるかに大きいため、このような問題はありません。



ポインターのサイズを大きくすることもマイナスになります。64ビットプロセッサで実行する場合、同じプログラムがより多くのメモリ（場合によってはそれ以上）を使用します。 また、メモリ使用量を増やすとキャッシュが詰まり、パフォーマンスが低下します。



簡単に言うと、64ビットはコードの一部のパフォーマンスを向上させ、メモリマップファイルなどのいくつかの手法を簡素化できます。 ただし、メモリ使用量の増加によりパフォーマンスが低下する場合があります。

ARM64

iPhone 5Sの64ビットプロセッサは、レジスタサイズが増加したARMだけでなく、大きな変更があります。



まず、名前に言及します。ARMの正式名は「AArch64」ですが、これは入力に悩まされる馬鹿げた名前です。 AppleはARM64アーキテクチャを呼び出し、名前も付けます。



ARM64は整数レジスタの数を2倍にしました。 32ビットARMは16個の整数レジスタを提供し、そのうちの1つはプログラムカウンタであり、さらに2つはスタックおよびリンクレジスタへのポインタと13個の汎用レジスタに使用されます。 ARM64には32個の整数レジスタがあり、専用のゼロレジスタ、通信レジスタ、およびフレームポインタレジスタがあります。 別のレジスタがプラットフォームによって予約されており、28個の汎用レジスタが残っています。



ARM64では、浮動小数点数のレジスタ数も増加します。 32ビットARMのレジスタはやや奇妙なので、比較するのは困難です。 32ビットARMには32個の32ビット浮動小数点レジスタがあり、16個の重複する64ビットレジスタとして表すことができます。 さらに、16個の独立した64ビットレジスタがあります。 ARM64は、これを32個の重複しない128ビットレジスタに簡素化し、より小さなデータに使用できます。



レジスタの数は、パフォーマンスに大きく影響します。 メモリはプロセッサよりも大幅に遅く、メモリの読み取り/書き込みはプロセッサの命令を実行するよりも大幅に時間がかかります。 プロセッサはキャッシュでこれを修正しようとしますが、最速のキャッシュでさえプロセッサのレジスタよりもはるかに遅くなります。 より多くのレジスタ-より多くのデータをプロセッサ内に保存できます。 これがパフォーマンスにどの程度影響するかは、特定のコードと、レジスターの使用を最適化するコンパイラーの有効性によって決まります。 Intelが32ビットから64ビットに移動したとき、レジスタの数は8から16に増加し、これはパフォーマンスの大きな変化でした。 ARMはすでにIntelの32ビットアーキテクチャよりも多くのレジスタを備えていたため、レジスタを増やすとパフォーマンスは低下しますが、この変化は依然として顕著です。



ARM64では、レジスタ数の増加に加えて重要な変更も導入されました。



ほとんどの32ビットARM命令は、register-conditionの状態に応じて実行される場合と実行されない場合があります。 これにより、分岐を使用せずに条件式（ifステートメント）を変換できます。 これは生産性を向上させると考えられていましたが、ARM64がこの機会を拒否したという事実から判断すると、それは何よりも多くの問題を引き起こしました。



ARM64では、NEON SIMD（1命令多データ）セットのNEONは、倍精度浮動小数点数のIEEE754標準を完全にサポートしますが、NEONの32ビットバージョンは単精度のみをサポートし、一部のビットの標準に厳密に従いませんでした。



ARM64は、AES暗号化とSHA-1およびSHA-256ハッシュ用の特別な命令を追加しました。 一般的にはあまり有用ではありませんが、これらの問題に対処する場合の大きなボーナスです。



一般に、最も重要な違いは、汎用レジスタの数の増加と、NEONの倍精度数でのIEEE754互換算術の完全サポートです。 これにより、多くの場所で生産性を目に見える形で高めることができます。

32ビットアプリケーションの互換性

A7には32ビット互換モードが含まれており、変更することなく32ビットアプリケーションを実行できることに注意してください。 つまり、iPhone 5Sはパフォーマンスに影響を与えることなく、古いアプリケーションを実行できます。

実行期間システムの変更

Appleは、ライブラリの新しいアーキテクチャを活用しています。 このような変更に対するバイナリの後方互換性について心配する必要がないため、これは既存のアプリケーションを「壊す」ような変更を加える絶好の機会です。



Max OS X 10.7では、Appleはタグ付きポインターを導入しました。 ラベル付きポインタを使用すると、インスタンス内の少量のデータを含む一部のクラスをポインタに直接格納できます。 これにより、NSNumberなどのいくつかのケースでのメモリ割り当てが回避され、パフォーマンスが大幅に向上します。 タグ付きポインターは64ビットプラットフォームでのみサポートされます。これは、一部はパフォーマンスの問題によるものであり、一部は32ビットポインターの「タグ」用のスペースがあまりないためです。 このように、iOSはラベル付きポインターをサポートしていなかったようです。 したがって、ARM64のObjective-Cランタイムでは、ラベル付きポインターのサポートが含まれており、Macと同じ利点が得られます。



ポインターのサイズが64ビットであるという事実にもかかわらず、これらのビットのすべてが実際に使用されるわけではありません。 x86-64上のMac OS Xは47ビットのみを使用します。 ARM64上のIOSはさらに少なく、33ビットしか使用しません。 使用する前に毎回これらのビットをマスクすると、残りのビットを使用して追加データを保存できます。 これにより、Objective-Cランタイムの歴史の中で最も重要な変更の1つが可能になりました。

isaポインターの再考

このセクションの情報のほとんどは、 グレッグパーカーの記事からのものです。 まず、メモリを更新するには：Objective-Cのオブジェクトは、割り当てられたメモリブロックを表します。 最初の部分であるポインターのサイズはisaです。 通常、isaはオブジェクトクラスへのポインタです。 オブジェクトがメモリに保存される方法について詳しくは、他の記事をご覧ください 。



特にすべての64ビットを使用しない64ビットプラットフォームでは、ポインターのサイズ全体をisaポインターに使用するのは多少無駄です。 iOS上のARM64は実際には33ビットを使用しますが、31ビットは他のものに使用します。 メモリ内のクラスは8バイトの境界で整列しているため、最後の3ビットは破棄できます。これにより、isaから34ビットが追加情報の格納に使用できます。 Apple64のARM64ランタイムはこれを使用してパフォーマンスを向上させます。



おそらく、最も重要な最適化はインラインリンクカウンターでした。 Objective-Cのほとんどすべてのオブジェクトには参照カウンターがあり（NSStringリテラルなどの不変オブジェクトを除く）、このカウンターを変更する保持/解放操作は非常に頻繁に発生します。 これは、ARCにとって特に重要です。ARCでは、プログラマが行うよりも頻繁に保持/解放呼び出しを挿入します。 したがって、保持/解放メソッドの高いパフォーマンスが重要です。



通常、参照カウントはオブジェクト自体には保存されません。 オブジェクト自体に参照カウンターを保存することは可能ですが、これはスペースを取りすぎます。 これは今ではそれほど重要ではありませんが、それからずっと前に非常に重要でした。 このため、参照カウントは外部ハッシュテーブルに格納されます。 retainを呼び出すたびに、次のアクションが実行されます。

1. ポインターカウンターのグローバルハッシュテーブルを取得する
   
   
2. ハッシュテーブルをロックして、操作がスレッドセーフになるようにします
   
   
3. 特定のオブジェクトのハッシュテーブルでカウンターを見つける
   
   
4. カウンターを1つ増やして、テーブルに保存します
   
   
5. ハッシュテーブルロックを解除する
   
   

十分遅い！ カウンターのハッシュテーブルの実装は、ハッシュテーブルに対して非常に効率的になりますが、メモリへの直接アクセスよりもはるかに低速です。 ARM64では、19ビットのisaポインターが参照カウントの保存に使用されます。 これは、retain呼び出しが次のように簡略化されることを意味します。

1. isaフィールドの一部でアトミック増加を生成するには
   
   

そしてそれだけです！ それははるかに速いはずです。



実際、処理が必要なエッジケースが異なるため、すべてが多少複雑になります。 アクションの実際のシーケンスは、およそ次のとおりです。

1. isaの最後のビットは、isaの追加ビットを使用して参照カウントを保存するかどうかを示します。 そうでない場合は、古いハッシュテーブルアルゴリズムが使用されます。
   
   
2. オブジェクトが既に削除されている場合、何も行われません
   
   
3. カウンターがオーバーフローする場合（めったに起こりませんが、19ビットではかなり可能です）、古いハッシュテーブルアルゴリズムが使用されます
   
   
4. isaを新しい値にアトミックに変更します
   
   

これらのアクションのほとんどは、以前のアプローチでも引き続き必要であり、操作をあまり遅くしませんでした。 そのため、新しいアプローチは古いアプローチよりも大幅に高速です。



isaの参照カウンタの下で未使用のビットを使用すると、オブジェクトの割り当て解除を高速化できます。 理論的には、Objective-Cのオブジェクトが削除されたときに一連のアクションを実行する必要があり、不要なオブジェクトをスキップする機能によりパフォーマンスが大幅に向上します。 これらの手順は次のとおりです。

1. オブジェクトにobjc_setAssociatedObjectを使用して設定された関連オブジェクトがなかった場合、それらを削除する必要はありません。
   
   
2. オブジェクトにC ++デストラクタ（dealloc中に呼び出される）がない場合は、呼び出す必要もありません。
   
   
3. オブジェクトが弱い（__weak）ポインターによって参照されたことがない場合、これらのポインターを無効にする必要はありません。
   
   

以前は、これらのフラグはすべてクラスに保存されていました。 たとえば、クラスの少なくとも1つのインスタンスが関連オブジェクトを格納したことがある場合、このクラスのすべてのインスタンスは、割り当て解除中に関連オブジェクトを削除しました。 インスタンスごとにこれらのフラグを追跡することで、本当に必要なインスタンスに対してのみ適切なメソッドを呼び出すことができました。



全体として、これは大きな利益です。 私のベンチマークでは、単純なオブジェクトの作成と削除には、32ビットモードでは5Sで380nsかかりますが、64ビットでは200nsしかかかりません。 少なくとも1つのインスタンスがそれ自体への弱い参照を持っている場合、32ビットモードではすべての削除時間が480 nsに増加し、64ビットモードでは、弱いリンクがないすべてのインスタンスで200 nsの領域に残りましただった。



つまり、実行時間の改善により、64ビットモードでは32ビットモードでの割り当て時間が40〜50％になります。 アプリケーションが多くのオブジェクトを作成および削除する場合、これは重要です。

おわりに

64ビットA7は単なるマーケティング策略ではありませんが、新しいクラスのアプリケーションを作成できる驚くべきブレークスルーでもありません。 真実は、いつものように、真ん中にあります。



64ビットに切り替えるという単なる事実は少しだけです。 これにより、場合によってはアプリケーションが高速化され、ほとんどのプログラムで使用されるメモリ量がわずかに増加します。 一般に、大きな違いはありません。



ARMアーキテクチャは、64ビットだけでなく変更されました。 レジスタの数が増え、命令セットが改訂され、合理化されたことにより、32ビットARMと比較してパフォーマンスが大幅に向上しました。



Appleは、ランタイムを改善するために新しいアーキテクチャへの移行を使用しました。 主な変更点は、インラインリンクカウンターです。これにより、高価なハッシュテーブル検索が回避されます。 Objective-Cでは、保持/解放操作が非常に一般的であるため、これは大きな利点です。 フラグに基づいてリソースを削除すると、オブジェクトの削除がほぼ2倍速くなります。 タグ付きポインタは、パフォーマンスを向上させ、メモリ消費を削減します。



ARM64はAppleからの素晴らしい追加です。 遅かれ早かれこれが起こることは誰もが知っていましたが、そうすぐになると予想した人はほとんどいません。 しかし、それは素晴らしいことです。