avantages pour rep movs

1. Lorsqu'une instruction rep movs est émise, le CPU sait qu'un bloc entier d'une taille connue doit être transférer. Cela peut l'aider à optimiser l'opération d'une manière qu'il ne peut pas avec des instructions discrètes, par exemple:

   • éviter la requête RFO quand elle sait que toute la ligne de cache sera écrasée.
   • émission immédiate et exacte des demandes de préfetch. La préfetching du matériel Fait du bon travail pour détecter les modèles de type memcpy , mais il faut quand même quelques lectures pour entrer en action et "over-prefetch" beaucoup de lignes de cache au-delà de la fin de la région copiée. rep movsb connaît exactement la taille de la région et peut préférer exactement.

2. apparemment, il n'y a aucune garantie de commander parmi les magasins dans ³ un seul rep movs qui peut aider à simplifier le trafic de cohérence et simplement d'autres aspects du mouvement de bloc, par rapport à simple mov instructions qui doivent obéir à la commande de mémoire assez stricte ⁴ .

3. en principe, l'instruction rep movs pourrait profiter de diverses astuces architecturales qui ne sont pas exposées dans L'ISA. Par exemple, les architectures peuvent avoir des chemins de données internes plus larges que L'ISA expose ⁵ et rep movs pourrait utiliser en interne.

désavantages

1. rep movsb doit mettre en œuvre une sémantique spécifique qui peut être plus forte que les exigences logicielles sous-jacentes. En particulier, memcpy interdit les régions qui se chevauchent, et donc peut ignorer cette possibilité, mais rep movsb leur permet et doit produire le résultat attendu. Sur les implémentations en cours affecte principalement au démarrage de frais généraux, mais probablement pas au débit de gros blocs. De même, rep movsb doit supporter les copies byte-granulaires même si vous l'utilisez réellement pour copier de grands blocs qui sont un multiple d'une grande puissance de 2.

2. le logiciel peut contenir des informations sur l'alignement, la taille de la copie et l'alias éventuel qui ne peuvent pas être communiquées au matériel en utilisant rep movsb . Les compilateurs peuvent souvent déterminer l'alignement des blocs de mémoire ⁶ et peuvent donc éviter une grande partie du travail de démarrage que rep movs doit faire sur chaque invocation.

Résultats Des Essais

Voici les résultats d'essais pour de nombreuses méthodes de copie différentes de tinymembench sur mon i7-6700HQ à 2,6 GHz (dommage que j'ai le CPU identique donc nous n'obtenons pas un nouveau point de données...):

 C copy backwards                                     :   8284.8 MB/s (0.3%)
 C copy backwards (32 byte blocks)                    :   8273.9 MB/s (0.4%)
 C copy backwards (64 byte blocks)                    :   8321.9 MB/s (0.8%)
 C copy                                               :   8863.1 MB/s (0.3%)
 C copy prefetched (32 bytes step)                    :   8900.8 MB/s (0.3%)
 C copy prefetched (64 bytes step)                    :   8817.5 MB/s (0.5%)
 C 2-pass copy                                        :   6492.3 MB/s (0.3%)
 C 2-pass copy prefetched (32 bytes step)             :   6516.0 MB/s (2.4%)
 C 2-pass copy prefetched (64 bytes step)             :   6520.5 MB/s (1.2%)
 ---
 standard memcpy                                      :  12169.8 MB/s (3.4%)
 standard memset                                      :  23479.9 MB/s (4.2%)
 ---
 MOVSB copy                                           :  10197.7 MB/s (1.6%)
 MOVSD copy                                           :  10177.6 MB/s (1.6%)
 SSE2 copy                                            :   8973.3 MB/s (2.5%)
 SSE2 nontemporal copy                                :  12924.0 MB/s (1.7%)
 SSE2 copy prefetched (32 bytes step)                 :   9014.2 MB/s (2.7%)
 SSE2 copy prefetched (64 bytes step)                 :   8964.5 MB/s (2.3%)
 SSE2 nontemporal copy prefetched (32 bytes step)     :  11777.2 MB/s (5.6%)
 SSE2 nontemporal copy prefetched (64 bytes step)     :  11826.8 MB/s (3.2%)
 SSE2 2-pass copy                                     :   7529.5 MB/s (1.8%)
 SSE2 2-pass copy prefetched (32 bytes step)          :   7122.5 MB/s (1.0%)
 SSE2 2-pass copy prefetched (64 bytes step)          :   7214.9 MB/s (1.4%)
 SSE2 2-pass nontemporal copy                         :   4987.0 MB/s

