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に近づけることができます。

ユーザーの観点から：

• 通常、64ビットOSの64ビットアプリケーションの場合、32ビットOSのアプリケーションの32ビットバージョンと比較して、アプリケーションの速度は速くなりますが、ほとんどのユーザーにはこの高速化は見られません。通常のユーザー向けのほとんどのアプリケーションは、余分なレジスターを実際に活用していないか、キャッシュを埋める大きなポインターによって利点が相殺されています。

• メモリホグアプリケーション（フォトエディター、ビデオ処理、科学計算など）がある場合、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ビットアプリケーション）。

32ビットと64ビットが意味しないもの：

x86システムでは、32ビットと64ビットは直接ポインターのサイズを指します。それで全部です。

• C int型のサイズを指すものではありません。これは特定のコンパイラの実装によって決定され、一般的なコンパイラのほとんどはint64ビットシステムで32ビットを選択します。

• 通常の非ポインタレジスタのサイズを直接参照するわけではありません。ただし、64ビット算術レジスタを使用するには、アプリケーションとOSも64ビットポインターモードで実行する必要があります。

• 物理アドレスバスのサイズを直接参照するわけではありません。たとえば、64ビット幅のキャッシュラインと最大512GiBのメモリを備えたシステムでは、アドレスバスに33ビット（つまりlog2(512*1024**3) - log2(64) = 33）しか必要ありません。

• 物理データバスのサイズは参照しません。これは、製造コスト（CPUソケットのピンの数）とキャッシュラインサイズに関連しています。

基本的に、すべてをより大きな規模で実行できます。

1. OSごとのRAM：OSの x86で4GBのRAM制限（ほとんどの場合）
2. プロセスごとのRAM：プロセスの x86でのRAM制限（常に）。これが重要ではないと思う場合は、巨大なMSSQLデータベース集中型アプリケーションを実行してみてください。使用可能な場合は、4GBを超えて使用し、動作が大幅に向上します。
3. アドレス：アドレスは32ビットではなく64ビットであるため、より多くのメモリを使用する「より大きな」プログラムを使用できます。
4. プログラムで使用可能なハンドル：ファイルハンドル、プロセスなどをさらに作成できます。たとえば、Windows x64ではプロセスごとに2000以上のスレッドを作成できますが、x86では数百に近くなります。
5. より広いプログラムが利用可能： x64からx86とx64の両方のプログラムを実行できます。（ウィンドウの例：wow64、windows64エミュレーションのwindows32）
6. エミュレーションオプション： x64から、x86 VMとx64 VMの両方を実行できます。
7. より高速：一部の計算は64ビットCPUでより高速です
8. 複数のシステムリソースの分割：システムリソースを分割する少なくとも1つのVMを実行する場合、大量のRAMメモリが非常に重要です。
9. 使用可能な専用プログラム：いくつかの新しいプログラムはx64のみをサポートします。Exchange 2007の例。
10. 将来廃止されるx86 ?:時間が経つにつれて、ますます64ビットが使用され、ますますx86は使用されなくなります。したがって、ベンダーは64ビットのみをサポートするようになります。

64ビットアーキテクチャの2つの大きなタイプは、x64アーキテクチャとIA64アーキテクチャです。しかし、x64は断然最も人気があります。

x64は、x64コマンドだけでなくx86コマンドも実行できます。IA64はx86コマンドも実行しますが、SSE拡張は行いません。Itaniumには、x86命令を実行するための専用のハードウェアがあります。それはエミュレータですが、ハードウェアです。

@Philが述べたように、ここでどのように機能するかをより深く見ることができます。

現時点で人々が気付く最大の影響は、32ビットPCが最大4GBのメモリしかアドレスできないことです。オペレーティングシステムによって他の用途に割り当てられたメモリを削除すると、PCにはおそらく約3.25GBの使用可能なメモリしか表示されません。64ビットに移行すると、この制限はなくなります。

深刻な開発を行っている場合、これは非常に重要です。いくつかの仮想マシンを実行してみると、すぐにメモリが不足します。サーバーは追加のメモリを必要とする可能性が高いため、サーバーではデスクトップよりも64ビットの使用がはるかに多いことがわかります。ムーアの法則により、マシンのメモリはこれまで以上に増え、ある時点でデスクトップも標準として64ビットに切り替えられます。

