問題タブ [sse2]

私は少しのコードに取り組んでおり、可能な限り最適化しようとしています。基本的には、特定の制限時間内で実行します。

以下は呼び出しを行います...

...そして、以下が実行されます。

これを最適化するために Intel の TBB を使用しています。しかし、SIMD や SSE2 など、その性質に沿ったものについても読んでいます。私の質問は、変数 (i、j、k) をレジスタに格納して、CPU がより高速にアクセスできるようにするにはどうすればよいかということです。答えはSSE2またはそのバリエーションの実装に関係していると思いますが、その方法がわかりません。何か案は？

編集：これはLinuxボックスで実行されますが、Intelのコンパイラを使用していると思います。それが役立つ場合は、何かを行う前に次のコマンドを実行して、コンパイラーが機能することを確認する必要があります... source /opt/intel/Compiler/11.1/064/bin/intel64/iccvars_intel64.csh; source /opt/intel/tbb/2.2/bin/intel64/tbbvars.csh ... そしてコンパイルするには: icc -ltbb test.cxx -o test

SSE2 を実装する簡単な方法がない場合、コードをさらに最適化する方法について何かアドバイスはありますか?

ありがとう、フリスト

異なるタイプの論理 SSE 組み込み関数に違いはありますか? たとえば、OR 演算を使用する場合、3 つの組み込み関数_mm_or_psが_mm_or_pdあり_mm_or_si128ます。私の質問:

1. 1つまたは別の組み込みを使用することに違いはありますか(適切な型キャストを使用)。特定の状況で実行時間が長くなるなどの隠れたコストはありませんか?

2. porこれらの組み込み関数は、3 つの異なる x86 命令 ( 、orps、 ) にマップされますorpd。Intelが同じことを行ういくつかの命令のために貴重なオペコードスペースを浪費している理由を知っている人はいますか?

簡単に言えば、python、より具体的には numpy から共有ライブラリを呼び出そうとしています。共有ライブラリは、sse2 命令を使用して C で実装されています。最適化を有効にすると、つまり -O2 または -O1 でライブラリをビルドすると、ctypes を介して共有ライブラリを呼び出すときに奇妙なセグメンテーション違反に直面します。最適化 (-O0) を無効にすると、ライブラリを C プログラムに直接 (最適化されているかどうかに関係なく) リンクする場合と同様に、すべてが期待どおりに機能します。私のシステムで描写された動作を示す切り取りが見つかりました。最適化を有効にすると、gdb は emmintrin.h:113 の __builtin_ia32_loadupd (__P) でセグメンテーション違反を報告します。__P の値は、最適化されていると報告されています。

test.c:

コンパイラ フラグ: gcc -o libtest.so -shared -std=c99 -msse2 -fPIC -O2 -g -lm test.c

test.py:

C から test を呼び出すと、期待どおりに動作します。

call_from_c.c:

コンパイルして呼び出します:
gcc -std=c99 -otestc -msse2 -L. -ltest call_from_c.c
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:.
./testc
... 動作します。

私のシステム:

• Ubuntu Linux i686 2.6.31-22-ジェネリック
• コンパイラ: gcc (Ubuntu 4.4.1-4ubuntu9)
• Python: Python 2.6.4 (r264:75706、2009 年 12 月 7 日、18:45:15) [GCC 4.4.1]
• でこぼこ: 1.4.0

y が整列され、x の整列は問題にならないという規定 (python コードを参照) を取りました (ただし、x を明示的に整列しても問題は解決しません)。

また、b と f をロードするときに _mm_load_pd の代わりに _mm_loadu_pd を使用することにも注意してください。C のみのバージョンでは、_mm_load_pd が機能します (予想どおり)。ただし、_mm_load_pd を使用して ctypes を介して関数を呼び出すと、(最適化とは関係なく) 常にセグメンテーション違反が発生します。

この問題を解決するために数日間試みましたが、成功しませんでした...そして、モニターを打ち負かして死ぬ寸前です。任意の入力を歓迎します。ダニエル

