問題タブ [sse4]

SSE4を使用して、1つの命令で複数の数値を比較することは可能ですか？

Intel Referenceは、PCMPGTQについて次のように述べています

PCMPGTQ —パックされたデータを比較して

デスティネーションオペランド（第1オペランド）とソースオペランド（第2オペランド）のパックされたクアドワードに対してSIMD比較を実行します。最初の（宛先）オペランドのデータ要素が2番目の（ソース）オペランドの対応する要素よりも大きい場合、宛先の対応するデータ要素はすべて1に設定されます。それ以外の場合は、0に設定されます。

ベクトル内でどの整数が大きいか、どれが小さいかを判断できるようにしたいので、これは実際には私が望んでいることではありません。

たとえば、比較する必要がある場合

[32, 13, 44, 99]あるベクトルと別のベクトルを入れて、 [45, 78, 12, 66]1つの命令でSSE4を使用してそれらを比較し、[0, 0, 1, 1]結果として（0-少ない、1-大きい）にすることを計画していました。

しかし、これはPCMPGTQが行うことではないようです。この比較を高速化するために、このレベルで並列処理を使用する方法に関する提案はありますか？

私は自分のコンピューター（Fedora 17 32ビット）で次のプログラムを実行しようとしました。popcntシステムが高速人口カウントの命令をサポートできるようにするにはどうすればよいですか？

プログラムをコンパイルして実行しましたが、次の例外が発生しました。

以下は私のプロセッサの情報です：

この命令を使用して、C++ の関数にpcmpestri似た関数を作成するにはどうすればよいですか? strposg++ コンパイラを使用できます。

pcmpestriSSE4で見つかった新しい命令です

なぜ世界は_mm_crc32_u64(...)このように定義されたのですか？

「crc32」命令は常に32 ビット CRC を累積し、64 ビット CRC を累積することはありません (結局のところ、CRC64 ではなく CRC32 です)。マシン命令 CRC32に 64 ビットのデスティネーション オペランドがある場合、上位 32 ビットは無視され、完了時に 0 で満たされるため、64 ビットのデスティネーションを使用する必要はありません。Intel が (均一性のために) 命令で 64 ビットのデスティネーション オペランドを許可した理由は理解していますが、データをすばやく処理したい場合は、できるだけ大きなソース オペランドが必要です (つまり、それだけ多くのデータが残っている場合は 64 ビット、テール エンドでは小さい) であり、常に 32 ビットのデスティネーション オペランドです。ただし、組み込み関数では、64 ビットのソースと 32 ビットの宛先は許可されていません。他の組み込み関数に注意してください。

「crc」の型は8ビット型ではなく、戻り値の型でもなく、32ビットです。なぜないのですか

? Intel 命令はこれをサポートしており、これが最も理にかなっている組み込み関数です。

後者の組み込みを実装するための移植可能なコード (Visual Studio および GCC) を持っている人はいますか? ありがとう。 私の推測は次のようなものです：

GCCの場合、および

VisualStudio用。残念ながら、私は制約がどのように機能するかをほとんど理解しておらず、アセンブリ レベル プログラミングの構文とセマンティクスに関する経験もほとんどありません。

小さな編集:私が定義したマクロに注意してください:

最後のマクロ ステートメントがどのように異なるかに注意してください。統一性の欠如は確かに、組み込みが適切に定義されていないことを示しています。最後のマクロに明示的なキャストを入れる必要は(uint64)ありませんが、それは暗黙的であり、実際に行われます。生成されたコードを逆アセンブルすると、キャスト 32->64 と 64->32 の両方のコードが表示されますが、どちらも不要です。

別の言い方をすれば、それは_mm_crc32_u64ではなく _mm_crc64_u64、後者であるかのように実装されています。

上記の正しい定義を得ることができればCRC32、マクロを次のように変更したいと思います

AVX(2) ではなく SSE から SSE4.1 を持っていると仮定すると、次のようなパックされたメモリ レイアウト (すべて 32 ビット整数) をロードする最速の方法は次のとおりです。

4 つのベクトルにa, b, c, d?

これが関連しているかどうかはわかりませんが、実際のアプリケーションでは 16 個のベクトルがありa0、a1メモリ内で 16*4 バイト離れています。

SSE42 および STTNI 命令を試しているところ、奇妙な結果が得られました。PcmpEstrM (明示的な長さの文字列で動作) は、PcmpIstrM (暗黙的な長さの文字列)よりも 2 倍遅くなります。

• 私のi7 3610QM では、差は2366.2 ms 対 1202.3 ms - 97%です。
• i5 では 3470の差はそれほど大きくありませんが、それでも有意です = 3206.2 ms 対 2623.2 ms - 22%。

両方とも「Ivy Bridge」です - 「違い」が非常に異なるのは奇妙です (少なくとも、仕様に技術的な違いは見られません - http://www.cpu-world.com/Compare_CPUs/Intel_AW8063801013511,Intel_CM8063701093302 / )。

Intel 64 and IA-32 Architectures Optimization Reference Manual では、PcmpEstrM と PcmpIstrM の両方で同じスループット = 11 とレイテンシ = 3 について言及しています。したがって、両方に同様のパフォーマンスを期待しています。

Q:私が実際に設計した/予期した違いですか、それともこれらの命令を間違った方法で使用していますか?

以下は、ダミーのテスト シナリオ (VS 2012) です。ロジックは非常に単純です。16MB のテキストをスキャンして、一致する文字を見つけます。干し草の山と針の糸のいずれにもゼロのターミネータが含まれていないため、E と I の両方が同様のパフォーマンスを発揮することを期待しています。

PS: この質問をインテルの開発フォーラムに投稿しようとしましたが、彼らはそれをスパムとして識別しました :(

ページ境界を越えてデータにアクセスする movdqu 命令で xmm レジスタをロードする簡単なテスト プログラムがあります (OS = Linux)。

次のページがマップされている場合、これは問題なく機能します。マップされていない場合は、SIGSEGV を取得しますが、これはおそらく予想どおりです。

ただし、これにより、アライメントされていないロードの有用性がかなり低下します。さらに、アラインされていないメモリ参照を可能にする SSE4.2 命令 (pcmpitri など) も、この動作を示すようです。

それはすべて問題ありません - pcmpistri を使用した strcmp の実装が多く、この問題にまったく対処していないように見えることを除いて - そして、これらの実装が失敗する原因となる簡単なテストケースを考案することができました。一方、一度にバイト単位の単純な strcmp 実装は、同じデータ レイアウトで問題なく動作します。

もう 1 つ注意してください。64 ビット Linux 用の GNU C ライブラリの実装には、より安全な方法で pcmpistri 命令を使用するように見える __strcmp_sse42 バリアントがあるようです。この strcmp の実装はかなり複雑ですが、ページ境界の問題を慎重に回避しようとしているようです。それが上で説明した問題によるものなのか、それともデータを調整してパフォーマンスを向上させようとしたことの単なる副作用なのかはわかりません。

とにかく、私が持っている質問は、主に、この問題についてどこで詳しく知ることができますか? 「movdqu クロス ページ境界」と入力して、考えられるすべてのバリアントを Google に入力しましたが、特に役立つものは見つかりませんでした。誰かが私にこれに関する詳細情報を教えてくれるなら、それは大歓迎です。