none
x64アプリケーションの処理劣化について RRS feed

  • 質問

  • がっちんと申します。

    現在VS2008 C#にてWin Formアプリを開発しています。

    これまでプラットフォームターゲットをAnyCPUとして開発していましたが、このたびWindows VISTA 64Bit

    環境でX64コンパイルしてアプリケーションを起動したところアプリケーションの処理速度が半分程度に

    著しく落ちてしまいました。(とある重い計算処理を行っているのですがその時間が2倍かかるようになりまし

    た。WinFormの振る舞い自体はさほどかわりありません)

     

    PCはノートPC(DELL D820, CPUはCore2 Duo T5600)なのですが、ベンチマークツールで各種ベンチ

    マークを測定してみたところ特にパフォーマンスは問題なかったので、考えられる要因としては次の2つ

    かなっと思っています。

     

    1. .NET Framework 64Bit版でなんらかの相性不具合等が発生している

    2. アプリから外部参照のDLLを呼び出すときになんらかの処理劣化が発生している

     

    1についてですが、.NET Framework2.0と3.5について両方テストしてみましたがパフォーマンスに

    主だった違いはなく、32ビット環境のアプリケーションに比べて両方とも遅くなりました。

     

    2についてですが、開発中のアプリではいくつかのDLLを外部参照していてそのすべては32BitのDLLです。

    (x64でコンパイルしたアプリがどうやって32BitのそれらDLLを呼び出せるのかは実は理解できていません)

     

    プロファイラなども使用してみたのですが原因はつかめませんでした。

     

    そこでお伺いしたいのですが、1や2によって上記問題が発生するということはありえるのでしょうか?

    また、何か他に考えられる要因などはありますでしょうか?

     

    どうかご教授の程よろしくお願いします。

     

     

    2008年6月23日 7:47

回答

  •  がっちん さんからの引用

    そもそもなぜx64環境で使用したかったかというと64bitによりパフォーマンスが向上すると思ったからでした。

    単純に32bitを64bitにしたからといってパフォーマンスが劇的に改善するわけではありません。

    もちろん、longの演算が速くなる、64ビットのポインタが使えるなどの恩恵を受ける可能性はありますが、パフォーマンスを気にするようなアプリでは微々たるものでしょう。

    2008年6月25日 14:06
    モデレータ

すべての返信

  • >2についてですが、開発中のアプリではいくつかのDLLを外部参照していてそのすべては32BitのDLLです。

    >(x64でコンパイルしたアプリがどうやって32BitのそれらDLLを呼び出せるのかは実は理解できていません)


    64ビットプロセスに32ビットDLLはロードできないはずです。

    DLL が COM の話なら、32ビットのときはインプロセスサーバで、64ビットのときはアウトプロセスサーバになっているとか。

     

    2008年6月23日 8:50
  • がっちんです。

    返信をありがとうございます。

     

    DLLはCOMと32ビットDLLの両方を参照で使用しているのですが、

    VS2008の参照設定でこのCOMと32ビットDLLを参照追加し、x64でコンパイルして

    使っています。これは間違っているのでしょうか。。。

     

     

    2008年6月24日 3:08
  •  がっちん さんからの引用

    DLLはCOMと32ビットDLLの両方を参照で使用しているのですが、

    VS2008の参照設定でこのCOMと32ビットDLLを参照追加し、x64でコンパイルして

    使っています。これは間違っているのでしょうか。。。

    参照を追加できるのは、COMと.NETのDLLになりそうですが、(COMじゃない方は)本当に32bitのDLLなのですか?

    32bitで動くAny CPUでビルドされた.NETのDLLじゃありませんか?

     

    32bitのCOMをx64なアプリから呼び出せば、囚人さんが書かれている情報によるとプロセス間の通信処理が走ります。

    32bitではそのプロセス間の通信処理がありませんので、処理速度は変化するでしょう。

     

     

    で、対処案としては、次のような手でしょうか?

     

    1.COMも含めて全てx64でビルドしなおす。(ソースが手元にあるとかじゃないと不可能)

    2.プラットフォームをx86としてビルドし、64bit WindowsではWOW64を頼る。(本当の意味で解決できるかは不明)

    3.パフォーマンスの問題は諦めて、正常に動くかどうかだけを見る。
    2008年6月24日 13:55
    モデレータ
  •  Azulean さんからの引用

    1.COMも含めて全てx64でビルドしなおす。(ソースが手元にあるとかじゃないと不可能)

    2.プラットフォームをx86としてビルドし、64bit WindowsではWOW64を頼る。(本当の意味で解決できるかは不明)

    3.パフォーマンスの問題は諦めて、正常に動くかどうかだけを見る。

     

    アドバイスをありがとうございます。

    詳しく確認していませんでしたが、たしかに32bitで動くAny CPUでビルドされたDLLなのかもしれません。

    ソースがなくDLLのみを組み込んで使っています。

     

    そもそもなぜx64環境で使用したかったかというと64bitによりパフォーマンスが向上すると思ったからでした。

    しかしながら、参照DLLもx64で再コンパイルする必要があるということは見落としていました。

    パフォーマンス向上への道は遠しでした。

     

    また、プロファイラにてさらに検証した結果、ArrayListもしくは変数の二次元配列を取り扱ってる部分で32bitの時

    とは違う特別なボトルネックが発生しているようでした。64bit特有の何かが起こっているのでしょうか。

     

     

    教えていただいた対処案ですが、3の正常に動くかどうかだけを確認することにとどめることにします。

    ありがとうございました。

    2008年6月25日 10:08
  •  がっちん さんからの引用

    そもそもなぜx64環境で使用したかったかというと64bitによりパフォーマンスが向上すると思ったからでした。

    単純に32bitを64bitにしたからといってパフォーマンスが劇的に改善するわけではありません。

    もちろん、longの演算が速くなる、64ビットのポインタが使えるなどの恩恵を受ける可能性はありますが、パフォーマンスを気にするようなアプリでは微々たるものでしょう。

    2008年6月25日 14:06
    モデレータ