問題タブ [64-bit]

Knuthは最近、64ビットシステムに反対し、4ギガのメモリに収まるプログラムの場合、ポインタが32ビットシステムの2倍の大きさであるため、「キャッシュの半分を効果的に破棄する」と述べました。

私の質問は、64ビットマシンに32ビットオペレーティングシステムをインストールすることでこの問題を回避できるかどうかです。そして、この場合の利点を示す帯域幅を大量に消費するベンチマークはありますか？

PartCover を実行して、Windows x64 で Gallio を使用していくつかのテストのカバレッジをテストしようとしています。ただし、実行しようとすると、次のエラーが発生します。

次のエラーのため、CLSID {FB20430E-CDC9-45D7-8453-272268002E08} を持つコンポーネントの COM クラス ファクトリを取得できませんでした: 80040153。

編集：PartCover 2.2.0を使用しています

私は現在、 Managed Extensionsを使用して C++ で Visual Studio 2003 で作成された 32 ビット dll を持っています。現在、C++/CLI にアップグレードせずに 64 ビット バージョンをコンパイルしようとしています。この場所のチュートリアルに従っています。次のエラーが表示されます。

致命的なエラー C1197: 'c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll' を参照できません。プログラムが既に 'c:\windows\microsoft.net\framework\v2.0.50727\mscorlib. dll'

何が .NET 2.0 バージョンの dll を参照しているのかわかりません。

アプリケーション（Visual Studio 2008で任意のCPUとしてコンパイルされている）が32ビットまたは64ビットのアプリケーションとして実行されているかどうかを確認するにはどうすればよいですか？

DB (SQL 2005) に書き込むカスタム サービスがあります。これは完全な 64 ビット環境 (DB、.NET サービス) です。サーバーの 1 つで、データ量が急増すると毎朝クラッシュします。別のサーバーでは正常に動作します。2 台のマシンの唯一の違いは、クラッシュが発生したマシンには .NET 3.5 もインストールされていることです。

他の誰かがこの種の行動を見たことがありますか?

今日のクラッシュのイベント ログ エントリは次のとおりです。

イベントの種類: エラー
イベント ソース: .NET ランタイム 2.0 エラー報告
イベント カテゴリ: なし
イベント ID: 1000
日付: 2008 年 11 月 6 日
時刻: 09:35:03
ユーザー: N/A
コンピューター: RDDARWIN02
説明:
アプリケーション servicehost.exe のエラー、バージョン 2.0.6.6、スタンプ 48eb7b7a、障害モジュール kernel32.dll、バージョン 5.2.3790.4062、スタンプ 462643a7、デバッグ? 0、障害アドレス 0x0000000000027d8d。

詳細については、ヘルプとサポート センター ( http://go.microsoft.com/fwlink /events.asp) を参照してください。
データ:
0000: 41 00 70 00 70 00 6c 00
アプリケーション 0008: 69 00 63 00 61 00 74 00 icat
0010: 69 00 6f 00 6e 00 20 00 イオン。
0018: 46 00 61 00 69 00 6c 00 失敗
0020: 75 00 72 00 65 00 20 00 ure .
0028: 20 00 73 00 65 00 72 00 .ser
0030: 76 00 69 00 63 00 65 00 バイス
0038: 68 00 6f 00 73 00 74 00 ホスト0040 :
2e 00 65 00 78 00 65.exe 00
00 32 00 2e 00 30 00 .2...0.
0050: 2e 00 36 00 2e 00 36 00 ..6...6.
0058: 20 00 34 00 38 00 65 00 .4.8.e.
0060: 62 00 37 00 62 00 37 00 b.7.b.7.
0068: 61 00 20 00 69 00 6e 00 a. .in
0070: 20 00 6b 00 65 00 72 00 .ker
0078: 6e 00 65 00 6c 00 33 00 nel3.
0080: 32 00 2e 00 64 00 6c 00 2...dl
0088: 6c 00 20 00 35 00 2e 00 l. .5...
0090: 32 00 2e 00 33 00 37 00 2...3.7.
0098: 39 00 30 00 2e 00 34 00 9.0...4.
00a0: 30 00 36 00 32 00 20 00 0.6.2. .
00a8: 34 00 36 00 32 00 36 00 4.6.2.6.
00b0: 34 00 33 00 61 00 37 00 4.3.a.7.
00b8: 20 00 66 00 44 00 65 00 .fDe
00c0: 62 00 75 00 67 00 20 00 バグ .
00c8: 30 00 20 00 61 00 74 00 0. .at
00d0: 20 00 6f 00 66 00 66 00 .off
00d8: 73 00 65 00 74 00 20 00 セット .
00e0: 30 00 30 00 30 00 30 00 0.0.0.0。
00e8: 30 00 30 00 30 00 30 00 0.0.0.0。
00f0: 30 00 30 00 30 00 32 00 0.0.0.2。
00f8: 37 00 64 00 38 00 64 00 7.d.8.d.
0100: 0d 00 0a 00 ....

XP64 を搭載した Core2 マシン (Dell T5400) があります。

32 ビット プロセスを実行している場合、memcpy のパフォーマンスは 1.2GByte/s 程度であることがわかります。ただし、64 ビット プロセスの memcpy は約 2.2GByte/s (Intel コンパイラ CRT の memcpy では 2.4GByte/s) を達成します。最初の反応は、64 ビット コードで使用できるレジスタがより広いため、これを単に説明するだけかもしれませんが、独自の memcpy のような SSE アセンブリ コード (32 ビット幅に関係なく 128 ビット幅のロード ストアを使用する必要がある) /64-bitness of the process) は、それが達成するコピー帯域幅の同様の上限を示しています。

私の質問は、この違いは実際には何によるものですか? 32 ビット プロセスは、RAM に到達するために余分な WOW64 フープをジャンプする必要がありますか? それはTLBやプリフェッチャーと関係がありますか、それとも...何ですか?

洞察をありがとう。

Intel フォーラムでも取り上げられました。

.NET アセンブリの任意のリストを取得しました。

各 DLL が (x64 または任意の CPU ではなく) x86 用にビルドされているかどうかをプログラムで確認する必要があります。これは可能ですか？

私たちは Winforms アプリケーションを開発しており、起動時間を最適化しています。

アプリは 64 ビット Vista マシンで実行されます。私たちのテストでは、直感に反するような結果が得られました。それ以外はすべて同じで、32 ビットと 64 ビットのロードを半分の時間でターゲットにしています。なぜ誰かが光を当てることができますか？

ありがとう。

[編集] ClickOnce を介してアプリをデプロイします。これは、独自のサンドボックスでアプリを開始する調査から得られたものです。したがって、常にコールド スタートになるため、ここでパフォーマンスを改善しようとしても無駄でした。

私たちの主な問題は、プロジェクトに 32 ビット dll が存在することでした。プロジェクトを x86 でターゲットにすると (x64 で実行されますが)、ロード時間が半分に短縮されました。[/編集]

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

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

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

ありがとう。

32ビットおよび64ビットのMSWindowsでのInt64とInt32の実際のパフォーマンスの違いは何ですか？

また、2つのオペレーティングシステムバリアントのそれぞれで、Int64とInt32の実際のタイミングを確認することもできます。XPまたはVistaも興味深いでしょう。

• memcpyのパフォーマンスに関するこの質問も参照してください。