2009-04-28 14 views
6

私はそれを正しく理解していません:64ビットOSは、同じシステム上の32ビットOSよりも速くコードを実行/実行できますか?64ビットOSで開発する利点はありますか?

私は64ビットOSを使用しています。これは、従来のソフトウェアと独自のソフトウェアとの互換性の問題のみを引き起こすようです。 (Ubuntu 9.04 Jaunty amd64を実行しています)

答えて

18

私はあなたが実際に質問している質問だと思うので、私はこの回答をx86-32(IA-32)とx86-64(AMD64)に限定します。

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

さらに、AMD64アーキテクチャは、レジスタの完全な欠如であるIA-32の最大の問題の1つに対処しています。実際、これは利用可能なレジスタを2倍にします。これは、いくつかのタイプのコードにとって大きな勝利です。 (実際にはほぼすべてのコードで勝利を収めていますが、一部のアプリケーションで64ビットのメモリコストが増加し、それが衰えます)

Windows側では、MSはこれを歴史的な互換性の問題。それは古い世界からのきれいな休憩ではありませんが、それはスタートです。私は、Linuxが最初から同じ問題を抱えているとは思っていません。私は、64ビットの利点について多くの視点を持っていません。

1

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

6

(コメンテーターは注意したように、この答えはこれらの点のいくつかは、Intel/AMDのチップには適用されません、多少ジェネリックです。)

答えは:それは異なり、いくつかの理由のために:

  • 幅の広い命令では、表現力が増します(命令の種類が増えたり、命令に直接データをエンコードする能力が向上します)。そのため、マシンを流れる命令の数が減り、これは一般的に勝利です:ここで++ 64bitです。

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

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

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

  • 誰もが言いたいことは間違いありませんが、あなたはより多くのメモリを扱うことができます。

  • (これはほとんど忘れてしまいます)アーキテクチャに応じてネイティブの「ロング」サイズまたは「int」サイズが上がる可能性があります。より大きい=より多くのメモリは、移動するより多くのメモリを待つことを意味します: - 64ビット注意しない場合は注意してください。

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

+3

当然のことながら、最初の3つの点は、x86ベースのシステムには影響しません。今日は17以上の場合もあります。 – Promit

11

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

しかし、(あなたがUbuntuについて議論しているので)あなたが本当に尋ねているものであるx86対AMD64は、非常に特殊な獣です。 AMD64は、すべてのポインタを64ビットに拡張するだけでなく、 x86アーキテクチャの多くの多くの欠点を修正し、GPRの数を倍増させ、命令を簡素化して最新のCPU設計にやさしくなるようにします。このため、AMD64プラットフォームのの場合は、しか使用されませんが、64ビットになるとパフォーマンスが大幅に向上します。

ソフトウェア開発では、64ビットに移行することが理にかなっている領域が1つあります。多くのVMを実行する必要があります。いくつかのVMを実行することで、オペレーティングシステムの3 GBのメモリバリアを簡単に過ぎ去らせることができ、非常に苦労します。 (これは、32ビットシステムと64ビットシステム間のギャップを埋めるためにインテルが考案したPAE(Paged Addressing Extensions)というテクノロジーや、ページングアドレッシングエクステンションのためにはうまくいくが、その結果は遅く、開発者としてはうまくやっていない。 Windows上で非常にうまくサポートされています)。64ビットOSに移行すると、大きなメリットが得られます。

+0

これは、私が生活のパフォーマンスを測定する人々から聞いたことを反映しています。ポインタの余分なサイズとキャッシュヒット数の減少は、実際にパフォーマンスに影響します。小さくてはるかに顕著なヒットが64ビットアプリケーションを実行しています。 –

+3

境界はOSによって異なりますが、OSによっては2〜3GBです。すべての主要OSは1〜2GBのスライスを仮想空間の最上部から取り出して使用します。 PowerPCに関しては、Powerアーキテクチャには64ビットモードのいくつかの奇妙な欠点があり、32ビットモードでの実行が高速になります。ポインタの大きさだけではありません。 – Promit

+0

@Promitあなたはもちろん境界線上で正しいです。私はそれらを修正しました。 Re。 PowerPCの難しさは、アーキテクチャーが「癖」を持っていることに同意した限り、状況はSPARC v。UltraSPARCと32-bit MIPS v。64-bit MIPSでも同様でした。 Hellは、逆に、ARMがTHUMBを持っている理由、MIPSにMIPS16eがあること、そして日立SuperHが驚くほどうまくいくことです。キャッシュを吹き飛ばすことは本当に傷つきます。 –

3

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

互換性の問題:これはバグではなく、機能です。クリーンなソフトウェアを誰が書いているかを示します。

2

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

1

私はそれが少し遅くなると思っています。私はFC10でその経験を持っていました。本当の理由はありませんが、間違いなくsizeof(ポインタ)の問題ではありません。 (*)

私自身の勘違いは、あまり最適化されていないドライバや調整されたチップセットの問題であるということです。

また、NTFS-3Gは

(*)は、32ビットの下で働いている間(同じディストリビューション、同じカーネル同じパーティション、それだけでいくつかの状況で「ハング」)、64ビットの下で面白かった最もコンパイルされますディスクにバインドされ、CPUにバインドされません。さらに、x86_64アーキテクチャーには、その事実を打ち消す他の改良があります(より良いPIC、より多くのregs、SSE2デフォルトオン、686cmovデフォルトオン)。あなたのアプリがランダムに小さなブロックを動かす以外に何もしない限り。

関連する問題