私は今日、NVidiaのPhys-Xライブラリがx87FPとSSE2を使用していることを発見した研究者について読んでいました。明らかに、これは速度が精度よりも優先される並列データセットには最適ではありません。ただし、記事の著者は次のように引用しています。

Intelは2000年後半にP4の導入によりx87の使用を推奨し始めました。x86-64はSSE2サポートで定義されているため、AMDは2003年のK8以降x87を非推奨にしました。VIAのC7は2005年からSSE2をサポートしています。64ビットバージョンのWindowsでは、x87はユーザーモードでは非推奨であり、カーネルモードでは完全に禁止されています。業界のほぼすべての人が2005年以来x87よりもSSEを推奨しており、ソフトウェアを組み込みPentiumま​​たは486で実行する必要がない限り、x87を使用する理由はありません。

私はこれについて疑問に思いました。x87は内部で80ビットの拡張doubleを使用して値を計算しますが、SSE2は使用しません。これは誰にとっても重要ではありませんか？それは私には驚きのようです。平面内のポイント、ライン、ポリゴンを計算する場合、減算を行うと値が驚くほど間違っている可能性があり、精度が不足しているために領域が崩壊し、ラインが相互にエイリアスする可能性があります。80ビット値と64ビット値を使用すると役立つと思います。

これは間違っていますか？そうでない場合、x87が段階的に廃止された場合、拡張ダブルFP操作を実行するために何を使用できますか？

/clrスイッチでコンパイルされたC++プログラムでSSE2拡張命令セットの最適化を利用できないのはなぜですか？

私は SSE の初心者で、組み込み関数を使用してコードのセクションを最適化しました。操作自体には満足しているのですが、結果の書き方をもっとうまくできないかと模索中です。結果は 3 つの_m128i変数になります。

私がやろうとしているのは、結果値から特定のバイトを連続しないメモリ位置に保存することです。私は現在これをやっています：

ここyで、、、cbおよびcrはバイト ( unsigned char) 配列です。私が定義できない理由から、これは私には間違っているようです。より良い方法について何か提案はありますか？

ありがとう！

入力データは16ビットデータであり、SSE2命令セットを使用して3つの値の中央値を見つける必要があります。

16ビットの入力値A、B、Cが3つある場合、次のようにすると思いました。

私が使用する予定のC関数は次のとおりです。

• max-_mm_max_epi16
• min-_mm_min_epi16
• 追加-_mm_add_epi16
• 減算-_mm_sub_epi16

誰かがより良い方法を提案できますか？

次のボトルネック関数があります。

C++コードを SSE2 組み込み関数に置き換えたい。試してみ_mm_cmpgt_epi8ましたが、符号付き比較を使用しました。符号なしの比較が必要です。

私の問題を解決するためのトリック (SSE、SSE2、SSSE3) はありますか?

注: この場合、マルチスレッドを使用したくありません。

SSE2 を使用して関数を最適化しようとしています。アセンブリ コードのデータをこの方法よりも適切に準備できるかどうか疑問に思っています。私のソース データは、pSrcData からの符号なし文字の束です。計算は float で行う必要があるため、この float の配列にコピーします。

pSrcData の 1 バイトおきに float にキャストして vVectX に格納する、より迅速な方法はありますか?

ありがとう！

Visual C++ で、メモリ アライメントを必要とする SSE2 関数を使用できるように、16 バイトでアライメントされたメモリを動的に割り当てようとしています。今、これは私がメモリを割り当てる方法です：

boost::shared_array aData(new unsigned char[GetSomeSizeToAllocate()]);

_aligned_malloc を使用してアラインされたメモリを割り当てることができることはわかっていますが、メモリを解放しようとするとブーストで問題が発生しますか? これは、ブーストがメモリを解放するために使用するコードです。

delete によって解放されたメモリは、new で割り当てる必要がありますよね? これを回避する方法についてのヒントはありますか？