45

x64アーキテクチャの明らかな利点（アドレス指定可能なRAMアドレスが高いなど）を認識しています...しかし：

  • プログラムをネイティブ64ビットモードで実行する必要がない場合はどうなりますか。とにかく移植する必要がありますか？
  • 32ビットサポートを終了するための予測可能な期限はありますか？
  • 私のアプリケーションは、ネイティブx64コードとしてより速く/より良く/より安全に実行されますか？
4

19 に答える 19

66

x86-64は少し特殊なケースです。多くのアーキテクチャ（SPARCなど）では、アプリケーションを64ビットモードでコンパイルしても、4 GBを超えるメモリを有利に使用できない限り、メリットはありません。バイナリのサイズを大きくするだけで、キャッシュの動作に影響を与える場合、実際にコードが遅くなる可能性があります。

ただし、x86-64は、64ビットのアドレス空間と64ビットの整数レジスタだけでなく、汎用レジスタの数も2倍にします。これにより、x86のようなレジスタが不足しているアーキテクチャでは、パフォーマンスが大幅に向上します。再コンパイルします。

また、コンパイラは、SSEやSSE2などの多くの拡張機能が存在することを想定できます。これにより、コードの最適化も大幅に向上します。

もう1つの利点は、x86-64がPC相対アドレス指定を追加することです。これにより、位置に依存しないコードを大幅に簡素化できます。

ただし、アプリのパフォーマンスに敏感でない場合は、これもそれほど重要ではありません。

于 2009-09-25T23:41:53.447 に答える
28

私がまだ言及していない可能性のある利点の1つは、潜在的なバグを発見する可能性があることです。64ビットに移植すると、いくつかの変更が加えられます。一部のデータ型のサイズが変更され、呼び出し規約が変更され、例外処理メカニズム（少なくともWindowsでは）が変更されます。

これらすべてが、他の方法では隠れたバグの表面化につながる可能性があります。つまり、それらを修正することができます。

コードが正しく、バグがないと仮定すると、64ビットへの移植は、理論的にはコンパイラスイッチをフリックするのと同じくらい簡単なはずです。それが失敗した場合、それはあなたが言語によって保証されていないものに依存しているためであり、したがって、それらは潜在的なエラーの原因です。

于 2009-09-26T09:57:27.190 に答える
18

64ビットの機能は次のとおりです。

  • 64ビットを使用すると、32ビットアプリよりも多くのメモリを使用できます。
  • 64ビットを使用すると、すべてのポインターが64ビットになり、コードのフットプリントが大きくなります。
  • 64ビットを使用すると、整数および浮動小数点レジスタが増え、メモリへのレジスタの流出が少なくなり、アプリの速度がいくらか向上します。
  • 64ビットを使用すると、64ビットのALU演算を高速化できます（64ビットのデータ型を使用している場合にのみ役立ちます）。
  • 追加のセキュリティは得られません（セキュリティについて言及されている別の回答ですが、そのような利点については認識していません）。
  • 64ビットオペレーティングシステムでの実行のみに制限されています。

私はいくつかのC++アプリを移植し、64ビットコードで約10％のスピードアップを見てきました（同じシステム、同じコンパイラ、唯一の変更は32ビットと64ビットのコンパイラモードでした）が、それらのアプリのほとんどはかなりの量の64ビット演算を実行します。YMMV。

32ビットサポートがすぐになくなることを心配する必要はありません。

（コメントからのメモを含めるように編集-ありがとう！）

于 2009-09-25T23:37:01.803 に答える
5

32 ビットがしばらく何らかの形で存在することは事実ですが、Windows Server 2008 R2 には 64 ビット SKU のみが付属しています。より多くのソフトウェアが 64 ビットに移行するため、WOW64 が Windows 8 という早い時期にインストール オプションとして表示されても驚かないでしょう。WOW64 は、インストール、メモリ、およびパフォーマンスのオーバーヘッドです。32 ビット Windows の 3.5GB RAM 制限と RAM 密度の増加により、この移行が促進されます。CPUよりRAMの方がいいのに…

64ビットを受け入れましょう！時間をかけて 32 ビット コードを 64 ビット互換にする必要があります。簡単で簡単です。通常のアプリケーションでは、変更はコード修正としてより正確に記述されます。ドライバーにとっての選択肢は、順応するか、ユーザーを失うかです。その時が来たら、再コンパイルすることで、あらゆるプラットフォームにデプロイする準備が整います。

IMO 現在のキャッシュ関連の問題は議論の余地があります。この領域でのシリコンの改善と、さらに 64 ビットの最適化が近日中に行われる予定です。

