2

現在、VS2005 C ++アプリケーションをCE5からCE6に移植していますが、深刻なパフォーマンスの問題が発生しています。これまでのところ、動的コンテンツを取得する単一のHTTPリクエストには、CE5では40ミリ秒、CE6では350ミリ秒かかります。これらの値は、私がすでにクリーンアップした多くの非効率性のために悪化し、両方のシステムのパフォーマンスが向上していましたが、現時点ではその遅延で立ち往生しています。ちなみに、両方のテストは同じマシンで行われ、WebサーバーはCEで提供されるものではなく、C++で実装されたカスタムのものです。また、問題はネットワークIOではなく、静的ファイルを提供する場合、CE6は同じマシン上でCE5よりも優れていますが、動的コンテンツ処理であることに注意してください。

プログラムのパフォーマンスが非常に悪い理由を理解しようとしているときに、私は困惑したことに気づきました。CE5では、x86用のInterlocked * APIは、コンパイラ組み込み関数も実際の関数呼び出しも使用せず、インラインアセンブリコードを使用します。このコードには、組み込みにはマルチプロセッサシステムにのみ必要なロックプレフィックスが含まれており、CE5のようなシングルコアで実行されるコードの速度が低下するというコメントがあります。CE6では、これらの関数は、ロックプレフィックスを含むコンパイラ組み込み関数を使用して実装されます。これらの関数は、たとえばBoostやSTLportによって使用されており、どちらもWebサーバー内で使用されているため、これらが原因である可能性があるのではないかと思いました。

もう1つ気付いたのは、文字列解析関数の中には非常に時間がかかるものがあることです。さらに悪いことに、同じ関数を1回目以降にもう一度呼び出す方が時間がかからないように見えるため、何らかのキャッシュが行われているように見えます。これは、TCPを介して受信され、メモリ内で解析される短い（<1kB）文字列であるため、どのキャッシュがその原因であるかは想像できません。唯一のキャッシュは命令キャッシュである可能性がありますが、プログラムはCE5バージョンより大きくなく、コードがキャッシュされていないメモリから実行されている場合、これらのキャッシュ効果は表示されません。

TLDR-質問：

  • CE6は複数のプロセッサを処理できますか？
  • ロックプレフィックスを省略すべきであることをコンパイラに伝える簡単な方法はありますか？それを達成するための私の現在のアプローチは、CE5 SDKからインラインアセンブリをコピーすることですが、それは醜いものではありません。
  • 他に何を見るべきか、何を試してみるべきかについての提案もいただければ幸いです。よろしくお願いします！

まとめInterlockedAPIはもちろん、実行可能ファイルに依存する問題はありません。同じ実行可能ファイルを実行すると、それが証明されました。ただし、プラットフォーム設定が異なる別のマシンで実行すると、違いが生じました。プラットフォームビルダーに戻り、2つのプラットフォームの違いを理解しようとしています。

4

2 に答える 2

2

  1. いいえ。SMP のサポートには WEC7 が必要です。CE6 では、OEM が他のコアを無効にしている可能性があります。

  2. 私が知っているものはありません。

  3. パフォーマンス プロファイリング ツールを使用するか、コードにタイミング コールを組み込んで、処理に時間がかかりすぎている場所を絞り込みます。

于 2013-01-15T22:29:17.127 に答える
1

私は最終的にパフォーマンス動作の理由を見つけました。それは単にページングです。CE6 にはプール マネージャー ( http://blogs.msdn.com/b/ce_base/archive/2008/01/19/paging-and-the-windows-ce-paging-pool.aspxを参照) があり、未使用のページングを処理します。マップされた DLL と EXE。マップされたバイナリの量が特定のサイズを超えると、(低い優先度で) メモリのページアウトが開始されます。ページアウトを開始するときの制限は、デフォルトでわずか 3MiB であり、現在のアプリケーションではかなり低い値です。また、キャッシュは LRU キャッシュではなく、ロードされた順序でページを破棄するだけです。

システムがこの制限を超えたため、ページングが開始されたことが判明しました。使用されているアルゴリズムにより、使用済みのものは常に破棄され、再度ページインする必要があります。静的ファイルを提供するコードは小さいため、この制限による影響はあまりありませんでした。ただし、動的ページを提供するコードははるかに大きいため、IO でシステム全体に大混乱をもたらします。これは、問題が特定のコードに起因するものではなく、コード自体ではなく、コードの読み込みに起因するものではない理由も説明しています。

IOCTL_HAL_GET_POOL_PARAMETERS を介してこれを検出しました。これにより、関連する構成パラメーター、現在の状態、ページアウト スレッドが実行された頻度と期間がわかりました (ただし、後者はページをスワップアウトするのにかかった時間です)。何を探しているかがわかったので、結果のページ フォールトもカーネル トラッカーで見つけることができるはずです。また、CF カード アダプタのアクティビティ LED が、ファイルを最初にロードするときに点灯するようになりましたが、それがキャッシュから取得される後続の要求では点灯しないことも確認できました。これにより、動的ページで常に LED が点滅していました。

簡単な解決策は、プール マネージャーの制限を増やすことです。これは、config.bib で kernel.dll に適切な値をパッチすることで簡単に実行できます。別の方法として、実行可能ファイルのサイズを小さくすると効果的ですが、それは簡単ではありません。

于 2013-01-29T22:28:44.533 に答える