32ビットC ++コードを64ビットに移植する-それだけの価値はありますか？どうして？
私はx64アーキテクチャの明らかな利点をいくつか知っています（より高いアドレス可能RAMアドレスなど）...しかし：
- プログラムをネイティブ64ビットモードで実行する必要がない場合はどうなりますか。とにかく移植する必要がありますか？
- 32ビットサポートを終了するための予測可能な期限はありますか？
- 私のアプリケーションはネイティブx64コードとしてより速く/より良く/より安全に実行されますか？
x86-64は少し特殊なケースです。多くのアーキテクチャ（SPARCなど）では、アプリケーションを64ビットモード用にコンパイルしても、4GBを超えるメモリを有利に使用できない限り、メリットはありません。バイナリのサイズを大きくするだけで、キャッシュの動作に影響を与える場合、実際にコードを遅くすることができます。
ただし、x86-64は、64ビットのアドレス空間と64ビットの整数レジスタだけでなく、doubles汎用レジスタの数を提供します。これは、x86のようなレジスタ不足のアーキテクチャでは次のようになります。再コンパイルするだけで、パフォーマンスが大幅に向上します。
また、コンパイラはSSEやSSE2などの多くの拡張機能が存在することを想定できます。これにより、コードの最適化も大幅に改善されます。
もう1つの利点は、x86-64がPC相対アドレス指定を追加することです。これにより、位置に依存しないコードを大幅に簡素化できます。
ただし、アプリのパフォーマンスに敏感でない場合は、これもそれほど重要ではありません。
私がまだ言及していない可能性のある利点の1つは、潜在的なバグを発見する可能性があることです。 64ビットに移植すると、いくつかの変更が加えられます。一部のデータ型のサイズが変更され、呼び出し規約が変更され、例外処理メカニズム（少なくともWindowsでは）が変更されます。
これらすべてが、他の方法では隠れたバグの表面化につながる可能性があります。つまり、それらを修正することができます。
コードが正しく、バグがないと仮定すると、64ビットへの移植は、理論的にはコンパイラスイッチをフリックするのと同じくらい簡単なはずです。それが失敗した場合、それはあなたが言語によって保証されていないものに依存しているためであり、したがって、それらは潜在的なエラーの原因です。
64ビットの機能は次のとおりです。
- 64ビットを使用すると、32ビットアプリよりも多くのメモリを使用できます。
- 64ビットを使用すると、すべてのポインターが64ビットになり、コードのフットプリントが大きくなります。
- 64ビットを使用すると、整数レジスタと浮動小数点レジスタが増えるため、メモリへのレジスタの流出が少なくなり、アプリの速度がいくらか向上します。
- 64ビットを使用すると、64ビットのALU演算を高速化できます（64ビットのデータ型を使用している場合にのみ役立ちます）。
- 追加のセキュリティは得られません（セキュリティについて言及されている別の回答ですが、そのような利点はありません）。
- 64ビットオペレーティングシステムでの実行のみに制限されています。
私はいくつかのC++アプリを移植し、64ビットコードで約10％のスピードアップを見てきました（同じシステム、同じコンパイラ、唯一の変更は32ビットと64ビットのコンパイラモードでした）が、それらのアプリのほとんどはかなりの量の64ビット計算を実行します。 YMMV。
32ビットサポートがすぐになくなることを心配する必要はありません。
（コメントからのメモを含むように編集されました-ありがとう！）
32ビットが何らかの形でしばらくの間存在することは事実ですが、Windows Server 2008R2には64ビットSKUのみが付属しています。より多くのソフトウェアが64ビットに移行するにつれて、早くもWindows8のインストールオプションとしてWOW64が表示されても驚かないでしょう。 WOW64は、インストール、メモリ、およびパフォーマンスのオーバーヘッドです。 3.5GB RAM 32ビットWindowsの制限とRAM密度の増加により、この移行が促進されます。もっとRAM CPUより..
64ビットを採用！時間をかけて32ビットコードを64ビット互換にします。これは非常に簡単で簡単です。通常のアプリケーションの場合、変更はコード修正としてより正確に記述されます。ドライバーの選択は次のとおりです。ユーザーを適応させるか失うか。時が来れば、再コンパイルして任意のプラットフォームにデプロイする準備が整います。
IMOの現在のキャッシュ関連の問題は議論の余地があります。この分野でのシリコンの改善と、さらに64ビットの最適化が予定されています。
- プログラムを64ビットで実行する必要がない場合、なぜそうしますか？メモリに縛られておらず、巨大なデータセットがない場合は、意味がありません。新しいミアータはそれがそれらを必要としないので、より大きなタイヤを持っていません。
- 32ビットのサポート（エミュレーションのみを介した場合でも）は、ソフトウェアが役に立たなくなったときにはるかに長くなります。私たちはまだAtari2600をエミュレートしていますよね？
- いいえ、ほとんどの場合、64ビットモードではアプリケーションの速度が低下します。これは、プロセッサのキャッシュに収まるアプリケーションが少ないためです。少し安全かもしれませんが、優れたコーダーはその松葉杖を必要としません:)
Microsoftが64ビットに移植されていない理由に関するRico Marianiの投稿は、実際にそれを要約しています Visual Studio：なぜ64がないのですか？ビットバージョン？（まだ）
コードがアプリケーションであるか、再利用可能なライブラリであるかによって異なります。ライブラリの場合、そのライブラリのクライアントには64ビットモードで実行する正当な理由がある可能性があるため、シナリオが機能することを確認する必要があることに注意してください。これは、プラグインを介して拡張可能なアプリケーションにも当てはまります。
64ビットモードの場合、現在実際に必要なものがなく、おそらくそうなることはない場合は、移植を行うべきではありません。
今は必要ないが、いつか必要になる可能性がある場合は、どれだけの労力がかかるかを見積もる必要があります（たとえば、それぞれのコンパイラ警告をすべてオンにして、64ビットコンパイルを試行します）。些細なことではないこともあるので、どのような問題が発生する可能性があり、それらを修正するのにどれくらいの時間がかかるかを知ることは有用です。
依存関係からも必要になる場合があることに注意してください。プログラムがライブラリ（DLLなど）の場合、一部のホストアプリケーションが移植されるという理由だけで、プログラムを64ビットモードに移植する必要がある場合があります。
近い将来、32ビットアプリケーションは引き続きサポートされます。
64ビットに移行するビジネス上の理由がない限り、64ビットをサポートするための実際の「必要性」はありません。
ただし、他の人がすでに言及したすべての理由を除いて、ある時点で64ビットに移行する理由はいくつかあります。
64ビット以外のPCを購入するのはますます難しくなっています。 32ビットアプリは今後数年間互換モードで実行されますが、現在または将来販売される新しいPCは64ビットになる可能性があります。光沢のある64ビットオペレーティングシステムを使用している場合、互換モードで「臭い古い32ビットアプリ」を実行したくありません。
互換性モードでは正しく実行されないものもあります。32ビットハードウェア上の32ビットOSで実行するのと同じではありません。互換モードで実行しているときに、いくつかの問題が発生しました（たとえば、32/64ビットレジストリハイブ間でのレジストリアクセス、プログラムが予期するフォルダーにないために失敗するプログラムなど）。私は常に互換モードでコードを実行することに神経質になっています-それは単に「本物ではない」ものであり、しばしば表示されます。
コードをきれいに記述している場合は、64ビットのexeとして再コンパイルするだけで問題なく動作する可能性が高いため、試してみない理由はありません。
ネイティブ64ビットバージョンを早期に構築するほど、新しい機能を追加するときに64ビットでの動作を維持しやすくなります。これは、暗黒時代にさらに「n」年間開発を続けてから、光の中に飛び出そうとするよりもはるかに優れた計画です。
次の就職の面接に行くとき、あなたは64ビットの経験と32-> 64の移植の経験を持っていると言うことができます。
X64の利点（最も重要なのはRAMサイズ）の増加）をすでに認識していて、興味がない場合は、実行可能ファイル（exe）を移植しないでください。通常、移植後にパフォーマンスが低下します。 、主にx86よりもx64モジュールのサイズが大きくなったため：すべてのポインターは2倍の長さを必要とし、これはコードサイズ（一部のジャンプ、関数呼び出し、vtable、仮想呼び出し、グローバルシンボルなど）を含むあらゆる場所に浸透します。大幅な劣化がありますが、通常は測定可能です（3〜5％の速度低下、多くの要因によって異なります）。
DLLを使用できるx64アプリで新しい「オーディエンス」を取得できるため、DLLを移植する価値があります。
一部のOSまたは構成では、32ビットプログラムを実行できません。たとえば、32ビットのない最小限のLinux libc がインストールされています。また、IIRC Iは通常、カーネルから32ビットサポートをコンパイルします。
これらのOSまたは構成が潜在的なユーザーベースの一部である場合は、はい、移植する必要があります。
より高速にする必要がある場合は、それも移植する必要があります（他の人が言っているように、x86-64にはより多くのレジスタとそれを高速化するクールな命令があります）。
または、もちろん、mmap（）を実行したり、大きなファイルや大量のメモリをマップしたりする場合。次に、64ビットが役立ちます。
たとえば、以下のように32ビットコード（GNU C/++）を記述した場合編集：フォーマットコード
struct packet {
unsigned long name_id;
unsigned short age;
};
ネットワークメッセージングの場合、htonl/ntohlなどのため、64ビットシステムでの再コンパイル中に移植を行う必要があります。ネットワークピアがまだ32ビットシステムを使用している場合（と同じコードを使用）、通信が切断されます。あなたのもの）; sizeof（long）も32から64に変更されます。
http://code.google.com/p/effocore/downloads/list 、ドキュメント名EffoCoreRef.pdfで32/64移植に関するその他の注意事項を参照してください。
「ネイティブ」を実行するために、64ビットに移植することをお勧めします（また、OpenBSDを使用しています。AMD64ポートでは、32ビットエミュレーションサポートを提供していません。すべて64ビットである必要があります）
また、stdint.h あなたの親友であります！アプリケーションを移植することにより、移植可能にコーディングする方法を学ぶ必要があります。これにより、128ビットプロセッサもある場合にコードが正しく機能するようになります（数十年以内に）
私は2つまたは3つのものを64ビットに移植し、両方のために開発しました（stdint.hを使用すると非常に簡単です）。最初のプロジェクトで64ビットに移植すると、2つまたは3つのバグが発生しましたが、それはそれ。そのほとんどは単純な再コンパイルでしたが、移植可能に自動的にコーディングするだけなので、新しいコードを作成するときに32ビットと64ビットの違いについて心配する必要はありません。 （intptr_tやsize_tなどを使用）
極端なセキュリティ対策やわいせつな量のRAMが必要でない限り、メリットが得られる可能性はほとんどありません。
基本的に、コードが64ビット移植に適しているかどうかは直感的にわかるでしょう。
締め切りについて。私は心配しません。32ビットのようなものは、ネイティブでしばらくの間、そして他の形で予見可能な将来のために存在するでしょう。
この質問に対する私の答えを参照してください ここ。 64ビットコンピューターは32ビットコンピューターよりもはるかに多くの情報を保存および取得できると言って、その投稿を締めくくりました。 Webの閲覧、電子メールのチェック、ソリティアの再生などはすべて32ビットアドレス指定の範囲内で快適に機能するため、ほとんどのユーザーにとって、これは実際にはそれほど意味がありません。 64ビットの利点が本当に際立つのは、コンピューターが大量のデータを処理しなければならない領域です。デジタル信号処理、ギガピクセル写真、高度な3Dゲームはすべて、64ビット環境で大量のデータ処理が大幅に向上する分野です。
あなたのコードがより速く/より良く実行されることに関しては、それは完全にあなたのコードとそれに課せられた要件次第です。
覚えておくべき1つの問題は、利用可能なソフトウェアライブラリです。たとえば、私の会社は複数のOpenGLライブラリを使用するアプリケーションを開発しており、OpenSuSEOSで開発しています。古いバージョンのOSでは、x86_64アーキテクチャでこれらのライブラリの32ビットバージョンをダウンロードできました。ただし、新しいバージョンにはこれがありません。 64ビットモードでのコンパイルが簡単になりました。
Dllが64ビットプロセスから呼び出される場合、dllも64ビットである必要があります。それが価値があるかどうかは関係ありません、あなたは単に選択の余地がありません。
パフォーマンスの問題に関しては、実際にはプログラムによって異なります。プログラムがポインタを集中的に使用する場合、64ビットに移植するとパフォーマンスが低下する可能性があります。同じサイズのCPUキャッシュの場合、各64ビットポインタがキャッシュ上でより多くのスペースを占有し、仮想から物理へのマッピングもより多くのTLBスペースを占有するためです。 。それ以外の場合、プログラムがポインターを多用しない場合、そのパフォーマンスはx64の恩恵を受けます。
もちろん、移植の理由はパフォーマンスだけではありません。移植作業、時間のスケジューリングなどの他の問題も考慮する必要があります。