問題タブ [32bit-64bit]

次のシナリオにおける通常の C++ アプリケーションの相対的なパフォーマンスを知りたいです。

1. 32 ビット アプリとして構築され、Intel 64 ビット プロセッサ (x64-64) で実行されます
2. 32 ビット アプリとして構築され、Intel 32 ビット プロセッサ (x86) で実行されます
3. 64 ビット アプリとしてビルドされます。

また、アプリケーションを 64 ビット プロセッサでより高速に実行できるように変更または開発する場合、どのような要因を考慮する必要がありますか?

P/Invoke (DllImport) 署名によって参照される特定の DLL を CPU アーキテクチャに依存させる方法はありますか?

私は、サード パーティ ベンダーのネイティブ dll (この場合はハードウェアのユーザー空間インターフェイス DLL) から多数のメソッド シグネチャをロードするアプリケーションに取り組んでいます。そのベンダーは現在、x86 バージョンと x64 バージョンの両方の DLL の提供を開始しており、私のアプリは 64 ビット プロセスとして実行することでメリットが得られると思います。この 1 つの DLL を除いて、すべてが .NET コードであるため、「任意の CPU」としてビルドできます。

ネイティブ DLL のすべてのメソッド シグネチャは 64 ビットでも同じですが、DLL の名前が異なります (Foo.dll と Foo_x64.dll)。P/Invoke シグネチャまたは app.config エントリを使用して、実行中の CPU アーキテクチャに基づいてロードする DLL を選択する方法はありますか?

異なる DLL 名ではなく、異なるフォルダーで同じ名前だった場合、他のオプションが開きますか?

注: このユーザー空間 DLL のバージョンがハードウェア用にインストールされたカーネル ドライバーと一致することが不可欠であるため、DLL はアプリにバンドルされていませんが、代わりに、ベンダーのインストーラーに依存して %道％。

IE732ビットXP/Vistaでスムーズに動作するBHOは、64bt XP/VistaのIE7では動作しません。問題はBHOアセンブリの登録にあると思います。BHOを64ビットプラットフォームで機能させるための優れたソリューションを誰かが持っているでしょうか？

ありがとう、

ダッテ

リフレクションを介してロードせずに .net アセンブリの corflags を読み取るコードを記述する必要があります。

アセンブリをロードするには比較的長い時間がかかるため、アセンブリをストリームとして開き、バイナリ ストリームを分析するものを探しています。

アセンブリ バイナリ メタデータ構造に関する情報はどこにありますか? 利用可能なコード スニペットはありますか?

ありがとうサール

簡単な背景: Vista-x64 マシンの .net 3.5 で VS2008 で C# を開発しています。

私は最近 Vista-x64 に切り替えましたが、いくつか検索した後でも、OS と .net フレームワークの間の相互作用を完全には理解していないように感じます。これに関する訂正/説明をお願いします。

以下は、開発プロセスに関する私の理解です（間違っている場合は修正してください）。

プロジェクトをセットアップするときに、プラットフォーム ターゲット (x64、x86、AnyCpu) を設定できます。私が理解しているように、AnyCpu は現在のプラットフォーム (私の場合は x64) をターゲットにします。x86 をターゲットにして実行することもできます (WoW64 のため)。

x64 を対象とする場合、プログラムは 64 ビットの .net フレームワーク 3.5 を使用し、x86 では同様に 32 ビット フレームワークを使用すると想定しています。これは正しいです？

私を混乱させるのは、x64 をターゲットにしてプラットフォーム情報を出力すると、「WIN32NT」と出力されることです。これにより、「WIN32NT」は私が思っているものではないと思いますが、これについてはあまり知ることができませんでした。これは何ですか？

ありがとう。

C# で作成した 32 ビット アプリケーションを 64 ビットに変換するにはどうすればよいですか? Visual Studio でターゲット マシンを 64 ビットに変更して再コンパイルするだけでは、もっと複雑だと思います。

私の環境：XPを使用したasp.net 3.5フレームワーク

質問があります。32ビットを使用して製品を開発しました。64 ビット マシン (Windows 2008 仮想マシン) にデプロイした場合、32 ビット バージョンの iis と比較すると非常に遅いようです。64 ビット環境でより高速な応答を得るには、アセンブリを 64 ビット マシンで再コンパイルする必要がありますか?
または、64 ビット マシンで設定を行う必要はありますか? dll が 32 ビットでコンパイルされている場合、より高速なパフォーマンスを得るために 32 ビット iis でのみ実行するのが賢明です。

32 ビット アンマネージ DLL を使用する既存の 32 ビット ASP.NET アプリケーションがあります。

これを 64 ビット OS で実行すると、自動的に LARGEADDRESSAWARE になりますか (つまり、4GB の仮想メモリ全体にアクセスできますか)?

