.net - 64 ビット プラットフォーム用のプログラミング

Question

.Net アプリケーション (たとえば、Asp.Net アプリケーション) で作業しているときに、32 ビット プラットフォームで作業する場合と比較して、64 ビット プラットフォームで作業するときに行う方法に違いはありますか。

あなたがフレームワークに取り組んでいて、フレームワークがあなたのためにほとんどのことを処理しているので、私はほとんど想像しませんよね?

ですが、ご意見をお聞かせください。

ありがとう。

Answer 1

p/invoke を使用している場合は、DLL の 64 ビット バージョンが利用可能であることを確認する必要があります。kernel32 などの MS 提供の DLL を呼び出している場合、これらは 32 ビット プラットフォームと 64 ビット プラットフォームで同じ名前を持っているため (奇妙なことですが)、これは問題ではありません。バージョン。ただし、サード パーティの DLL を使用していて、64 ビット アプリが 32 ビット DLL にリンクしようとすると、ランタイム例外が発生します。

これは、インプロセス COM オブジェクトを使用している場合に問題が発生することも意味します。64 ビット アプリは、プロセス境界を越えて移動しているときに 32 ビットのアウトプロセス COM オブジェクトを呼び出すことができ (逆も同様)、COM がマーシャリングを処理します。

これ以外は、フレームワークがほとんどのことを処理します。ポインターのサイズについて実際に心配する必要はなく、clr 型には明示的なサイズがあります (int は常に 32 ビット、long は常に 64 ビットです)。純粋な .NET の世界では、心配する必要はほとんどありません。より注意しなければならないのは、サンドボックスの外に出始めるときです。

Answer 2

64 ビット性を考慮することが興味深い場合が 2 つあります。

1. 2^31 要素を超えるコンテナーを考慮する必要があります。標準の配列 .Length プロパティは Int32 を返すため、32 ビット VM では作成できない大きな配列を表すことができません。64 ビット VM では、代わりに LongLength を使用する必要があります (要素が 2^31 未満であることがわかっている場合を除く)。残念ながら、多くの標準コレクション クラスは、多数の要素をまったくサポートしていないようです。
2. パフォーマンスに関する懸念が少ない long 型を使用できます。64 ビット バージョンでは、long はレジスターに適合しますが、32 ビット バージョンでは、JIT コードは単一の long 操作に対して複数のマシン命令を必要とします。