プロセッサの違いの詳細については、ArsTechnicaのこの優れた記事を参照してください。

無料のものはありません。64ビットアプリケーションは 32ビットアプリケーションよりも多くのメモリにアクセスできますが、欠点はより多くのメモリが必要になることです。以前は4バイトが必要でしたが、現在は8バイトが必要になります。たとえば、Emacsのデフォルトの要件は、64ビットアーキテクチャ用に構築されたときのメモリが60％増加することです。この追加のフットプリントは、メモリ階層のすべてのレベルでパフォーマンスを低下させます。実行可能ファイルが大きくなるとディスクからの読み込みに時間がかかり、ワーキングセットが大きくなるとページングが増え、オブジェクトが大きくなるとプロセッサキャッシュに収まりにくくなります。16K L1キャッシュを搭載したCPUについて考えると、32ビットアプリケーションは、L2キャッシュに失敗してL2キャッシュに移動する前に、4096のポインターで動作できますが、64ビットアプリケーションは、2048ポインターだけでL2キャッシュに到達する必要があります。

x64では、これは他のレジスタなどの他のアーキテクチャの改善により緩和されますが、PowerPCでは、アプリケーションが4Gを使用できない場合、「ppc64」よりも「ppc」で高速に実行される可能性があります。Intelでも、x86でより高速に実行されるワークロードがあり、x86よりもx64で5％以上高速に実行されるワークロードはほとんどありません。

64ビットOSはより多くのRAMを使用できます。実際にはそれで終わりです。64ビットVista / 7は、RAMの重要なコンポーネントを配置する場所に、より洗練された安全機能を使用していますが、それ自体は「気付く」ものではありません。

ChrisInEdmontonから：

PAEを搭載したix86システム上の32ビットオペレーティングシステムは、最大64 GBのRAMに対応できます。x86-64上の64ビットオペレーティングシステムは、最大256 TBの仮想アドレス空間にアクセスできますが、これは後続のプロセッサで最大16 EBまで増加する可能性があります。一部のオペレーティングシステムはアドレススペースをさらに制限し、ほとんどのマザーボードには追加の制限があることに注意してください。

エッセイ全体を書かずにすべての質問に答えることができるかどうかはわかりません（常にGoogleです...）。ただし、64ビット用にアプリを別に設計する必要はありません。参照されているのは、ポインターのサイズがintと同じサイズではなくなったことに注意する必要があるということです。また、特定のタイプのデータが4バイト長であるという前提が組み込まれていて、もはや真実ではない可能性があるという潜在的な問題が山ほどあります。

これは、アプリケーション内のあらゆる種類のものをトリップする可能性があります-ファイルの保存/読み込み、データの反復処理、データのアライメント、データのビット単位操作まで。移植しようとしている既存のコードベースがある場合、または両方で作業している場合、多くの小さな手間がかかります。

これは設計上の問題ではなく、実装上の問題だと思います。つまり、写真編集パッケージは言葉の大きさに関わらず同じになるという「デザイン」だと思います。32ビットと64ビットの両方のバージョンにコンパイルするコードを作成しますが、デザインは確かに2つのバージョンの間で違いはありません。同じコードベースです。

64ビットの基本的な「大したこと」は、32ビットよりもはるかに大きなメモリアドレス空間にアクセスできることです。これは、実際に4Gb以上のメモリをコンピューターに取り込み、実際にそれを変えられることを意味します。

私は他の答えが私よりも詳細と利益になると確信しています。

違いを検出するという点では、プログラムでポインタのサイズを確認するだけです（たとえば、sizeof（void *））。4の答えは32ビットを意味し、8は64ビット環境で実行していることを意味します。

32ビットプロセスには、4 GBの仮想アドレススペースがあります。これは一部のアプリには少なすぎるかもしれません。64ビットアプリのアドレススペースは事実上無制限です（もちろん制限されていますが、この制限に達することはほとんどないでしょう）。

OSXには他にも利点があります。カーネルを64ビットアドレス空間で実行する（アプリが64または32を実行するかどうかに関係なく）か、64ビットアドレス空間で実行する（カーネルが32ビットのままである）ことでパフォーマンスが大幅に向上する理由については、次の記事を参照してください。要約すると、どちらかが64ビット（カーネルまたはアプリ、またはもちろん両方）である場合、スペースを使用して戻るようにカーネルを切り替えるたびにTLB（ "translation lookaside buffer"）をフラッシュする必要はありません（高速になります） RAMアクセス）。

