web-dev-qa-db-ja.com

64ビットマシンで64ビットではなく32ビットソフトウェアを実行する正当な理由はありますか？

64ビットハードウェアで最新の64ビットオペレーティングシステムを実行している最新のデスクトップマシンを対象とするソフトウェアの64ビットバージョンと共に32ビットバージョンを提供する正当な理由はありますか？

64ビットソフトウェアの方が効率的で、必要に応じてメモリ使用量を増やすことができるようです。Appleは、RAMが1〜2 GBしかない場合でも、64ビットプロセッサを使用しています。 、32ビットCPUの4 GB制限をはるかに下回ります。

hardware64-bit32-bit
56
Filip Haglund

64ビット環境での32ビットソフトウェアの利点

  • 特にポインターが多いアプリケーションでは、メモリフットプリントが少ないため、64ビット対32ビットでメモリ要件を簡単に2倍にすることができます。
  • オブジェクトファイルも小さくなります。
  • 32ビット環境との互換性。
  • メモリリークは2 GB、3 GB、または4 GBにハードキャップされ、システム全体を圧迫することはありません。

64ビット環境での32ビットソフトウェアの欠点

  • プロセスあたり2 GB、3 GB、または4 GBのメモリ制限。 （単にプロセスごとに、複数の32ビットプロセスが合計で利用可能なシステムメモリを使用する可能性があります）
  • X64に応じて、追加のレジスタと命令セット拡張を使用しません。これは非常にコンパイラとCPUに固有です。
  • すべて（ほとんどのLinuxディストリビューション）または一般的ではない（ほとんどのWindowsバージョン）ライブラリの32ビットバージョンとランタイム環境が必要になる場合があります。 32ビットバージョンの共有ライブラリがアプリケーション専用にロードされ、それがフットプリントに含まれる場合。静的にリンクしている場合、違いはありません。

その他の側面

  • ドライバーは通常問題ではありません。カーネルモジュールのAPIではなく、ユーザー空間ライブラリのみが32ビットと64ビットで異なる必要があります。
  • 整数データ型の異なるデフォルト幅に注意してください。追加のテストが必要です。
  • 64ビットCPUアーキテクチャは、32ビットもまったくサポートしない場合があります。
  • [〜＃〜] aslr [〜＃〜] などの特定の手法と、物理メモリよりもはるかに大きなアドレス空間に依存する手法は、32ビット実行モードではうまく機能しない（またはまったく機能しない） 。

ここで非常に特定のCPUアーキテクチャ、オペレーティングシステム、およびライブラリインフラストラクチャを比較しない限り、詳細に進むことはできません。

80
Ext3h

32ビットソフトウェアと64ビットソフトウェアの違いは、ポインタのサイズ、そしておそらく整数レジスタのサイズです。それでおしまい。

つまり、プログラム内のすべてのポインタのサイズが2倍になります。 （少なくともILP32/LP64アーキテクチャでは）longsも2倍のサイズです。これは通常、オブジェクトコードのサイズが約30％増加することになります。この意味は …

  • オブジェクトコードは、ディスクからRAMへのロードに30％長くかかります
  • オブジェクトコードはメモリの最大30％の領域を占有します
  • （オブジェクトコードの）メモリ帯域幅を効果的に最大20％削減した
  • 命令キャッシュのサイズを約20％削減しました

これは、パフォーマンスに無視できない悪影響を及ぼします。

これを行うのは、何らかの形でこれらのパフォーマンスコストを「回収」できる場合にのみ意味があります。基本的に、これを行うには2つの方法があります。64ビット整数演算を大量に実行するか、4 GBを超えるメモリをマップする必要があります。これらのいずれかまたは両方が当てはまる場合、64ビットソフトウェアを使用することは理にかなっており、そうでない場合はそうではありません。

注：対応する32ビットまたは64ビットのバリアントがないアーキテクチャーがいくつかあります。その場合、その質問は明らかに意味がありません。最もよく知られているのは、64ビットのみで32ビットのバリアントがないIA64と、密接に関連しているものの異なるアーキテクチャであるx86/AMD64で、x86は32ビットのみ、AMD64は64です。ビットのみ。

実際、後者のステートメントは100％真実ではありません。 Linuxは最近、32ビットポインターでAMD64コードを実行できるx32 ABIを追加しました。これは、「適切な」CPUアーキテクチャではない場合でも、ネイティブであるかのようにAMD64アーキテクチャを使用する方法です32ビットバリアント。これは正確に行われました原因上記で言及したパフォーマンスオーバーヘッドが実実世界のシステムで実世界のコードを実行している実世界のユーザーに測定可能な定量化可能な問題を引き起こしていました。

7
Jörg W Mittag

ソフトウェアがレガシーシステム、ドライバー、またはライブラリと直接インターフェースする必要がある場合、OSのAFAIK（間違いなくWindowsとLinux AFAIK）は64ビットと32の混在を許可しないため、32ビットバージョンを提供する必要がある場合があります。プロセス内のビットコード。

たとえば、ソフトウェアが特殊なハードウェアにアクセスする必要がある場合、顧客が32ビットドライバーしか利用できない古いモデルを操作することは珍しくありません。

6
Michael Borgwardt

ソフトウェアがDLLの場合、[〜＃〜] [〜＃〜]は32ビットと64ビットバージョン。 32ビットと64ビットのどちらのソフトウェアを使用してDLLと通信するかはわからず、DLLはアプリケーションと同じビット長を使用する必要があります。これは交渉不可。

ソフトウェアがスタンドアロンの実行可能ファイルである場合は、それほど明確ではありません。古いOSでソフトウェアを実行する必要がない場合は、32ビットバージョンを提供する必要がない場合があります。 64ビットに固執し、64ビットOSが必要であることを指定して、作業を完了します。

ただし、古いOSでソフトウェアを実行する必要がある場合は、積極的に[〜＃〜] not [〜＃〜] 64ビット版を提供したい。 2つのバージョンがある場合は、2倍のテストが行​​われ、さまざまなOSバージョンと言語にわたってソフトウェアを適切にテストすることは、迅速なプロセスではありません。 32ビットソフトウェアは64ビットプラットフォームで完全に問題なく動作するため、ソフトウェアが32ビットとしてのみリリースされることは、特に小規模な開発者にとってはまだかなり一般的です。

また、ほとんどの携帯電話は32ビットです。おそらくいくつかのハイエンドのものは現在64ビットですが、その一歩を踏み出す説得力のある理由はほとんどありません。したがって、クロスプラットフォームを開発していて、コードをAndroidでも実行したい場合は、32ビットのままにするのが安全なオプションです。

3
Graham