Quelques plats à emporter clés:

• les méthodes rep movs sont plus rapides que toutes les autres méthodes qui ne sont pas" non temporelles " ⁷ , et considérablement plus rapide que les approches" C " qui copient 8 octets à la fois.
• les méthodes" non temporelles "sont plus rapides, jusqu'à environ 26% que les méthodes rep movs -mais c'est un delta beaucoup plus petit que celui que vous avez signalé (26 GO/s vs 15 Go/s = ~73%).
• si vous n'utilisez pas de mémoire non temporelle, l'utilisation de copies de 8 octets à partir de C est à peu près aussi bonne que 128 bits de large charge SSE/mémoire. C'est parce qu'une bonne copie boucle générer suffisamment de pression mémoire pour saturer la bande passante (par exemple, 2,6 GHz * 1 mémoire/cycle * 8 octets = 26 GO/s pour les mémoires).
• il n'y a pas d'algorithmes explicites de 256 bits dans tinymembench (sauf probablement le" standard " memcpy ) mais cela n'a probablement pas d'importance en raison de la note ci-dessus.
• l'augmentation du débit des approches de stockage non temporel par rapport aux approches temporelles est d'environ 1,45 x, ce qui est très proche du 1,5 x auquel on s'attendrait si NT élimine 1 sur 3 transferts (c'est à dire, 1 lire, 1 écrire pour NT vs 2 lit 1 écrire). Les approches rep movs se trouvent au milieu.
• la combinaison d'une latence de mémoire assez faible et d'une bande passante modeste à 2 canaux signifie que cette puce en particulier est capable de saturer sa bande passante de mémoire à partir d'un seul fil, ce qui change le comportement de façon spectaculaire.
• rep movsd semble utiliser la même magie que rep movsb sur cette puce. C'est intéressant parce que ERMSB cible seulement explicitement movsb et des tests antérieurs sur des arches plus tôt avec ERMSB montrent movsb effectuer beaucoup plus rapide que movsd . C'est surtout académique puisque movsb est plus général que movsd de toute façon.

Haswell

en regardant les Haswell results aimablement fournis par iwillnotexist dans les commentaires, nous voyons les mêmes tendances générales (la plupart des résultats pertinents extraits):

 C copy                                               :   6777.8 MB/s (0.4%)
 standard memcpy                                      :  10487.3 MB/s (0.5%)
 MOVSB copy                                           :   9393.9 MB/s (0.2%)
 MOVSD copy                                           :   9155.0 MB/s (1.6%)
 SSE2 copy                                            :   6780.5 MB/s (0.4%)
 SSE2 nontemporal copy                                :  10688.2 MB/s (0.3%)

l'approche rep movsb est encore plus lente que l'approche non temporelle memcpy , mais seulement d'environ 14% ici (comparativement à ~26% dans le test de Skylake). L'avantage des techniques NT au-dessus de leurs cousins temporels est maintenant ~57%, même un peu plus que l'avantage théorique de la réduction de bande passante.

Quand devez-vous utiliser rep movs ?

Enfin un coup de poignard à votre question: quand ou pourquoi devriez-vous utiliser? Il s'inspire de ce qui précède et présente quelques idées nouvelles. Malheureusement, il n'y a pas de réponse simple: vous devrez compenser divers facteurs, y compris certains que vous ne pouvez probablement pas savoir exactement, tels que les développements futurs.

une note que l'alternative à rep movsb peut être la version optimisée libc memcpy (y compris les copies insérées par le compilateur), ou il peut être une version roulée à la main memcpy . Certains des avantages ci-dessous s'appliquent seulement en comparaison à l'une ou l'autre de ces alternatives (par exemple, "simplicité" aide contre une version laminée à la main, mais pas contre intégré memcpy ), mais certains s'appliquent aux deux.

Restrictions sur les instructions disponibles

dans certains environnements Il ya une restriction sur certaines instructions ou l'utilisation de certains registres. Par exemple, dans le noyau Linux, l'utilisation des registres SSE/AVX ou FP est généralement interdite. Donc la plupart des variantes optimisées memcpy ne peuvent pas être utilisées car elles s'appuient sur les registres SSE ou AVX, et une simple copie 64 bits mov est utilisée sur x86. Pour ces plates-formes, l'utilisation de rep movsb permet la plupart des performances d'un optimisé memcpy sans briser la restriction sur le code SIMD.