また、「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ビットモードをサポートします。0（false / disabled）の場合、サポートしません。設定がまったく見つからない場合は、falseであると考えてください。

注：ネイティブCアプリ内からsysctl変数をフェッチすることもできます。コマンドラインツールを使用する必要はありません。見る

man 3 sysctl

アドレス空間は（実際の）メモリ以上に使用できることに注意してください。大きなファイルをメモリマップすることもできます。これにより、より強力で効率的なブロックレベルのVMレベルキャッシングが開始されるため、より奇妙なアクセスパターンでパフォーマンスを向上できます。大きなブロックを割り当てることができないアドレス空間の断片化が発生する可能性があります。

このスレッドで述べられていることのいくつか（＃レジスタの倍増など）は、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ビットでは、デフォルトで浮動小数点にSSE2を使用します。これにより、単純な操作が高速になり、複雑な（sin、cosなど）操作が遅くなります。

（*）あまり知られていない事実は、SSEレジスタの数も64ビットモードで2倍になることです。

（**）ドブス博士は数年前にそれについて素晴らしい記事を書いた。

ほとんどの人がここで言及している明らかなメモリ空間の問題に加えて、私は、Knuth（とりわけ）が最近話している「ブロードワードコンピューティング」の概念を見る価値があると思います。ビット操作により多くの効率が得られ、64ビットワードでのビット単位の操作は、32ビットワードでの操作よりもさらに進んでいます。要するに、メモリをヒットすることなくレジスタでより多くの操作を行うことができ、パフォーマンスの観点から、それは非常に大きな勝利です。

私が話しているクールなトリックのいくつかの例については、第4巻のpre-Fascicle 1Aをご覧ください。

より多くのメモリをアドレス指定する機能とは別に、x86_64にはより多くのレジスタがあり、コンパイラがより効率的なコードを生成できるようにします。ただし、パフォーマンスの改善は通常かなり小さいでしょう。

x86_64アーキテクチャは、x86と下位互換性があります。変更されていない32ビットオペレーティングシステムを実行することは可能です。また、変更されていない32ビットソフトウェアを64ビットOSから実行することもできます。ただし、通常の32ビットライブラリはすべて必要になります。これらは個別にインストールする必要がある場合があります。

このスレッドはすでに長すぎますが...

応答のほとんどは、より大きな64ビットアドレス空間があるため、より多くのメモリをアドレス指定できるという事実に焦点を当てています。すべてのアプリケーションの約99％にとって、これはまったく無関係です。大きなフープ。

リアル 64ビットが良い理由があるではないレジスタが大きくなっているが、それらの2倍の数があること！つまり、コンパイラーは、値をメモリーに流し込んでから後でいくつかの命令でロードし直すのではなく、より多くの値をレジスターに保持できることを意味します。最適化コンパイラがループを展開している場合、ループを約2倍展開できます。これにより、パフォーマンスが大幅に向上します。

また、64ビットのサブルーチン呼び出し元/呼び出し先の規則は、呼び出し元がスタックにプッシュして呼び出し先がポップするのではなく、渡されたパラメーターのほとんどをレジスタに保持するように定義されています。

したがって、「典型的な」C / C ++アプリケーションは、64ビット用に再コンパイルするだけで、パフォーマンスが約10％または15％向上します。（アプリの一部がコンピューティングバウンドであると仮定します。もちろん、これは保証されていません。すべてのコンピューターが同じ速度で待機します。マイレージは異なる場合があります。）

すでに述べた利点とは別に、セキュリティに関するいくつかの利点があります。

• x86_64 cpusのページテーブルにはno-executeビットがあります。つまり、これにより、バッファオーバーランによるセキュリティの悪用を防ぐことができます。32ビットx86 cpusは、PAEモードでのみこの機能をサポートします。
• アドレス空間が大きいほど、アドレス空間レイアウトのランダム化（ASLR）が改善され、バッファオーバーランの悪用が困難になります。
• x86_64 cpus機能の位置に依存しないコード、つまり命令ポインタレジスタ（RIP）に関連するデータアクセス。

