64ビットOSで開発することに利点はありますか？

Question

それを適切に理解しているかどうかわかりません：64ビットOSは、同じシステム上で32ビットOSよりも速くコードを実行/コンパイルしますか？

私は現在64ビットOSを使用していますが、レガシーおよびプロプライエタリソフトウェアとの互換性の問題のみを引き起こすようです。 （Ubuntu 9.04 Jaunty amd64を実行しています）

Answer 1

この回答をx86-32（IA-32）対x86-64（AMD64）に制限します。これはあなたが実際に尋ねている質問だと思います。

プロセッサレベルでは、いくつかの利点があります。まず最も明白なのは、プロセスごとの仮想メモリが48ビットのはるかに広い範囲に拡張されていることです。 （アーキテクチャでは64が許可されますが、メモリが提供される場合は必須ではありません。）これにより、アプリケーションは使用可能なシステムのメモリをより多く使用できるようになります。実メモリにリンクされていない仮想メモリ。また、データの4 GBの制限を共有する必要がないため、問題のOSが動作するための多くのスペースを開きます。つまり、アプリケーションとOSはマシンのリソースをより有効に活用できます。

さらに、AMD64アーキテクチャは、IA-32の最大の問題の1つであるレジスタの完全な不足に対処します。実際、利用可能なレジスタを2倍にします。これは、ある種のコードにとっては大きな勝利です。 （実際には、ほぼすべてのコードで勝ちですが、一部のアプリケーションは64ビットのメモリコストの増加に苦しんでいます。）

Windows側では、MSは、歴史的な互換性の問題のすべてを解消する機会と捉えました。それは古い世界からのきれいな休憩ではありませんが、それは始まりです。 Linuxがそもそも同じ問題に苦しんでいるとは思いませんし、64ビットの利点について提供する見通しもあまりありません。

Answer 2

原則として、64ビットオペレーティングシステムの開発（または使用）は、どのコンテキストでも、同じ32ビットオペレーティングシステムよりも遅いことになります。すべてのポインターが突然2倍の大きさになるため、キャッシュを爆破する可能性がはるかに高くなり、RAMに収まるデータが少なくなります。それはあなたのアプリケーションをかなり遅くします。通常、アプリケーションが2〜3 GBを超えるデータに同時に対処する必要がある場合にのみ64ビットシステムを使用します。これは、科学計算や一部のデータベース状況では非常に一般的ですが、それ以外の場合は非常にまれです。これが、Appleが64ビットモードでPowerPCアプリケーションを無条件にコンパイルすることを推奨していない理由です。たとえば、キャッシュミスやメモリ不足によるコストが高いため、64ビットに移行することは、本当に64ビットスペース。

しかし、x86 v。AMD64は（Ubuntuについて議論しているので）あなたが本当に求めているのは非常に特別な獣です。 AMD64は、すべてのポインターを64ビットに拡張するだけではありません。 x86アーキテクチャの多くの多くの欠陥を修正し、GPRの数を2倍にし、命令を簡素化して現代のCPU設計によりわかりやすくします。このため、 AMD64プラットフォームのみでは、64ビットに移行するとパフォーマンスが大幅に向上することがよくあります。

ソフトウェア開発では、64ビットに移行することが理にかなっている領域がもう1つあります。多くのVMを実行する必要があります。いくつかのVMを実行すると、オペレーティングシステムの3 GBのメモリバリアを簡単に超えてしまい、使用が非常に苦痛になります。 （これは、Intelが32ビットシステムと64ビットシステムのギャップを埋めるために発明したPAE（Paged Addressing Extensions）と呼ばれる技術により機能しますが、結果は遅く、開発者として作業するのは苦痛であり、 64ビットOSに移行すると、多大なメリットが得られます。

Answer 3

（コメンテーターが指摘しているように、この回答は多少一般的であり、これらの点のいくつかはインテル/ AMDチップには適用されません。）

答えは次のとおりです。いくつかの理由により異なります：

• 幅の広い命令を使用すると、表現力が向上します（命令の種類が増えるか、命令にデータを直接エンコードする能力が向上します）。これにより、流れる命令の数が減ります。一般的には勝利であるマシン：++ 64bitがここにあります。

• しかし、より大きな命令は、より複雑になる可能性があるため、デコードおよび実行するのにより多くのサイクルが必要になる場合があります 。ここで--64ビットが可能です。

• また、CPUとの間でこれらの命令を転送する必要があります。64ビット命令は32ビット命令の2倍の大きさです。つまり、メモリとキャッシュとの間のトラフィックが増えます。 CPUはこのコストの多くを改善するように構成されていますが、ここではわずか--64ビットです。

• 通常、より広い命令セットでより多くのレジスタを使用できるため、スタックやメモリとの間でやり取りされるデータトラフィックが少なくなります。 ++ 64bitがここにあります。

• そして誰もが間違いなく言及するように、より多くのメモリに対処する能力があります。

• （これはもうほとんど忘れていました）ネイティブの「長い」または＆quot; int＆quot;アーキテクチャによってはサイズが大きくなる場合があります。つまり、これらに基づくデータ構造は大きくなります。大きい=移動するメモリが多いため、データの移動を待機する可能性が高くなります。注意していない場合は--64ビットです。

アーキテクチャによっては、他の多くの懸念事項も当てはまる場合があります。プロセッサーとコンパイラーのベンダーは、上記の「-」を減らして「++」を増やすために努力しているので安心できます。

Answer 4

変換が必要なこの5GByteデータベースがあります。 64ビットシステムでは、すべてのデータをコレクションに入れるだけです。 32ビットシステムでは、読み込みと変換の順序を考える必要がありました。問題はランタイムではなく、エンジニアリング時間です。 64ビットに切り替えると、開発時間が数週間節約されます。

互換性の問題：それはバグではなく、機能です。誰がきれいなソフトウェアを書いたかを示しています。

Answer 5

64ビットオペレーティングシステムを使用することには、いくつかのセキュリティ上の利点もあります。総当たりによるアドレス空間レイアウトのランダム化を回避するバッファオーバーフローエクスプロイトがいくつかありました。 64ビットOSでは、この種の攻撃が成功するにはアドレスが多すぎます。

Answer 6

コンパイルプロセスがメモリバウンドであり、64ビットOSを使用してシステムで使用可能なメモリ量を増やすと、コンパイルが高速化されます。

Answer 7

やや遅くなると思われますが、FC10での経験がありました。本当の理由はありませんが、sizeof（pointer）の問題ではありません。 （*）

私自身の考えは、それは単に最適化されていないドライバーまたは調整されたチップセットの問題であるということです。

また、NTFS-3gは64ビットではおかしくなりましたが、32ビットでは動作しました（同じディストリビューション、同じカーネル、同じパーティション、状況によっては "ハング"）

（*）ほとんどのコンパイルは、CPUバウンドではなくディスクバウンドです。さらに、x86_64アーキテクチャには、その事実を打ち消す他の改善点があります（より良いPIC、より多くのreg、SSE2のデフォルトオン、686 cmovのデフォルトオン）。アプリが小さなブロックをランダムに移動する以外に何もしない限り。