于 2009-09-26T19:10:21.583 に答える
3
  1. プログラムを64ビットで実行する必要がない場合、なぜそうしますか？メモリに縛られておらず、巨大なデータセットがない場合は、意味がありません。新しいミアータはそれがそれらを必要としないので、より大きなタイヤを持っていません。
  2. 32ビットのサポート（エミュレーションを介した場合でも）は、ソフトウェアが役に立たなくなったときよりずっと前に拡張されます。私たちはまだAtari2600をエミュレートしていますよね？
  3. いいえ、ほとんどの場合、64ビットモードではアプリケーションの速度が低下します。これは、プロセッサのキャッシュに収まるアプリケーションが少ないためです。少し安全かもしれませんが、優れたコーダーはその松葉杖を必要としません:)

MicrosoftがVisualStudioを64ビットに移植しない理由に関するRicoMarianiの投稿は、実際にはVisual Studioを要約しています。64ビットバージョンがないのはなぜですか？（まだ）

于 2009-09-25T23:38:07.917 に答える
2

コードがアプリケーションであるか再利用可能なライブラリであるかによって異なります。ライブラリの場合、そのライブラリのクライアントには64ビットモードで実行する正当な理由がある可能性があるため、シナリオが機能することを確認する必要があることに注意してください。これは、プラグインを介して拡張可能なアプリケーションにも当てはまる場合があります。

于 2009-09-25T23:30:28.087 に答える
2

現在、実際に必要なものがなく、64ビットモードの場合は、移植を行うべきではありません。

今は必要ないが、いつか必要になる可能性がある場合は、どれだけの労力がかかるかを見積もる必要があります（たとえば、それぞれのコンパイラ警告をすべてオンにして、64ビットコンパイルを試行します）。些細なことではないことを期待してください。そのため、発生する可能性のある問題と、それらを修正するのにかかる可能性のある時間を知ることは有用です。

依存関係からも必要になる場合があることに注意してください。プログラムがライブラリ（DLLなど）の場合、一部のホストアプリケーションが移植されるという理由だけで、プログラムを64ビットモードに移植する必要がある場合があります。

近い将来、32ビットアプリケーションは引き続きサポートされます。

于 2009-09-25T23:31:13.187 に答える
2

64 ビットに移行するビジネス上の理由がない限り、64 ビットをサポートする本当の「必要性」はありません。

ただし、他の人がすでに言及したすべての理由を除けば、ある時点で 64 ビットに移行する正当な理由がいくつかあります。

  • 64 ビット以外の PC を購入することはますます難しくなっています。32 ビット アプリは今後数年間互換モードで動作しますが、現在または将来販売される新しい PC はすべて 64 ビットになる可能性があります。ピカピカの 64 ビット オペレーティング システムを使用している場合、互換モードで「臭い古い 32 ビット アプリ」を実行したくありません。

  • 互換性モードで正しく動作しないものもあります。これは、32 ビット ハードウェア上の 32 ビット OS で実行するのと同じではありません。互換モードで実行しているときに、いくつかの問題 (たとえば、32/64 ビット レジストリ ハイブでのレジストリ アクセス、あるべきフォルダにないためにプログラムが失敗するなど) に遭遇しました。コードを互換モードで実行することにいつも不安を感じています。それは単に「本物ではない」ことであり、しばしばそれが示されます。

  • コードをきれいに書いた場合は、64 ビット exe として再コンパイルするだけで問題なく動作する可能性が高いので、試してみない理由はありません。

  • ネイティブ 64 ビット バージョンをビルドするのが早ければ早いほど、新しい機能を追加しても 64 ビットで動作し続けることが容易になります。それは、暗黒時代をさらにn年間発展させ続けてから、光の中に飛び出そうとするよりも、はるかに優れた計画です.

  • 次の就職の面接に行くときは、64 ビットの経験と 32->64 の移植経験があると言えます。

于 2009-09-26T20:13:27.887 に答える
1

x64の利点（最も重要なのはRAMサイズの増加）をすでに認識しており、興味がない場合は、実行可能ファイル（exe）を移植しないでください。通常、移植後のパフォーマンスは、主にx86よりもx64モジュールのサイズが大きくなるために低下します。すべてのポインターは2倍の長さを必要とし、これはコードサイズ（一部のジャンプ、関数呼び出し、vtables、仮想呼び出し、グローバルシンボル）を含むあらゆる場所に浸透します。などなど）。重大な劣化ではありませんが、通常は測定可能です（3〜5％の速度低下、多くの要因によって異なります）。

DLLを使用できるx64アプリで新しい「オーディエンス」を取得できるため、DLLを移植する価値があります。

于 2009-09-26T00:03:02.843 に答える
1

一部のOSまたは構成では、32ビットプログラムを実行できません。たとえば、32ビットlibcがインストールされていない最小限のLinux。また、IIRC Iは通常、カーネルから32ビットサポートをコンパイルします。

これらのOSまたは構成が潜在的なユーザーベースの一部である場合は、はい、移植する必要があります。

より高速にする必要がある場合は、それも移植する必要があります（他の人が言っているように、x86-64にはより多くのレジスタとそれを高速化するクールな命令があります）。