頭に浮かぶもう1つの利点vmalloc()は、Linuxカーネルで割り当てられる仮想連続メモリの量が64ビットモードで大きくなる可能性があることです。

32ビットマシンでは、アドレスするメモリは4,294,967,295バイトのみです。64ビットマシンでは、1.84467441×10 ^ 19バイトのメモリがあります。

ウィキペディアはこう言っています

64ビットプロセッサは、32ビット環境での作業の2倍の速度で特定のタスク（大きな数字の階乗など）を計算します（所定の例は、32ビットと64ビットのWindows Calculatorの比較から得られます。 ）。これにより、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ビットクラスターが広く展開されています。

Microsoft.comからの引用：

次の表では、64ビットバージョンのWindowsおよび64ビットIntelプロセッサに基づくコンピューターの最大リソースの増加が、既存の32ビットリソースの最大値と比較されています。

KristofとPoshiは、32ビットOSと64ビットOSの主な技術的な違いを述べています。ユーザーエクスペリエンスは通常、理論とは大きく異なります。これまでの64ビットWindowsのコンシューマーバージョン（XPおよびVista）には、ドライバーサポートに大きな隙間があります。多くのプリンター、スキャナー、その他の外部デバイスは、32ビットバージョンで正常に動作する64ビットバージョンでは動作しません。これらは64ビットドライバーを備えたデバイスであり、それでも動作しません。この時点で、Windows 7がこれをどのように処理するかを聞くまで、Microsoftの64ビットベースのコンシューマーには近づかないことをお勧めします。少なくとも6か月は与えて、人々が経験していることを見てください。

一部のゲームプレイプログラムは、ビットボード表現を使用します。たとえば、チェス、チェッカー、オセロには8x8のボード、つまり64マスがあり、マシンワードに少なくとも64ビットがあるとパフォーマンスが大幅に向上します。

64ビットビルドが32ビットバージョンのほぼ2倍の速さのチェスプログラムについて読んだことを覚えています。

32ビットおよび64ビットという用語は、コンピュータープロセッサ（CPUとも呼ばれる）が情報を処理する方法を指します。64ビットバージョンのWindowsは、32ビットシステムよりも効果的に大量のランダムアクセスメモリ（RAM）を処理します。

私の意見では速度は異なるかもしれません

Microsoft Windowsに関するこれのもう1つのポイントは、32ビットオペレーティングシステム向けで、64ビットコンパイル用に最適化されていないWin32 APIが長年にわたって存在していたことです。アプリケーション用のDLLを作成するとき、通常は64ビットバージョンではないWin32でコンパイルします。Vista以前は、Windowsの64ビットバージョンはあまり成功していません。新しいマシンの作業場所には4 GBのRAMがありますが、32ビットWindows XP Proは安定したO / XP64またはVistaに対するS。

16ビットから32ビットへの移行があったときに、一部の人々にとって移行が大したことのない理由の詳細についても振り返ることをお勧めします。企業がデスクトップで実行するミッションクリティカルなアプリケーション（小さなアカウンティングパッケージなど）は64ビットオペレーティングシステムで実行できない場合があるため、仮想マシンまたは実在するレガシーマシンを維持する必要があります。

アドレスのサイズを変更すると、大きな影響と影響が生じる可能性があります。

最も実用的な目的では、おそらく違いに気付かないでしょう。

64ビットオペレーティングシステムをインストールするには、64ビットCPU（過去数年のほとんどのCPU）が必要です。

64ビットオペレーティングシステムにはいくつかの利点があります。

• 4GB以上のRAMを実行できます（32ビットOSで対応できる最大数は2 ^ 32 = 4GBです）
• 大きなデータセット（Excelなど）や特定の計算集約的なタスク（Photoshopや大きなファイルなど）を扱うのに役立ちます
• 64ビットOSでのみ64ビットプログラムを実行できますが、両方で32ビットプログラムを実行できます（多くのプログラムは両方とも付属しているため、64ビットのみが多すぎることはないことに注意してください）プログラム）。

ほとんどのシナリオでは、64ビットプログラムは少し多くのメモリを使用しますが、パーソナルコンピューターの場合、これは通常は気付きません。