DLL で CPU 固有の機能を使用するための標準的な手法にはどのようなものがありますか?

Question

短縮版：DLL内でCPU固有の指示を利用することが可能か、そしてどのように最善かを疑問に思っていますか？

少し長いバージョン:たとえば Microsoft から (32 ビット) DLL をダウンロードする場合、1 つのサイズですべてのプロセッサに適合するようです。

これは、最小公倍数 (つまり、OSでサポートされる最小プラットフォーム）？または、DLL内の単一のインターフェイスをエクスポートするために使用されますが、舞台裏でCPU固有のコードを利用して最適なパフォーマンスを得るために使用される手法はありますか？もしそうなら、それはどのように行われますか?

Answer 1

何も知りません 標準 しかし、そのようなものを作成する必要がある場合は、DllMain() 関数にコードを記述して CPU タイプを検出し、各関数の CPU 最適化バージョンへの関数ポインターをジャンプ テーブルに設定します。

CPU タイプが不明な場合の最小公倍数関数も必要になります。

現在の CPU 情報はレジストリで確認できます。

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor

Answer 2

DLL は WIN32 が動作するすべてのコンピュータで動作することが期待されているため、一般的には i386 命令セットに固執することになります。特定の命令セットの機能/コードを公開する公式の方法はありません。それは手作業で透過的に行う必要があります。

基本的に使用されるテクニックは次のとおりです。-MMX、ランタイムのSSEなどのCPU機能を決定する - それらが存在する場合は、それらを使用しても、フォールバックコードを準備してください

コンパイラに i386 以外の最適化をさせることはできないため、インライン アセンブラで特定の命令セットを使用してコードを記述する必要があります。これ用の高等言語ツールキットがあるかどうかはわかりません。CPU の機能を判断するのは簡単ですが、アセンブラで行う必要がある場合もあります。

Answer 3

SSE/SSE2 を最適化する簡単な方法は、 /arch MSVC の引数。フォールバックについては心配する必要はありません。非常にニッチなアプリケーションでない限り、それ以下のものをサポートする理由はありません。

http://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx

gcc/g++ には同等のフラグがあると思います。

Answer 4

Intel の ICC は、異なるアーキテクチャに対してコードを 2 回コンパイルできます。そうすれば、ケーキを持って食べることができます。(OK、ケーキが 2 つ得られます - DLL はさらに大きくなります)。そして、MSVC2005 でも、非常に特殊な場合にそれを行うことができます (例:memcpy() は SSE4 を使用できます)

異なるバージョン間で切り替える方法はたくさんあります。ロードプロセスには DLL からの関数が必要であるため、DLL がロードされます。関数名はアドレスに変換されます。1 つの解決策は、この検索を関数名だけでなくプロセッサの機能にも依存させることです。別の方法では、名前からアドレスへの関数が中間ステップでポインターのテーブルを使用するという事実を利用します。テーブル全体を切り替えることができます。あるいは、重要な関数内にブランチを設けることもできます。そのため、 foo() は、より高速な場合に foo__sse4 を呼び出します。

Answer 5

Microsoft からダウンロードする DLL は、世の中の多数のマシンすべてで動作する必要があるという単純な理由から、汎用 x86 アーキテクチャを対象としています。

Visual Studio 6.0 の時代まで (変更されたかどうかはわかりません)、Microsoft は速度ではなくサイズを重視して DLL を最適化していました。これは、DLL の全体的なサイズの削減により、コンパイラーが生成できる他の最適化よりもパフォーマンスが向上したためです。これは、マイクロ最適化による高速化は、CPU にメモリを待たせないことによる高速化と比べて明らかに低いためです。速度の真の向上は、I/O の削減または基本アルゴリズムの改善によって実現されます。

プログラムの中心で実行される少数の重要なループのみが、呼び出される回数が非常に多いため、マイクロ最適化の恩恵を受けることができます。コードの約 5 ～ 10% のみがこのカテゴリに分類される可能性があります。このような重要なループは、マイクロソフトのソフトウェア エンジニアによってアセンブラですでにある程度最適化されており、コンパイラが検出できるほどの残骸は残らないので、安心してください。（期待しすぎているのはわかっていますが、そうなってくれることを願っています）

ご覧のとおり、このコードのほとんどがめったに使用されない、または CPU サイクルのほとんどを消費する重要なコードの一部ではない場合、さまざまなアーキテクチャ向けに調整されたコードの追加バージョンを含む DLL コードの増加による欠点だけが発生します。 。