または、もちろん、mmap（）を実行したり、大きなファイルや大量のメモリをマップしたりする場合。次に、64ビットが役立ちます。

于 2009-10-14T14:19:28.457 に答える
1

たとえば、次のように 32 ビット コード (GNU C/++) を記述した場合、編集: フォーマット コード

struct packet {
    unsigned long name_id;
    unsigned short age;
};

ネットワーク メッセージングの場合、64 ビット システムでの再コンパイル中に移植を行う必要があります。htonl/ntohl などのために、ネットワーク ピアがまだ 32 ビット システムを使用している場合、通信が切断されます (あなたのもの); sizeof(long) もあなたの側で 32 から 64 に変更されることを知っています。

http://code.google.com/p/effocore/downloads/listで32/64 移植に関する詳細なメモを参照してください。文書名は EffoCoreRef.pdf です。

于 2009-10-14T14:06:04.173 に答える
0

dllが64ビットプロセスから呼び出される場合、dllも64ビットである必要があります。それが価値があるかどうかは関係ありません、あなたは単に選択の余地がありません。

于 2010-04-02T10:07:30.510 に答える
0

極端なセキュリティ対策やわいせつな量のRAMが必要でない限り、メリットが得られる可能性はほとんどありません。

基本的に、コードが64ビット移植に適しているかどうかは直感的にわかるでしょう。

于 2009-09-25T23:29:44.580 に答える
0

締め切りについて。私は心配しません。32ビットのようなものは、ネイティブでしばらくの間、そして他の形で予見可能な将来のために存在するでしょう。

于 2009-09-25T23:30:40.520 に答える
0

ここでこの質問に対する私の答えを参照してください。私はその投稿を締めくくり、64ビットコンピューターは32ビットコンピューターよりもはるかに多くの情報を保存および取得できると述べました。ほとんどのユーザーにとって、これは実際にはそれほど意味がありません。Webの閲覧、電子メールのチェック、ソリティアの再生などはすべて、32ビットアドレス指定の範囲内で快適に機能するからです。64ビットの利点が本当に際立つのは、コンピューターが大量のデータを処理しなければならない領域です。デジタル信号処理、ギガピクセル写真、高度な3Dゲームはすべて、64ビット環境で大量のデータ処理が大幅に向上する分野です。

あなたのコードがより速く/より良く実行されることに関しては、それは完全にあなたのコードとそれに課せられた要件次第です。

于 2009-09-25T23:30:41.473 に答える
0

パフォーマンスの問題に関しては、実際にはプログラムに依存します。プログラムがポインター集中型の場合、64 ビットに移植するとパフォーマンスが低下する可能性があります。これは、同じサイズの CPU キャッシュの場合、各 64 ビット ポインターがキャッシュ上でより多くのスペースを占有し、仮想から物理へのマッピングもより多くの TLB スペースを占有するためです。 . それ以外の場合、プログラムがポインターを多用しない場合、そのパフォーマンスは x64 の恩恵を受けます。

もちろん、移植の理由はパフォーマンスだけではありません。移植作業や時間のスケジューリングなどの他の問題も考慮する必要があります。

于 2010-02-18T16:16:49.647 に答える
0

留意すべき 1 つの問題は、利用可能なソフトウェア ライブラリです。たとえば、私の会社では、複数の OpenGL ライブラリを使用するアプリケーションを開発していますが、これを OpenSuSE OS 上で行っています。OS の古いバージョンでは、これらのライブラリの 32 ビット バージョンを x86_64 アーキテクチャにダウンロードできました。ただし、新しいバージョンにはこれがありません。64ビットモードでコンパイルするだけで簡単になりました。

于 2010-07-02T15:34:14.607 に答える
0

「ネイティブ」を実行しているため、64ビットに移植することをお勧めします（また、OpenBSDを使用します。AMD64ポートでは、32ビットエミュレーションサポートを提供していません。すべてが64ビットでなければなりません）

また、stdint.hあなたの親友です！アプリケーションを移植することで、移植可能なコーディング方法を学ぶ必要があります。これにより、128ビットプロセッサもある場合にコードが正しく機能するようになります（できれば数十年以内に）

私は 2 つまたは 3 つのものを 64 ビットに移植し、現在は両方の開発を行っています (stdint.h を使用すると非常に簡単です)。最初のプロジェクトで 64 ビットに移植すると、2 つまたは 3 つのバグが発生しましたが、それはそれ。そのほとんどは単純な再コンパイルでしたが、移植可能なコードを自動的に作成するだけなので、新しいコードを作成するときに 32 ビットと 64 ビットの違いを気にする必要はありません。(intptr_t や size_t などを使用)

于 2010-02-18T16:24:30.073 に答える
-2

64ビットのコンパイラが成熟すれば、64ビットの方がはるかに高速に実行されるでしょうが、いつになるかはわかりません

于 2011-01-28T23:33:05.567 に答える