32ビットシステムと64ビットシステム
32ビットシステムと64ビットシステムの違いは何ですか？
両方を使用したことがある場合、どのような大きな違いがありますか？
場合によっては、64ビットシステムで32ビットプログラムを使用することは問題になりますか？
注：これらの回答は、標準のx86ベースのPC CPU（IntelおよびAMD）およびWindows（通常、エンドユーザー向けに構成されている）に適用されます。他の32ビットまたは64ビットチップ、他のOS、および他のOS構成には、異なるトレードオフがあります。
技術的な観点から、64ビットOSは以下を提供します：
個々のプロセスがそれぞれ4 GBを超えるRAMに対応できるようにします（実際、ほとんどの32ビットOSではありませんが、使用可能なシステムの合計RAMは4 GB未満に制限されます。アプリケーションごとの最大値のみ）。
すべてのポインターは、4バイトではなく8バイトを使用します。 RAM使用量への影響はごくわずかです（ギガバイトのポインターでアプリケーションがいっぱいになる可能性は低いため）が、最悪の理論的なケースでは、CPUキャッシュが1/2個のポインター（実質的にサイズの1/2にする）。ほとんどのアプリケーションでは、これは大した問題ではありません。
64ビットモードには、さらに多くの汎用CPUレジスタがあります。レジスタは、システム全体で最も高速なメモリです。 32ビットモードでは8個、64ビットモードでは16個の汎用レジスタがあります。私が書いた科学計算アプリケーションでは、64ビットモードで再コンパイルすることで最大30％のパフォーマンス向上が見られました（私のアプリケーションは実際に追加のレジスタを使用できます）。
実際、ほとんどの32ビットOSでは、4 GBがインストールされていても、個々のアプリケーションで2 GBのRAMしか使用できません。これは、他の2 GBのアドレススペースが、アプリケーション間、OSとのデータ共有、およびドライバーとの通信用に予約されているためです。 WindowsとLinuxでは、このトレードオフをアプリケーション用に3 GB、共有用に1 GBに調整できますが、これにより、変更を予期しない一部のアプリケーションで問題が発生する可能性があります。また、1 GBのRAMを搭載したグラフィックカードに障害が発生する可能性があると推測しています（しかし、わかりません）。 64ビットOSは、個々の32ビットアプリケーションを4 GBに近づけることができます。
ユーザーの観点から：
通常、アプリケーションの速度は、32ビットOS上の32ビットバージョンのアプリケーションと比較して、64ビットOSの64ビットアプリケーションの方が高速ですが、ほとんどのユーザーにはこの高速化は見られません。通常のユーザー向けのほとんどのアプリケーションは、余分なレジスターを実際に活用していないか、キャッシュを埋める大きなポインターによって利点が相殺されています。
メモリホグアプリケーション（フォトエディター、ビデオ処理、科学計算など）がある場合、3 GBを超えるRAMを持っている（または購入できる）場合、64ビットバージョンのアプリケーションを入手できます。選択は簡単です。64ビットOSを使用してください。
一部のハードウェアには64ビットドライバーがありません。切り替える前に、マザーボード、すべてのプラグインカード、およびすべてのUSBデバイスを確認してください。 Windows Vistaの初期には、ドライバーに多くの問題があったことに注意してください。最近の状況は一般的に優れています。
一度に非常に多くのアプリケーションを実行してRAMを使い果たした場合（通常、コンピューターが非常に遅くなり始め、ハードディスクドライブの音が聞こえるので、これを知ることができます） 64ビットOS（および十分なRAM）が必要です。
64ビットWindowsで32ビットアプリケーション（ドライバーは除く）を問題なく実行できます。 64ビットWindowsの32ビットアプリケーションで測定した最悪のスローダウンは約5％です（つまり、32ビットWindowsで何かを行うのに60秒かかった場合、最大で60 * 1.05 = 65秒かかりました64ビットWindowsの同じ32ビットアプリケーション）。
2ビットと64ビットが行うことnot意味：
X86システムでは、32ビットと64ビット直接はポインターのサイズを指します。それで全部です。
C
intタイプのサイズは参照しません。これは特定のコンパイラの実装によって決定され、一般的なコンパイラのほとんどは64ビットシステムで32ビットintを選択します。直接ではなく、通常の非ポインタレジスタのサイズを参照しません。ただし、64ビット算術レジスタを使用するには、アプリケーションとOSも64ビットポインターモードで実行する必要があります。
物理アドレスバスのサイズを直接参照することはありません。たとえば、64ビット幅のキャッシュラインと最大512GiBのメモリを搭載したシステムでは、アドレスバスに33ビットしか必要ありません（つまり、
log2(512*1024**3) - log2(64) = 33）。物理データバスのサイズを指すものではありません。製造コスト（CPUソケットのピンの数）とキャッシュラインサイズに関連しています。
基本的に、あなたはもっと大きな規模ですべてをやることができます。
- OSごとのRAM：RAM OS用x86上の4GBの制限（ほとんどの場合）
- プロセスごとのRAM：RAMプロセス上のx86上の4GBの制限（常に）。これが重要ではないと思われる場合は、巨大なMSSQLデータベース集約型アプリケーションを実行してみてください。あなたがそれを利用可能にしそしてずっと良く走らせるなら、それはそれ自身> 4GBを使います。
- アドレス：アドレスは32ビットではなく64ビットなので、より多くのメモリを使用する「より大きな」プログラムを使用できます。
- プログラムで利用可能なハンドル：もっと多くのファイルハンドル、プロセスを作成することができます... Windows x64では、1プロセスあたり2000個を超えるスレッドを作成できますが、x86では数百に近い。
- 幅広いプログラムが利用可能です。x64からは、x86とx64の両方のプログラムを実行できます。 （例windows：wow64、windows 64エミュレーション上のwindows 32）
- エミュレーションオプション：x64からは、x86とx64の両方のVMを実行できます。
- 高速：64ビットCPUでは計算が速い
- 複数のシステムリソースを分割する：少なくとも1つのRAMを分割して実行する場合は、VMメモリが非常に重要です。システムリソース。
- 利用可能な専用プログラム：いくつかの新しいプログラムはx64のみをサポートします。 Exchange 2007の例.
- 将来廃止されたx86？：今後、64ビットが使用されるようになり、x86は使用されなくなります。そのため、ベンダーは64ビット以上のものしかサポートしないでしょう。
2つの大きなタイプの64ビットアーキテクチャはx64とIA64アーキテクチャです。しかし、x64はこれまでで最も人気があります。
x64はx64コマンドと同様にx86コマンドを実行できます。 IA64もx86コマンドを実行しますが、SSE拡張は行いません。 x86命令を実行するためのItanium専用のハードウェアがあります。それはエミュレータですが、ハードウェアです。
@Philが述べたように、あなたはそれがここでどのように動くのか のより深い外観を得ることができます 。
現時点で気付く最大の影響は、32ビットPCは最大4GBのメモリしかアドレス指定できないことです。オペレーティングシステムによって他の用途に割り当てられたメモリを解放すると、お使いのPCはおそらく3.25GB程度の使用可能なメモリしか表示しないでしょう。 64ビットに移動すると、この制限はなくなります。
あなたが深刻な開発をしているなら、これは非常に重要かもしれません。複数の仮想マシンを実行してみると、すぐにメモリ不足になります。サーバーは追加のメモリを必要とする可能性が高いため、64ビットの使用量はデスクトップよりもサーバーの方がはるかに多いことがわかります。ムーアの法則により、マシン上のメモリはこれまで以上に増えることが保証されます。そのため、ある時点でデスクトップも標準として64ビットに切り替わります。
プロセッサの違いについてのより詳細な説明については、 ArsTechnica からこの素晴らしい記事をチェックしてください。
無料のものは何もありません。64ビットアプリケーションは32ビットアプリケーションよりも多くのメモリにアクセスできますが、欠点はです。 ）より多くのメモリが必要です。これまで4バイトを必要としていたポインタはすべて8バイトを必要とします。たとえば、Emacsのデフォルト要件は、64ビットアーキテクチャ用に構築されている場合、60％多くのメモリが必要です。実行可能ファイルが大きいほどディスクからのロードに時間がかかり、作業セットが大きいほどページングが多くなり、オブジェクトが大きくなるとプロセッサキャッシュへの収まりが少なくなるため、メモリ階層のあらゆるレベルでパフォーマンスが低下します。 16KのL1キャッシュを持つCPUを考えてみると、32ビットのアプリケーションはミスしてL2キャッシュに入る前に4096個のポインタで動作できますが、64ビットのアプリケーションでは2048個のポインタでL2キャッシュに到達する必要があります。
X64ではこれは他のレジスタのようなアーキテクチャ上の改善によって緩和されますが、PowerPC上でアプリケーションが> 4Gを使用できない場合は "ppc64"より "ppc"の方が速く動くでしょう。 Intel上でさえ、x86上でより速く動作するワークロードがあり、x64上でx86より5％以上速く動作するものはほとんどありません。
64ビットOSはより多くのRAMを使用できます。それは実際にはそれについてです。 64ビットVista/7は、重要なコンポーネントをRAMのどこに配置するかについて、より安全な機能を使用していますが、実際には「注目に値する」わけではありません。
ChrisInEdmontonから：
PAEを搭載したix86システム上の32ビットオペレーティングシステムは、最大64 GBのRAMをアドレス指定できます。 x86-64上の64ビットオペレーティングシステムは、最大256個のTBの仮想アドレス空間にアクセスできますが、これは後続のプロセッサでは最大16 EBまで発生する可能性があります。オペレーティングシステムによってはアドレス空間をさらに制限していることに注意してください。ほとんどのマザーボードには追加の制限があります。
私は全部のエッセイを書くことなしにあなたのすべての質問に答えることができるかどうかわからない（いつもグーグル...がある）、しかしあなたはあなたのアプリケーションを64ビットのために別に設計する必要はない。ここで言及されているのは、ポインタサイズがintと同じサイズではなくなるようなことに注意する必要があるということです。また、特定の種類のデータの長さが4バイトであり、もはや当てはまらない可能性があるという、組み込みの前提条件に関する潜在的な問題がたくさんあります。
これは、アプリケーション内のあらゆる種類のもの、つまりファイルからの保存/ロード、データの反復処理、データの整列、データに対するビット単位の操作まで、あらゆることを引き起こす可能性があります。もしあなたがあなたが移植しようとしている、あるいはその両方で作業しようとしている既存のコードベースを持っているならば、それはあなたが通り抜けるためにたくさんの小さなたるみを持つことになるでしょう。
これは設計上の問題ではなく、実装上の問題だと思います。すなわち私が言うの "デザイン"、写真編集パッケージはどんな言葉の大きさでも同じになると思います。私たちは32ビットと64ビットの両方のバージョンにコンパイルするコードを書きます、そしてデザインは確かに両者の間で違いはありません - それは同じコードベースです。
64ビットの基本的な「大したこと」は、32ビットよりはるかに大きいメモリアドレス空間にアクセスできることです。これはつまり、4Gb以上のメモリを実際にコンピュータに搭載して、実際に変化をもたらすことができるということです。
私は他の答えが私よりも詳細と利益に入るだろうと確信しています。
その違いをプログラムで検出するという意味では、ポインタのサイズ（例えばsizeof（void *））をチェックするだけです。 4の答えはその32ビットを意味し、8はあなたが64ビット環境で走っていることを意味します。
32ビットプロセスは4 GBの仮想アドレス空間を持ちます。アプリによってはこれが少なすぎるかもしれません。 64ビットアプリには、実質的に無制限のアドレススペースがあります（もちろんそれは限られていますが、おそらくこの制限には当たらないでしょう）。
OSXには他にも利点があります。 次の記事 を参照してください。カーネルを64ビットアドレス空間で実行するのか（アプリが64または32のどちらを実行する場合でも）、または64で実行するのかビットアドレス空間（カーネルは32ビットのままです）は、はるかに優れたパフォーマンスをもたらします。要約すると、どちらかが64ビット（カーネルまたはアプリ、あるいはその両方）の場合、カーネルを切り替えてスペースを使用するたびにTLB（ "translation lookaside buffer"）をフラッシュする必要はありません（高速になります）。 up RAM access）.
"long long int"変数（uint64_tのような64ビット変数）を扱うときにもパフォーマンスが向上します。 32ビットCPUは2つの64ビット値を加算/除算/減算/乗算することができますが、単一のハードウェア操作では実行できません。代わりに、この操作を2つ（またはそれ以上）の32ビット操作に分割する必要があります。そのため、64ビットの数字でうまく機能するアプリは、ハードウェアで直接64ビットの数学を実行できるという点でスピードが向上します。
大事なことを言い忘れましたが、x86-64アーキテクチャは古典的なx86アーキテクチャよりも多くのレジスタを提供します。レジスタの操作はRAMおよびCPUのレジスタ数が多いほど、レジスタ値をRAMにスワップしてレジスタに戻す必要が少なくなります。
あなたのCPUが64ビットモードで動作できるかどうかを調べるために、さまざまなsysctl変数を見ることができます。例えば。端末を開いてタイプする
sysctl machdep.cpu.extfeatures
EM64Tと表示されている場合、お使いのCPUはx86-64規格に従って64ビットアドレス空間をサポートしています。あなたも探すことができます
sysctl hw.optional.x86_64
1（true/enabled）と表示されている場合、CPUはx86-64 Bitモードをサポートしています。0（false/disabled）と表示されている場合、サポートしていません。設定がまったく見つからない場合は、falseに設定してください。
注意：ネイティブCアプリケーション内からsysctl変数を取得することもできます。コマンドラインツールを使用する必要はありません。見る
man 3 sysctl
アドレス空間は（実）メモリ以上に使用できることに注意してください。より強力で効率的なブロックレベルのVMレベルのキャッシングが開始されるため、大きなファイルをメモリマップすることもできます。これにより、64のメモリブロックに大きなメモリブロックを割り当てる方が安全です。ヒープマネージャは、大きなブロックを割り当てることができないようなアドレス空間の断片化に遭遇する可能性が低いので、少々少々。
このスレッドで述べられていることのいくつかは（＃レジスタの倍増のように）x86-> x86_64にのみ当てはまり、一般に64ビットには当てはまりません。 x86_64の下でSSE2、686のオペコード、そしてPICを実行するための安価な方法が保証されているという事実のように。これらの機能は、厳密には64ビット版ではありませんが、レガシーの削減とx86の既知の制限事項の修正に関するものです。
さらに、スピードアップの原因としてレジスタが2倍になることを指摘する人もいますが、トリックを行うのはデフォルトのSSE2の使用である可能性が高いです（memcpyや同様の機能の高速化）。 x86で同じセットを有効にした場合、違いはかなり小さくなります。 （*）（***）
また、ポインタのサイズが大きいだけで平均データ構造が大きくなるため、初期ペナルティが生じることが多いことにも留意してください。これにはキャッシュ効果もありますが、平均的なmemcpy（）（あるいはメモリコピーと同等のものがあなたの言語にあるものは何でも）にはもっと時間がかかるという事実でより顕著に注目に値します。これはほんの数パーセントの大きさにすぎませんが、上記のスピードアップもその大きさです。
通常、アライメントのオーバーヘッドは64ビットアーキテクチャでも大きくなり（以前は32ビットのみのレコードが32ビットと64ビットの値が混在することがよくあります）、構造がさらに膨大になります。
全体的に見て、私の簡単なテストでは、ドライバとランタイムライブラリが完全に適応していれば、それらはおおよそ互いに相殺されることを示しています。ただし、一部のアプリは突然（AESに依存する場合など）または遅くなることがあります（重要なデータ構造は常に移動/スキャン/移動され、多くのポインタが含まれます）。テストはWindows上で行われたため、PICの最適化はベンチマークされませんでした。
ほとんどのJIT-VM言語（Java、.NET）は平均的に（内部的に）かなり多くのポインタを使用します。 C++おそらくそれらのメモリ使用量は平均的なプログラムよりも増加するでしょう、しかし私はそれを遅くする効果と直接同じと見なすことを敢えてしません（これらは本当に複雑でファンキーな獣でありしばしば測定せずに予測するのが難しいので）
Windows 64ビットでは、単純な演算を高速化し、複雑な（sin、cosなど）演算を低速化するように思われる浮動小数点にSSE2を使用することがデフォルトです。
（*）少し知られている事実は、SSEレジスタの数も64ビットモードでは2倍になることです。
（**）Dobbs博士は数年前にそれについていい記事を書きました。
ほとんどの人がここで言及している明白な記憶スペースの問題に加えて、私はそれがKnuth（他の人の間で）が最近話している「ブロードワードコンピューティング」の概念を見る価値があると思います。ビット操作によって得られる効率はたくさんあり、64ビットWordでのビット単位の操作は32ビットWordよりもはるかに効率的です。要するに、メモリを使わずにレジスタでより多くの演算を実行でき、パフォーマンスの観点からすると、これは非常に大きな勝利です。
私が話しているクールなトリックのいくつかの例については、Volume 4、pre-Fascicle 1Aを見てください。
より多くのメモリをアドレス指定する能力は別として、x86_64はより多くのレジスタを持ち、コンパイラがより効率的なコードを生成できるようにします。パフォーマンスの向上は、通常はかなり小さいでしょう。
X86_64アーキテクチャは、x86と下位互換性があります。変更されていない32ビットオペレーティングシステムを実行することは可能です。 64ビットOSから未修正の32ビットソフトウェアを実行することも可能です。ただし、それには通常の32ビットライブラリがすべて必要になります。それらは別々にインストールする必要があるかもしれません。
このスレッドはもう長すぎますが...
ほとんどの回答では、64ビットのアドレス空間が大きいため、より多くのメモリをアドレス指定できるという事実に焦点が当てられています。すべてのアプリケーションの約99％では、これはまったく無関係です。大なんか。
64ビットが有効な本当の理由は、レジスタが大きいということではありませんが、その数は2倍になります。つまり、コンパイラは、値をメモリに書き出して、後でいくつかの命令でロードする代わりに、より多くの値をレジスタに保持できます。最適化コンパイラがループを展開している場合は、ループを約2倍展開することができます。これは、パフォーマンスの向上に非常に役立ちます。
また、64ビット用のサブルーチン呼び出し元/呼び出し先規則は、呼び出し元がそれらをスタックにプッシュして呼び出し先がそれらをポップする代わりに、渡されたパラメーターの大部分をレジスターに保持するように定義されています。
そのため、「典型的な」C/C++アプリケーションでは、64ビット用に再コンパイルするだけで、パフォーマンスが約10％または15％向上します。 （アプリの一部が計算量に制限されていたと仮定します。もちろん、これは保証されていません。すべてのコンピュータが同じ速度で待機します。マイレージが変わる場合があります。）
Microsoft.comからの引用：
次の表では、64ビットバージョンのWindowsと64ビットIntelプロセッサを搭載しているコンピュータの最大リソースの増加を、既存の32ビットリソースの最大値と比較しています。
32ビットマシンでは、アドレス指定できるメモリは4,294,967,295バイトしかありません。 64ビットマシンでは、1.84467441×10 ^ 19バイトのメモリがあります。
64ビットプロセッサは、32ビット環境での作業の2倍の速さで特定のタスク（大きな数字の階乗など）を計算します（与えられた例は、32ビットと64ビットのWindows電卓の比較から派生しています。 ）これは、64ビット最適化アプリケーションの理論的な可能性についての一般的な感覚を与えます。
64ビットアーキテクチャでは、デジタルビデオ、科学計算、大規模データベースなどのアプリケーションで大規模データセットの処理が容易になることは間違いありませんが、64ビットアーキテクチャと32ビット互換モードのどちらが同等価格より速いかについてはかなりの議論があります。他のタスク用の32ビットシステムx86-64アーキテクチャー（AMD64）では、32ビットオペレーティングシステムとアプリケーションの大部分は、64ビットハードウェア上でスムーズに実行できます。
Sunは64ビットプラットフォーム用の「サーバー」JITコンパイラ（C2）しか実装していないため、Sunの64ビットJava仮想マシンは32ビット仮想マシンより起動が遅い[9]。 「クライアント」JITコンパイラ（C1）は、効率の悪いコードを生成しますがコンパイル速度がはるかに速いため、64ビットプラットフォームでは使用できません。
32ビットプロセッサと64ビットプロセッサを比較する際に考慮する必要があるのは速度だけではありません。マルチタスク、ストレステスト、およびクラスタリング（高性能コンピューティング用）、HPCなどのアプリケーションは、正しい展開を考えれば、64ビットアーキテクチャに適しています。このため、IBM、HP、Microsoftなどの大規模組織では64ビットクラスタが広く展開されています。
ここで既に述べた利点とは別に、セキュリティに関してもう少し注意が必要です。
- x86_64 CPUでは、ページテーブルに実行不可ビットがあります。すなわちこれにより、バッファオーバーランによる機密性の悪用を防ぐことができます。 32ビットx86 CPUは、PAEモードでこの機能のみをサポートします。
- アドレス空間を大きくすると、アドレス空間レイアウトのランダム化（ASLR）が向上し、バッファオーバーランの悪用が困難になります。
- ｘ８６＿６４ ＣＰＵは、位置独立コード、すなわち命令ポインタレジスタ（ＲＩＰ）に対するデータアクセスを特徴とする。
頭に浮かぶもう一つの利点は、Linuxカーネルでvmalloc()で割り当てられる仮想連続メモリの量が64ビットモードでより大きくなることができるということです。
KristofとPoshiは32ビット版と64ビット版のOSの主な技術的違いを述べています。ユーザーエクスペリエンスは通常理論とは大きく異なります。これまでの64ビット版のWindows（XPおよびVista）には、ドライバサポートに大きなギャップがあります。私は多くのプリンタ、スキャナ、そして他の外付けデバイスが32ビットバージョンではうまく動く64ビットバージョンではうまく動かないようにしました。これらは64ビットドライバを持っていたデバイスであり、それでも動作しません。現時点では、Windows 7がこれをどのように処理するのかについて、現在アクセスしているユーザーだけでなく、実際のエンドユーザーからも聞き取れるまで、Microsoftからの64ビットのコンシューマベースから離れていくことをお勧めします。それを少なくとも6ヶ月与えて、人々が経験していることを確かめてください。私の64ビット版のVistaは私が前にeonsを使用するのを止めてXP 32ビットに戻ったので、個人的に私はWindows 7の32ビット風味をインストールするつもりです。
一部のゲームプレイプログラムは、 ビットボード 表現を使用します。たとえばチェス、チェッカー、オセロは8 x 8のボード、つまり64平方のボードを持っているので、Wordを1つのマシンに64ビット以上配置するとパフォーマンスが大幅に向上します。
私は64ビットビルドが32ビットバージョンのほぼ2倍の速さであるチェスプログラムについて読んだことを覚えています。
32ビットおよび64ビットという用語は、コンピュータプロセッサ（CPUとも呼ばれる）が情報を処理する方法を指します。 64ビット版のWindowsは、32ビットシステムよりも効率的に大量のランダムアクセスメモリ（RAM）を処理します。
速度は私の意見では異なるかもしれません
最も実用的な目的のためには、おそらく違いに気付かないでしょう。
64ビットオペレーティングシステムをインストールするには、64ビットCPU（ここ数年のほとんどのCPU）が必要です。
64ビットオペレーティングシステムにはいくつかの利点があります。
- 4GB以上のRAMを実行できます（32ビットOSでアドレス指定できる最大数は2 ^ 32 = 4GBです）。
- 大規模なデータセット（Excelなど）や特定の計算集約的なタスク（Photoshopや大きなファイルなど）を扱う場合に便利です。
- 64ビットプログラムは64ビットOS上でしか実行できませんが、32ビットプログラムは両方で実行できます（多くのプログラムが両方として提供されているので、64ビットのみが多すぎるということはない）プログラム）。
ほとんどのシナリオでは、64ビットプログラムはもう少し多くのメモリを使用しますが、パーソナルコンピュータの場合、これは通常気付かれません。
Microsoft Windowsに関するもう1つの注意点は、32ビットオペレーティングシステムを対象とし、64ビットコンパイル用に最適化されていないWin32 APIが長年にわたって存在していることです。私が自分のアプリケーション用のDLLを書くとき、私は通常Win32でコンパイルしますが、これは64ビット版ではありません。 Vistaより前のバージョンでは、新しいマシンに4 GBのRAMが搭載された64ビット版のWindowsが成功したとは思われていませんが、32ビットWindows XP Proを使用しています。 XP64またはVistaと比較して、既知の安定したO/Sです。
16ビットから32ビットへの移行があった時期を振り返って、一部の人々にとってなぜ移行が大きな問題になるのかについて、もう少し詳しく説明したいと思うかもしれません。会社がデスクトップ上で実行できるミッションクリティカルなアプリケーション。小さなアカウンティングパッケージは、64ビットオペレーティングシステムでは動作しない可能性があるため、レガシーマシンを仮想または実在させる必要があります。
アドレスのサイズを変更すると、大きな影響や波及効果が生じる可能性があります。