un exemple plus général pourrait être le code qui doit cibler plusieurs générations de matériel, et qui n'utilise pas de dispatching spécifique au matériel (par exemple, en utilisant cpuid ). Ici, vous pourriez être forcé d'utiliser seulement des ensembles d'instruction plus anciens, ce qui exclut tout AVX, etc. rep movsb pourrait être une bonne approche ici car il permet un accès" caché " à des charges plus larges et des magasins sans utiliser de nouvelles instructions. Si vous ciblez le matériel pré-ERMSB, vous devriez voir si la performance rep movsb est acceptable là, cependant...

Future Proofing

un bel aspect de rep movsb est qu'il peut, en la théorie tire profit de l'amélioration architecturale sur les architectures futures, sans changements de source, que les mouvements explicites ne peuvent pas. Par exemple, lorsque les chemins de données de 256 bits ont été introduits, rep movsb a pu en profiter (comme le prétend Intel) sans aucune modification du logiciel. Le logiciel utilisant des mouvements de 128 bits (ce qui était optimal avant Haswell) devrait être modifié et recompilé.

est donc à la fois un avantage de maintenance du logiciel (no besoin de changer la source) et un avantage pour les binaires existants (pas besoin de déployer de nouveaux binaires pour tirer profit de l'amélioration).

l'importance de ce point dépend de votre modèle de maintenance (p. ex., la fréquence à laquelle les nouveaux binaires sont déployés en pratique) et de la très difficile évaluation de la vitesse probable de ces instructions à l'avenir. Au moins Intel est une sorte de guidage des utilisations dans cette direction cependant, en s'engageant à au moins raisonnable la performance dans l'avenir ( 15.3.3.6 ):

REP et REP MOVSB STOSB continuera à exécuter raisonnablement bien sur futurs Transformateurs.

chevauchement avec des travaux ultérieurs

cet avantage ne se retrouvera pas dans un repère simple memcpy bien sûr, qui, par définition, n'a pas de travaux ultérieurs à chevaucher, de sorte que l'ampleur de l'avantage serait doivent être soigneusement mesurés dans un scénario réel. Pour tirer le maximum d'avantages, il faudrait peut-être réorganiser le code entourant le memcpy .

cet avantage est souligné par Intel dans leur manuel d'optimisation (section 11.16.3.4) et dans leurs mots:

lorsque le nombre est connu pour être au moins mille octets ou plus, en utilisant L'amélioration du REP MOVSB/STOSB peut fournir un autre avantage pour amortir le le coût de la non-consommatrices de code. L'heuristique peut être comprise en utilisant une valeur de Cnt = 4096 et memset() comme exemple:

• une implémentation SIMD 256 bits de memset () devra émettre/exécuter retirer 128 cas d'exploitation de magasins de 32 octets avec VMOVDQA, avant les séquences d'instructions Non consommatrices peuvent faire leur chemin retraite.

• une instance de REPSTOSB amélioré avec ECX = 4096 est décodé comme un long flux micro-op fourni par le matériel, mais se retire comme un instruction. Il existe de nombreuses opérations store_data qui doivent être complétées avant que le résultat de memset() peut être consommé. Parce que l'achèvement d'exploitation de données de magasin est découplé de la retraite de commande de programme, un une partie importante du flux de code non consommateur peut être traitée par l'émission / l'exécution et la retraite, essentiellement gratuitement si le la séquence sans consommation n'est pas en concurrence pour les ressources tampons du magasin.

So Intel dit qu'après tout quelques uops le code après rep movsb a émis, mais alors que beaucoup de magasins sont encore en vol et le rep movsb dans son ensemble n'a pas encore retiré, uops de suivre des instructions peuvent faire plus de progrès à travers la machine hors-d'ordre qu'ils pourraient si ce code est venu après une boucle de copie.

les uops d'une boucle de charge et de stockage explicite doivent tous être retirés séparément dans l'ordre de programmation. Cela doit arriver pour faire de la place dans le ROB pour avoir suivi uops.

il ne semble pas y avoir beaucoup d'informations détaillées sur la longueur des instructions de micro-codage comme rep movsb travailler, exactement. Nous ne savons pas exactement comment les branches de micro-code demandent un flux différent de uops du séquenceur de micro-code, ni comment les UOPs se retirent. Si les UOP individuels ne doivent pas prendre leur retraite séparément, peut-être que l'instruction entière ne prend qu'un seul créneau dans le braquage?

quand le front-end qui alimente la machine OoO voit une instruction rep movsb dans le cache uop, elle active le microcode Sequencer ROM (MS-ROM) pour envoyer le microcode uops dans la file d'attente qui alimente l'étape d'émission/de renommage. Il n'est probablement pas possible pour d'autres uops de se mêler à cela et d'émettre/exécuter ⁸ alors que rep movsb est encore en cours d'émission, mais des instructions ultérieures peuvent être récupérées/décodées et émises juste après le dernier rep movsb uop, alors que certaines copies n'ont pas encore été exécutées. Ceci n'est utile que si au moins une partie de votre code suivant ne dépend pas du résultat du memcpy (ce qui n'est pas inhabituel).

