Was ist der Unterschied zwischen _mm256_lddqu_si256 und _mm256_loadu_si256

Question

Ich hatte _mm256_lddqu_si256 basierend auf einem Beispiel verwendet, das ich online gefunden habe. Später entdeckte ich _mm256_loadu_si256. Das Intel Intrinsics-Handbuch gibt nur an, dass die lddqu-Version eine bessere Leistung erzielen kann, wenn eine Cache-Zeilengrenze überschritten wird. Was könnten die Vorteile von loadu sein? Wie unterscheiden sich diese Funktionen im Allgemeinen?

Answer 1

Es gibt keinen Grund, jemals _mm256_lddqu_si256 zu verwenden, betrachten Sie es als ein Synonym für _mm256_loadu_si256. lddqu gibt es nur aus historischen Gründen, da sich x86 zu einer besseren unausgerichteten Unterstützung von Vektorlasten entwickelt hat und CPUs, die die AVX-Version unterstützen, sie identisch ausführen. Es gibt keine AVX512-Version.

Compilers do still respect the lddqu intrinsic und geben Sie diese Anweisung aus, damit Sie sie verwenden können, wenn Sie möchten, dass Ihr Code identisch läuft, aber eine andere Prüfsumme oder Maschinencode-Bytes hat.

---

keine x86-Mikroarchitekturen laufen vlddqu anders jede von vmovdqu. I.e. Die beiden Opcodes dekodieren wahrscheinlich auf allen AVX-CPUs den gleichen internen UOP. Wahrscheinlich werden sie es immer tun, es sei denn, es kommt eine sehr schwache oder spezialisierte Mikroarchitektur ohne effiziente, nicht ausgerichtete Vektorlasten hinzu (was seit Nehalem eine Sache war). Compiler verwenden nie vlddqu beim automatischen Vektorisieren.

lddqu unterschied sich von movdqu auf Pentium 4. Siehe History of … one CPU instructions: Part 1. LDDQU/movdqu explained.

lddqu darf (und P4 macht) zwei ausgerichtete 16B Lasten und nimmt ein Fenster dieser Daten. movdqu lädt nur architektonisch von den erwarteten 16 Bytes. Dies hat Auswirkungen auf die Geschäftsweiterleitung: Wenn Sie Daten laden, die gerade mit einem nicht ausgerichteten Geschäft gespeichert wurden, verwenden Sie movdqu, da die Geschäftsweiterleitung nur für Lasten funktioniert, die vollständig in einem vorherigen Geschäft enthalten sind. Aber sonst wolltest du generell immer lddqu verwenden. (Deshalb haben sie nicht nur movdqu immer "den guten Weg" gemacht, sondern stattdessen eine neue Anweisung für Programmierer eingeführt. Aber glücklicherweise haben sie das Design geändert, so dass wir uns keine Gedanken darüber machen müssen unaligned Ladeanweisung zur Verwendung mehr.)

Es hat auch Auswirkungen auf die Korrektheit des beobachtbaren Verhaltens auf UnCacheable (UC) oder Uncacheable Specculate Write-Kombinieren (UCSW, aka WC) Speichertypen (die MMIO Register hinter ihnen haben können).

---

Es gibt keinen Code-Größenunterschied in den beiden asm Anweisungen:

---

Auf Core2 und später gibt es keinen Grund lddqu zu verwenden, aber auch keinen Nachteil gegenüber movdqu. Intel hat die speziellen lddqu Sachen für Core2 fallen gelassen, so dass beide Optionen gleichermaßen saugen.

Auf Core2 Insbesondere Cache-Zeile zu vermeiden spaltet in Software mit zwei ausgerichteten Lasten und SSSE3 palignr ist manchmal ein Sieg gegen movdqu, vor allem im 2. Generation Core 2 (Penryn), wo palignr ist nur ein Shuffle UOP statt 2 auf Merom/Conroe. (Penryn erweiterte die Shuffle-Ausführungseinheit auf 128b).

Dunkler Shikaris 2009 von Tagebuch einer x264 Entwickler Blog-Post: Cacheline splits, take two für mehr über unaligned Last Strategien zurück in den schlechten alten Tagen.

Die Generation nach Core2 ist Nehalem, wobei movdqu eine einzelne UOP-Anweisung mit dedizierter Hardwareunterstützung in den Ladeports ist. Es ist immer noch nützlich, Compilern zu sagen, wenn Zeiger ausgerichtet sind (besonders für Auto-Vektorisierung und insbesondere ohne AVX), aber es ist kein Performance-Desaster, wenn sie einfach movdqu überall verwenden, besonders wenn die Daten tatsächlich zur Laufzeit ausgerichtet sind.

---

Ich weiß nicht, warum Intel sogar eine AVX-Version von lddqu überhaupt gemacht. Ich schätze, es ist einfacher für die Decoder, diesen Opcode nur als Alias ​​für movdqu/vmovdqu in allen Modi (mit älteren SSE-Präfixen oder mit AVX128/AVX256) zu behandeln, anstatt diesen Opcode mit VEX-Präfixen zu dekodieren.

Alle aktuellen AVX-unterstützenden CPUs verfügen über eine effiziente Hardware-Unterstützung für unausgeglichene Lade-/Speicheroperationen, die sie so optimal wie möglich handhaben. z.B. Wenn die Daten zur Laufzeit ausgerichtet sind, gibt es genau null Leistungsunterschied gegenüber vmovdqa.

Dies war nicht der Fall vor Nehalem; movdqu und verwendet werden, um mehrere UPs zu dekodieren, um potenziell falsch ausgerichtete Adressen zu handhaben, statt Hardware-Unterstützung für das Recht in den Ladeports zu stellen, wo ein einzelner UOP es aktivieren kann, anstatt auf nicht ausgerichtete Adressen zu reagieren.

Jedoch sagt die Intel's ISA ref manual entry for lddqu 256b Version zu 64 Byte laden kann (implementierungsabhängig):

Diese Anweisung kann Leistung im Vergleich zu (V) MOVDQU verbessern, wenn der Quellenoperand eine Cache-Zeilengrenze überquert. In Situationen, die erfordern, dass die von (V) LDDQU geladenen Daten modifiziert und am selben Ort gespeichert werden, verwenden Sie (V) MOVDQU oder (V) MOVDQA anstelle von (V) LDDQU. Um ein doppeltes Vierfachwort zu oder von Speicherorten zu verschieben, von denen bekannt ist, dass sie an 16-Byte-Grenzen ausgerichtet sind, verwenden Sie die (V) MOVDQA-Anweisung.

IDK, wie viel davon bewusst geschrieben wurde, und wie viel davon kam gerade (V) aus vorangestellt wird, wenn der Eintrag für AVX-Update. Ich denke nicht, dass Intels Optimierungshandbuch wirklich empfiehlt, vlddqu irgendwo zu verwenden, aber ich habe es nicht überprüft.

Es gibt keine AVX512 Version von vlddqu, so denke ich, dass bedeutet, Intel, dass eine alternative-Strategie nicht ausgerichteten Ladebefehl nicht entschieden hat, ist mehr sinnvoll, und ist nicht einmal wert offen ihre Optionen zu halten.