Raspbianが64ビットモードに移行

で、このページ、公式RPi3の発表は述べて：

ダウンロードページから最新のNOOBSまたはRaspbianイメージが必要です。起動時には、他のRaspberry Piデバイスで使用しているのと同じ32ビットRaspbianユーザーランドを使用しています。今後数か月にわたって、64ビットモードに移行する価値があるかどうかを調査します。

私の質問は、プロセッサが64ビットであることを考えると、64ビットでOSを実行することがあらゆる点で優れていることは明らかではないでしょうか？私は何が欠けていますか？

プロセッサが64ビットであることを考えると、64ビットでOSを実行することがあらゆる点で優れていることは明らかではないでしょうか。

いいえ、実際は違います。いくつかの点で、64ビットオペレーティングシステムを実行すると、Raspberry Piのパフォーマンスが低下する可能性があります。

64ビットの利点：

64ビットプロセッサ/オペレーティングシステムを使用する2つの主な利点は、デバイスが4 GBを超えるRAMを処理でき2^32、bignumライブラリを必要とせずに、より大きな整数をネイティブに処理できることです。

Raspberry Piには4 GB以上のRAMはありません。1 GBのRAMで、2つの主要な利点のうち最初の利点を完全に失います。2番目の利点については、2番目のオペレーティングシステム全体をサポートするのに理にかなっている十分な数の人々が実際に使用しているのは何パーセントですか？現状では、RPiはソフトウェア手法で膨大な数を使用できますが、その領域に一貫してアクセスする場合は、とにかくより良いハードウェアを使用する必要があるようです。

64ビットの問題：

より大きな数を格納する機能は、魔法によって許可されていません。むしろ、メモリオブジェクトのサイズを増やす必要があります。C（およびC ++）では、これをに変更するintことを意味しint64_tます。これは自動的には行われないため、基盤に関するコメントは2つのブランチを維持することを望んでいません。

さらに、多くのアプリケーションは、64ビットモードで実行した場合、ほとんどのユーザーに利点を提供しません。ほとんどのWebブラウザー、MS Office、およびその他の一般的なソフトウェアのホストはすべて、32ビット方式で出荷および保守されています。確かに64ビットリリースのMS Officeを手に入れることができますが、めったに使用されません。

アプリケーション/オペレーティングシステムが64ビットアーキテクチャを利用するように記述されている場合、変数とポインターがより多くのスペースを占有するため、アプリケーションはより多くのメモリを使用します。通常、これは特典の恩恵を受けるマシンの比較的小さなトレードオフです。この例では、特典とRAMが非常に少なくなっています。

また注意事項：

64ビットマシンで実行しているからといって、アプリケーションが32ビットで実行されているわけではありません。Windowsは、二つの異なるインストールパスを持っていることによって、これは非常に明確になり、C:\Program FilesそしてC:\Program Files (x86)。

それで、財団は64ビットのサポートを提供するでしょうか？：

「一部の人々は利益を見るかもしれませんが、ほとんどの人はそうではないでしょう」という同じポイントに戻りました。確かに64ビットビルドを提供する他のプロジェクトを見ることができますが、基盤が多くの（imo）フラックを取得しない限り、おそらく（imo）しないでしょう。別の64ビットブランチを作成して維持することは小さな努力ではなく、正直なところ、それだけの価値はありません。

ARMとIntel / AMDでは状況が異なることに注意してください。それは、x86_64への切り替えが、経年劣化のあるアーキテクチャを更新する機会としても使用されていたためです。したがって、Intel / AMDシステムを64ビットモードに切り替えることは、パフォーマンスを大幅に向上させる実際の機能を有効にすることも意味します。

ARMには最初からこの問題はありません（AArch64はレジスタを追加しますが、32ビットアーキテクチャはそれらに飢えていませんでした）。そのため、利点は基本的に直接アドレス可能なメモリとネイティブのビッグ整数サポートです。対処し、おそらくマイナス面（すべてに使用するメモリを増やす）によって相殺されます。

（余談ですが、この理由から、Intel / AMD Linux向けに「x32」のabiを作成し、CPUの機能強化を維持しながら32ビットポインターを使用する作業がいくつかありました。）

Pi 3ですでにDebian Aarch64（ARMv8）を実行している人がいると確信しています。それは確かに多くの人々のため難しいことではないでしょう（ここで見ることかもしれない作業についてのいくつかの手がかりのために）¹用がほとんどのユーザー、それはおそらく、ストレッチのビットです。

ただし、Raspbianおよび/またはFoundationが64ビットバージョンを提供しない場合、ブログなどを使用する人が増えて、ブログの実行方法を説明しながら、必要なグッズを入手できます。

現在、Pi 3用のFedora aarch64リリースがあります。

^{1. 32ビットの/opt/vcものにはいくつかの問題がありますが、それがどれほど克服できるかわかりません。以前はx86-64用の32ビット互換ライブラリがありましたが、Aarch64 ...はそうではないかもしれません。}

ローンチ宣伝の一環として、2つの別個のコードベース（32ビットと64ビット）を維持するために必要な努力が1つの懸念であると述べました。また、Adafruit PI3 Launchビデオでは、64ビットプロセッサへの移行は、64ビットモードを使用することよりも、提供される新しいチップのクロック速度を上げることに関するものであると述べました。

64ビットアドレス指定は、1 GBを超えるメモリがない場合でも役立ちます。

大きなファイルをメモリマップできるため、ポインタがあり、OSに透過的にI / Oを実行させることができます。I / Oを行う別の方法。大きなファイルでこれを行うには、64ビットのアドレス指定が必要です。

