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

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

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

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

• 特にポインターが重いアプリケーションでは、64ビットと32ビットのメモリフットプリントが少ないため、メモリ要件が簡単に倍になります。
• オブジェクトファイルも小さくなります。
• 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ビットさえもサポートされていない場合があります。
• 32ビット実行モードでは、物理メモリよりもはるかに大きなアドレス空間に依存するASLRなどの特定の手法はうまく機能しません（またはまったく機能しません）。

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

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

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

• オブジェクトコードがディスクからRAMにロードされるまでに最大30％かかります
• オブジェクトコードはメモリの最大30％の領域を占有します
• （オブジェクトコードの場合）メモリ帯域幅を実質的に20％削減しました。
• 命令キャッシュのサイズを実質的に20％削減した

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

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

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

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

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

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

​

お使いのソフトウェアは、DLLの場合は、しなければならない 32ビットと64ビットの両方のバージョンを提供します。お客様がDLLと通信するために32ビットまたは64ビットのソフトウェアを使用するかどうかはわかりません。また、DLLはアプリケーションと同じビット長を使用する必要があります。これは交渉不可能です。

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

古いのOS上で実行するソフトウェアが必要なのですがあれば、あなたは積極的かもしれませ 64ビットバージョンを提供したいです。2つのバージョンがある場合、テストは2倍になります。さまざまなOSバージョンと言語でソフトウェアを適切にテストするのは簡単なプロセスではありません。32ビットソフトウェアは64ビットプラットフォーム上で完璧に動作するため、特に小規模の開発者がソフトウェアを32ビットとしてのみリリースすることは依然として一般的です。

また、ほとんどのモバイルは32ビットです。現在、一部のハイエンドのものは64ビットになっているかもしれませんが、そのステップを踏む理由はほとんどありません。したがって、クロスプラットフォームを開発していて、Android上でもコードを実行したい場合は、32ビットのままにするのが安全なオプションです。