maintenant, la taille de cet avantage est limitée: au plus, vous pouvez exécuter n instructions (uops en fait) au-delà de la lente rep movsb instruction, à quel point vous décrocherez, où N est le ROB taille . Avec les tailles ROB actuelles de ~200 (192 sur Haswell, 224 sur Skylake), c'est un avantage maximum de ~200 cycles de travail libre pour le code suivant avec une IPC de 1. En 200 cycles, vous pouvez copier quelque chose autour de 800 octets à 10 Go/ s, donc pour des copies de cette taille, vous pouvez obtenir du travail gratuit proche du coût de la copie (d'une certaine manière rendant la copie gratuite).

comme les tailles de copie deviennent beaucoup plus grandes, cependant, l'importance relative de ceci diminue rapidement (par exemple, si vous copiez 80 KB à la place, le travail libre est seulement 1% du coût de copie). Il n'en reste pas moins intéressant pour les copies de taille modeste.

ne bloquent pas totalement l'exécution des instructions ultérieures. Intel n'entre pas dans les détails sur l'importance de l'avantage, ou sur le type de copies ou de code environnant il ya le plus d'avantages. (Destination ou source chaude ou froide, ILP élevé ou faible code de haute latence ILP après).

Taille De Code

la taille de code exécutée (quelques octets) est microscopique comparée à une routine optimisée typique memcpy . Si la performance est du tout limitée par les erreurs de I-cache (y compris UOP cache), la taille de code réduite pourrait être bénéfique.

encore une fois, nous pouvons lier l'ampleur de cet avantage en fonction de la taille de la copie. Je ne vais pas vraiment le résoudre numériquement, mais l'intuition est que réduire la taille du code dynamique par les octets B peut sauver au plus C * B cache-manques, pour une certaine constante C. Chaque appel à memcpy entraîne le coût de la perte de cache (ou avantage) une fois, mais l'avantage des échelles de débit plus élevées avec le nombre d'octets copiés. Ainsi, pour les transferts importants, un débit plus élevé dominera les effets de cache.

encore une fois, ce n'est pas quelque chose qui apparaîtra dans un benchmark simple, où l'ensemble de la boucle s'insérera sans doute dans le cache uop. Vous aurez besoin d'un test en place pour évaluer cet effet.

Optimisation Spécifique À L'Architecture

vous avez déclaré que sur votre matériel, rep movsb était considérablement plus lent que la plate-forme memcpy . Cependant, même ici il y a des rapports du résultat opposé sur le matériel plus tôt (comme Ivy Bridge).

c'est tout à fait plausible, car il semble que les opérations de string move obtiennent l'amour périodiquement - mais pas toutes les générations, de sorte qu'il peut bien être plus rapide ou au moins lié (à ce moment-là, il peut gagner basé sur d'autres avantages) sur les architectures où il a été amené à date, seulement pour tomber en retard dans le matériel subséquent.

citant Andy Glew, qui devrait savoir une chose ou deux à ce sujet après avoir mis en œuvre ces Sur le P6:

la grande faiblesse de ce qui va vite chaînes dans microcode était [...] le microcode est tombé d'accord avec chaque génération, devient plus lent et plus lentement jusqu'à ce que quelqu'un arrive à la réparer. Tout comme une bibliothèque hommes copie des chutes de musique. Je suppose qu'il est possible que l'un des les occasions manquées étaient d'utiliser des chargements et des est devenu disponible, et ainsi de suite.