私がそれが有用だと思う別の例は、スワップスペースを使用して、プロセスに2GB以上のアドレススペースを持たせることです。最近、大量のストレージと破損したファイルシステムを備えた32ビットNASで問題が発生しました。キャッシュオプションがオンになっていても、fsckプロセスはメモリを使い果たしました。スワップスペースを追加しても問題を解決できませんでした。32ビットアドレススペースがハード制限でした。そのため、32ビットバイナリを使用して、この大きな破損したファイルシステムでfsckを実行する方法はありませんでした。64ビットのバイナリといくつかのスワップスペースがあれば、実行されていたはずです。

64ビットネイティブプログラムが大きく（データとポインター用のメモリが多い）、4 GB未満のRAMを搭載したARMv8上の64ビットと32ビットOSに顕著な利点がないという主張に対処するために、ポイント。

ARMv7（およびそれ以前）とARMv8でのアーキテクチャー上の処理方法には、ARMv8の実行をより効率的にするいくつかの大きな違いがあります。これには、より広い内部データパスによるもの、特殊なケースの排除、およびより深いパイプラインによるものがあります）。これらの同じ変更により、ARMv7（32ビット）コードの実行でARMv8が改善されます。

ネイティブ64ビットアプリケーションは64ビットポインターを使用し、 'size_t'は64ビットなので、それらを使用する要素は大きくなります。残りのデータは同じサイズのままになる傾向があります。ただし、これの重要性は、実行可能イメージのサイズにとってはわずかです。

64ビットネイティブが本当に優れている場合（大きな整数や浮動小数点のことを気にしない場合）は、より大きな仮想アドレス空間を持っています。

• OSは仮想アドレス空間をより多くの大きなセクションに分割することができ、共有リソースの管理を容易にしたり、異なるレベルの特権間でコンテキストスイッチをより合理化したりすることができます。
• スワッピングを有効にすると、物理メモリの制限を超えて、より大きなプロセスを実行できます（これは実際には32ビットでも同様ですが、64ビットではそれほど制限されません）

OSが現在これを利用しているかどうかに関係なく、メインストリームが32ビットから遠ざかるにつれて、違いが生まれます。

ネイティブの64ビットAArch64カーネルに移行するための最良の議論は移植性だと思います。主流のデスクトップはほとんど64ビットプロセッサに移行しました。 32ビットから64ビットへの移植よりも。ユーザー空間では、32ビットアプリケーションと64ビットアプリケーションを並行して実行できます。マルチアーチライブラリをインストール済みであれば、32ビットから64ビットに移植する必要はありません。案件。64ビットOSを使用すれば、より多くのソフトウェアを選択できます。

Raspberry PI 3用の64ビットカーネルの作成は簡単だと言っているわけではありません。低レベルでの変更が必要な大きな違いがあります。Raspberianは32ビットOSのままである可​​能性がありますが、（長期的には）近視眼的であると思います。

単一のブートメディア（たとえば、SDカード）には、64ビットバージョンと32ビットバージョンの両方のOSを含めることができ、セカンダリブートソフトウェア（u-boot、arm-boot、およびその他）はどちらをロードするかを決定できます。難しい部分はユーザーランドです。64ビットのデータが役に立たない32ビットシステムであっても、ファイルシステムはマルチアーチである必要があります。32ビットのみのシステムで不要なライブラリとプログラム実行可能ファイルを削除するために、初期ブート後に実行できるスクリプトまたはユーティリティを使用して、これに対処します。

既存の回答は64ビットアーチの問題を非常によくカバーしていますが、アップグレードの利点についてはあまり述べられていません。だから、ここで私が最近発見した2つです：

• PHPがUnixタイムスタンプを処理するとき、32ビットアーチの整数サイズは、2038年の特定の日を超えることができないように、日付の上限を設定します。これはタイムスタンプを処理するすべての言語の問題だと思います。（ありがたいことに、PHPのDateTimeなど、Unixタイムスタンプを使用しないほとんどの日付処理サブシステムは、特に古いCPUでもこの問題によって制限されないように設計されています）。

• Mongoはこのアーキテクチャで2G未満のサイズのデータ​​ベースに制限されており、32ビットビルドは間もなく廃止されます。マニュアルから：

  MongoDB 3.2以降、32ビットバイナリは非推奨になり、将来のリリースでは使用できなくなります。

  LinuxおよびWindows用の32ビットビルドは存在しますが、実稼働展開には適していません。32ビットビルドは、WiredTigerストレージエンジンもサポートしていません。

これについての私の考え：ARMプロセッサがメモリをどのようにアドレスするかは正確にはわかりませんが、以前にプログラムした複数のCPUアーキテクチャ（SPARC / Alpha / i386 / AMD64 / X86_64）からこれを伝えることができます：共有メモリとアドレス指定を使用する場合「実際の」仮想アドレスポインターによって、64ビットへの移行は簡単ではありません。memcpyは本来の動作を行いますが、64ビットではデータが次のように格納されることを考慮する必要があります（ビットを逆方向に）：

HGFEDCBA
HGFEDCBA
HGFEDCBA

まだ32ビットでは次のようになります。

ABCD
ABCD
ABCD

したがって、32ビットでは、たとえばjpegをRAMに格納すると、ヘッダーバイトを読み取るか、エッジ検出を行うことができます。しかし、64ビットアーキテクチャでは、これが変わります。

32ビット：

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64ビット：

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}