何が_mm256_lddqu_si256と_mm256_loadu_si256の違い

Question

私はオンラインで見つかった例に基づいて_mm256_lddqu_si256を使用していました。後で私は_mm256_loadu_si256を発見しました。インテルイントリンシクスのガイドには、キャッシュラインの境界を越えたときに、lddquのバージョンが優れていると記載されています。 loaduのメリットは何ですか？一般に、これらの機能はどのように異なっていますか？

Answer 1

_mm256_lddqu_si256を使用する理由はありません。_mm256_loadu_si256と同義です。 lddquは、歴史的な理由から、x86がより整列していないベクトルロードのサポートに発展し、AVXバージョンをサポートするCPUがそれらを同じように実行するにつれて存在します。 AVX512バージョンはありません。

Compilers do still respect the lddqu intrinsicこの命令を実行すると、同じコードを実行するが、チェックサムまたはマシンコードのバイトが異なる場合に使用することができます。

---

んのx86マイクロアーキテクチャはvmovdquは異なるvlddquいずれかを実行しません。私。 2つのオペコードは、おそらくすべてのAVX CPUの同じ内部uopにデコードします。彼らはおそらく、おそらく、非常に低電力の、または特化したマイクロアーキテクチャが効率の良いアラインされていないベクトル負荷（Nehalem以来のことです）を伴わない限り、常にそうなります。自動ベクトル化の場合、コンパイラはvlddquを使用しません。

lddquは、ペンティアム4のmovdquとは異なります。History of … one CPU instructions: Part 1. LDDQU/movdqu explainedを参照してください。

lddquは、2つの整列16B負荷（をするのかP4 と上）に許可されると、そのデータのウィンドウをとるれます。 movdquは、アーキテクチャ上、予想される16バイトからのみロードされます。 これはストア転送に影響します：整列していないストアで保存されたばかりのデータをロードする場合は、movdquを使用します。ストア転送は以前のストアに完全に含まれているロードに対してのみ機能します。しかし、そうでなければ、いつもいつもいつもlddquを使いたいと思っていました。 （これは、movdquが常に「良い方法」を使用するようにしただけでなく、プログラマーに心配する新しい指示を導入したのです。しかし、幸いなことに、彼らは設計を変更したので、心配する必要はありませんUCまたはUncacheable Speculate Write-combining（UCSW、別名WC）メモリタイプ（それらの背後にMMIOレジスタがある可能性がある）での観察可能な動作の正しさにも影響します。

---

2つのasm命令には、コード・サイズ違いはありません：

# SSE packed-single instructions are shorter than SSE2 integer/packed-double 
    4000e3:  0f 10 07    movups xmm0, [rdi] 

    4000e6:  f2 0f f0 07    lddqu xmm0, [rdi] 
    4000ea:  f3 0f 6f 07    movdqu xmm0, [rdi] 

    4000ee:  c5 fb f0 07    vlddqu xmm0, [rdi] 
    4000f2:  c5 fa 6f 07    vmovdqu xmm0, [rdi] 
    # AVX-256 is the same as AVX-128, but with one more bit set in the VEX prefix 

---

Core2のオン以降では、lddquを使用する理由はなく、movdqu対無欠点はありません。 IntelはCore2のために特別なlddquを落としたので、両方のオプションが同じように吸い込まれる。 Core2のオン

具体的には、キャッシュラインを回避する2つの整列の負荷を持つソフトウェアに分割し、SSSE3 palignrは特にpalignrは一つだけシャッフルUOPの代わりに2である第二-GENのCore2（ペンリン）で、時々movdqu対勝利ですメロム/コンロー。 （Penrynはシャッフル実行ユニットを128bに広げた）。x264の開発者のブログ記事のうち

を参照してくださいダークShikarisの2009年の日記：Cacheline splits, take two非整列ロード戦略の詳細についてバックの悪い昔インチ

Core2以降の世代はNehalemです（movdquは、ロードポートで専用のハードウェアをサポートする単一のuop命令です）。ポインタが整列しているとき（特にAVXがない場合）、ポインタが整列しているときにコンパイラに通知するのは依然として有用ですが、特に実行時にデータが実際に整列されている場合は、どこでもmovdquを使用するのはパフォーマンス上の災害ではありません。

---

インテルは、まったくlddquのAVX版を作った理由を私は知りません。すべてのモード（レガシーSSEプレフィックス、またはAVX128/AVX256）でmovdqu/vmovdquの別名としてそのオペコードを処理するだけで、VEXプレフィックスを持つ別のオペコードにデコードするのではなく、デコードする方が簡単です。

すべての現在のAVX対応CPUには、効率的なハードウェアのアラインメントのないロード/ストアのサポートがあり、可能な限り最適な状態で処理します。例えばデータが実行時に整列されると、正確にはパフォーマンスの差はゼロvmovdqaになります。 Nehalemの前のケースであるではなく、であった。 movdquとlddquは、1つのuopがアライメントされていないアドレスでフォールトする代わりにアクティブにできるロードポートに、その権利のハードウェアサポートを置くのではなく、複数のuopにデコードして、

しかし、Intel's ISA ref manual entry for lddquは256Bバージョンは64バイト（実装に依存）まで読み込むことができ言う：

ソース・オペランドがキャッシュ・ライン境界を横切る場合、この命令は（V）MOVDQUに性能を相対的に向上させることができます。 （V）LDDQUによってロードされたデータを変更して同じ場所に格納する必要がある状況では、（V）LDDQUの代わりに（V）MOVDQUまたは（V）MOVDQAを使用します。ダブルクワッドワードを16バイト境界にアライメントされているメモリ位置に移動するには、（V）MOVDQA命令を使用します。

IDKどのくらいのものが意図的に書かれているのか、それだけはAVXのエントリを更新するときに(V)をプリペンドしたものです。私はインテルの最適化マニュアルで実際にvlddquを使用することを推奨しているとは思わないが、私はチェックしなかった。

はvlddquのないAVX512のバージョンはありませんので、私はそれはIntelが代替戦略非整列ロード命令がもはや有用であることが決定していないことを考えると、オープンそのオプションを維持しても価値はありません。