そうでない場合、LARGEADDRESSAWAREにするために何ができますか?

グーグルはこの質問を見つけましたが、上記の質問に対する答えがありません.

編集

このブログは、ASP.NET 1.1 ワーカー プロセスが LARGEADDRESSAWARE であることを示唆していますが、ASP.NET 2.0 については沈黙しています。

boot.ini で /3Gb スイッチを使用してシステムを起動すると (Windows 2000 の Enterprise および Data Center エディション、および Windows XP と Windows Server 2003 のすべてのバージョンでのみサポートされます)、/LARGEADDRESSAWARE スイッチにリンクされたプロセスは、" 「3Gb」を参照してください。Aspnet_wp.exe はバージョン 1.1 でそのようにリンクされており、それを利用できます。

編集2

これは、32 ビットの ASP.NET アプリが LARGEADDRESSAWARE であることを示唆している別のブログですが、ASP.NET のバージョンについては言及していません。

ASP.NET フレームワークによってホストされたコンポーネントが、2 ギガを超えるメモリ スペースを利用していることがわかりました。

私は、この主題に関する信頼できる公開情報が不足していることに驚いていると言わざるを得ません。

いくつかの数値コード (Python モジュールの生成) に Fortran (95) を使い始めました。簡単な例を次に示します。

これは 32 ビットで非常にうまく機能することがわかりましたが、x86_64 としてコンパイルすると、約 5 倍遅くなります (macbook pro core2duo、snow leopard、r.research.att.com の gfortran 4.2.3)。これは、ネイティブ型ではなく 32 ビット整数型を使用していることが原因である可能性があることに最終的に気付きました。実際、整数 * 8 に置き換えると、64 ビットのパフォーマンスは 32 ビットのパフォーマンスよりも 25% だけ悪くなります。

64 ビット マシンで 32 ビット整数の使用が非常に遅いのはなぜですか? 私が気付いていない可能性のあるインデックス作成で暗黙のキャストが行われていますか?

このタイプのコードでは、64 ビットが 32 ビットよりも遅くなるというのは常にあるのでしょうか (私はこれに驚きました)。それとも、64 ビットでコンパイルされたバージョンを同じ速度またはより速く実行できる可能性はありますか?

（主な質問）（整数）変数を「ネイティブ」型として宣言する方法はありますか...つまり、32ビットでコンパイルすると32ビット、最新のfortranで64ビットでコンパイルすると64ビットです。これがなければ、コンパイル方法に応じてそれほど遅くならない移植可能なfortranコードを書くことは不可能に思えます.これは、プロジェクトでfortranを使用するのをやめなければならないことを意味すると思います. kind と selected_kind を見てきましたが、これを行うものは見つかりませんでした。

[編集: 大きなパフォーマンス ヒットは、配列をコピーして 64 ビット int から 32 ビット int にキャストする f2py ラッパーによるもので、fortran に固有のものは何もありません。]

OS X 10.5 で Perl 5.10.1 をコンパイルしました。32ビットプログラムとしてコンパイルされました。その後、OS X 10.6 にアップグレードしました。私のバージョンの Perl 5.10.1 は引き続き正常に動作しますが、JSON::XS をコンパイルしようとしたところ、次のようなエラーが発生しました。

Can't load '/Users/cowens/.cpan/build/JSON-XS-2.26-clO6XX/blib/arch/auto/JSON/XS/XS.bundle' for module JSON::XS: dlopen(/Users/cowens/.cpan/build/JSON-XS-2.26-clO6XX/blib/arch/auto/JSON/XS/XS.bundle, 2): no suitable image found. Did find: /Users/cowens/.cpan/build/JSON-XS-2.26-clO6XX/blib/arch/auto/JSON/XS/XS.bundle: mach-o, but wrong architecture at /Users/cowens/local/lib/perl5/5.10.1/darwin-thread-multi-2level/DynaLoader.pm line 204.

ざっと見てみると、/Users/cowens/.cpan/build/JSON-XS-2.26-clO6XX/blib/arch/auto/JSON/XS/XS.bundle実際に 64 ビット ライブラリであることがわかります。

/Users/cowens/.cpan/build/JSON-XS-2.26-clO6XX/blib/arch/auto/JSON/XS/XS.bundle: Mach-O 64 ビット バンドル x86_64

これが原因である可能性が高いため、モジュールを 32 ビットとしてコンパイルしてみます。CCFLAGS64ビットライブラリではなく32ビットライブラリとして強制的にコンパイルするように設定できる 環境変数（のような）があると思います。

別の方法は、Perl とすべてのモジュールを再コンパイルすることのようです (やりたいことがよくわかりません)。