dans ce cas, il peut être considéré comme une autre optimisation" spécifique à la plate-forme "à appliquer dans les routines typiques memcpy que vous trouverez dans les bibliothèques standard et les compilateurs JIT: mais seulement pour une utilisation sur les architectures où il est mieux. Pour les compilations JIT ou AOT, c'est facile, mais pour les compilations statiques binaires compilés cela nécessite une expédition spécifique à la plate-forme, mais qui existe souvent déjà (parfois implémentée au moment de la liaison), ou l'argument mtune peut être utilisé pour prendre une décision statique.

simplicité

même sur Skylake, où il semble qu'il est tombé derrière les techniques non-temporelles les plus rapides absolues, il est encore plus rapide que la plupart des approches et est très simple . Cela signifie moins de temps en validation, moins de bogues mystères, moins de temps de mise au point et de mise à jour d'une implémentation monster memcpy (ou, à l'inverse, moins de dépendance aux caprices des implémentations de la bibliothèque standard si vous vous y fiez).

Plates-Formes Liées À La Latence

Mémoire de débit lié à des algorithmes de ⁹ peut être fait en deux principaux régimes: DRAM de la bande passante liée ou de simultanéité/temps de latence lié.

le le premier mode est celui que vous connaissez probablement: le sous-système DRAM possède une certaine largeur de bande théorique que vous pouvez calculer assez facilement en fonction du nombre de canaux, du débit/largeur de données et de la fréquence. Par exemple, mon système DDR4-2133 avec 2 canaux a une bande passante maximale de 2.133 * 8 * 2 = 34,1 GB / s, identique à rapporté sur ARK .

vous ne supporterez pas plus que ce taux de DRAM (et généralement un peu moins en raison de divers inefficiencies) ajouté à tous les cœurs sur la socket (i.e., il s'agit d'une limite globale pour les systèmes à une seule socket).

l'autre limite est imposée par le nombre de requêtes simultanées qu'un core peut effectivement émettre vers le sous-système mémoire. Imaginez qu'un noyau ne puisse avoir qu'une requête en cours d'exécution à la fois, pour une ligne de cache de 64 octets-une fois la requête terminée, vous pourriez en émettre une autre. Supposons aussi une latence de mémoire de 50ns très rapide. Alors malgré la large bande passante 34,1 GO/s DRAM, vous en fait, on n'obtient que 64 octets / 50 ns = 1,28 GB / s, soit moins de 4% de la bande passante maximale.

dans la pratique, les noyaux peuvent émettre plus d'une requête à la fois, mais pas un nombre illimité. Il est généralement entendu qu'il n'y a que 10 line fill buffers par noyau entre la L1 et le reste de la hiérarchie de mémoire, et peut-être 16 ou si remplir tampons entre L2 et DRAM. Préfetching concurrence pour les mêmes ressources, mais au moins contribue à réduire la efficace de latence. Pour plus de détails Regardez l'un des grands messages Dr.Bandwidth a écrit sur le thème , la plupart du temps sur les forums Intel.

Encore, plus les récents Processeurs sont limitées par ce facteur, pas la RAM de la bande passante. En général, ils atteignent 12 à 20 Go / s par cœur, alors que la bande passante de la mémoire vive peut être de 50+ Go/s (sur un système à 4 canaux). Seuls quelques noyaux de "clients" à 2 canaux de la gen récente, qui semblent pour avoir un meilleur uncore, peut-être plus de tampons de ligne peut frapper la limite DRAM sur un seul noyau, et nos puces Skylake semblent être l'un d'eux.

maintenant, bien sûr, il y a une raison pour laquelle Intel conçoit des systèmes avec une bande passante DRAM de 50 Go/s, tout en ne supportant que < 20 Go/s par core en raison de limites de simultanéité: la première limite est à l'échelle de la socket et la seconde est par core. Ainsi, chaque noyau sur un système 8 core peut pousser 20 Go / s de requêtes, à quel point elles seront limitées DRAM encore.

pourquoi je n'arrête pas de parler de ça? Parce que la meilleure mise en œuvre memcpy dépend souvent du régime dans lequel vous opérez. Une fois que vous êtes limité Dram BW (comme nos puces sont apparemment, mais la plupart ne sont pas sur un seul noyau), l'utilisation non-temporelle écrit devient très important car il sauve la lecture-pour-propriété qui normalement gaspille 1/3 de votre bande passante. Vous voyez cela exactement dans les résultats de test ci-dessus: les implémentations memcpy que ne utiliser les magasins NT perdent 1/3 de leur bande passante.

cependant, si vous êtes limité par la concurrence, la situation s'égalise et parfois s'inverse. Vous avez de la bande passante DRAM à épargner, donc les magasins NT n'aident pas et ils peuvent même faire mal puisqu'ils peuvent augmenter la latence puisque le temps de transfert pour le tampon de ligne peut être plus long qu'un scénario où prefetch apporte la ligne RFO dans LLC (ou même L2) et puis le magasin complète dans LLC pour un efficace inférieur le temps de latence. Enfin, server uncores ont tendance à avoir des magasins NT beaucoup plus lents que les magasins clients (et la bande passante élevée), ce qui accentue cet effet.

donc sur d'autres plateformes vous pourriez trouver que les magasins NT sont moins utiles (au moins quand vous vous souciez de la performance mono-threadée) et peut-être rep movsb Gagne où (si elle obtient le meilleur des deux mondes).

vraiment, ce dernier point est un appel pour la plupart des tests. Je sais que NT les magasins perdent leur avantage apparent pour les tests filetés simples sur la plupart des arcs (y compris les arcs de serveur actuels), mais je ne sais pas comment rep movsb va fonctionner relativement...

Références

autres bonnes sources d'information non intégrées dans ce qui précède.

comp.arch enquête de rep movsb par rapport à des solutions de rechange. Beaucoup de bonnes notes sur la prédiction de la branche, et une mise en œuvre de la approche j'ai souvent suggéré pour les petits blocs: en utilisant le chevauchement première et/ou dernière lecture / écrit plutôt que d'essayer d'écrire seulement exactement le nombre requis d'octets (par exemple, la mise en œuvre de toutes les copies de 9 à 16 octets comme deux copies de 8 octets qui pourraient se chevaucher dans un maximum de 7 octets).

¹ L'intention est probablement de la limiter aux cas où, par exemple, la taille du code est très importante.

² voir , Section 3.7.5: , préfixe REP et mouvement des données.

³ il est important de noter que cela ne s'applique qu'aux divers magasins visés par l'instruction unique elle-même: une fois terminée, le bloc de magasins apparaît toujours commandé par rapport aux magasins antérieurs et subséquents. Donc le code pouvez voir les magasins de la rep movs out of order à l'égard les uns des autres mais pas en ce qui concerne les stocks antérieurs ou ultérieurs (et c'est cette dernière garantie dont vous avez habituellement besoin). Il ne sera un problème si vous utilisez la fin de la destination de la copie comme un drapeau de synchronisation, au lieu d'un magasin séparé.

⁴ notez que les magasins discrets non temporels évitent également la plupart des exigences de commande, bien que dans la pratique rep movs ait encore plus de liberté puisqu'il y a encore quelques contraintes de commande sur les magasins WC/NT.

⁵ C'était courant dans la dernière partie de l'ère des 32 bits, où de nombreuses puces avaient des chemins de données 64 bits (E. g, to support FPUs which had support for the 64-bit double type). Aujourd'hui, les puces" castrées "telles que les marques Pentium ou Celeron ont désactivé AVX, mais probablement rep movs microcode peut encore utiliser 256b charges/magasins.

⁶ par exemple, en raison des règles d'alignement des langues, l'alignement attributs ou opérateurs, règles d'Alias ou autres informations déterminées au moment de la compilation. Dans le cas de l'alignement, même si l'alignement exact ne peut pas être déterminé, ils peuvent au moins être en mesure de hisser les contrôles d'alignement hors des boucles ou d'éliminer autrement les contrôles redondants.

⁷ je fais l'hypothèse que" standard " memcpy est le choix d'une approche non temporelle, ce qui est très probable pour cette taille de tampon.

⁸ ce n'est pas nécessairement évident, car il se pourrait que le flux uop généré par le rep movsb monopolise simplement l'expédition et alors il ressemblerait beaucoup au cas explicite mov . Il semble que cela ne fonctionne pas comme cela cependant-uops des instructions suivantes peuvent se mêler avec uops du micro-codé rep movsb .

⁹ c'est-à-dire: ceux qui peuvent émettre un nombre de demandes de mémoire indépendantes et donc saturer la bande passante DRAM-to-core disponible, dont memcpy serait un poster d'enfant (et comme appliqué à des charges purement liées à la latence telles que la chasse à l'aiguille).