Ce sont au point mort-cycles-frontend et au point mort-cycles-backend dans "perf stat' résultat?

Quelqu'un sait ce qu'est le sens de au point mort-cycles-frontend et au point mort-cycles-backend en perf stat résultat ? J'ai cherché sur internet mais n'a pas trouvé la réponse. Grâce

$ sudo perf stat ls                     

Performance counter stats for 'ls':

      0.602144 task-clock                #    0.762 CPUs utilized          
             0 context-switches          #    0.000 K/sec                  
             0 CPU-migrations            #    0.000 K/sec                  
           236 page-faults               #    0.392 M/sec                  
        768956 cycles                    #    1.277 GHz                    
        962999 stalled-cycles-frontend   #  125.23% frontend cycles idle   
        634360 stalled-cycles-backend    #   82.50% backend  cycles idle
        890060 instructions              #    1.16  insns per cycle        
                                         #    1.08  stalled cycles per insn
        179378 branches                  #  297.899 M/sec                  
          9362 branch-misses             #    5.22% of all branches         [48.33%]

   0.000790562 seconds time elapsed

Je ne suis pas sûr de ce que la vraie question est ici. Demandez ce que le frontend et le backend d'un PROCESSEUR? Veuillez lire ce très haut niveau introduction. Est-ce répondre à votre question?
J'ai cherché et la recherche d'une semblable réponse... C'était la ressource la plus utile que j'ai trouvé d'Intel: software.intel.com/en-us/articles/...
Non, presque personne ne sait ce que ces signifient vraiment. Mais le référencement manuel (comme dans le Manuel Selva réponse) combiné avec ce post (que je ne comprends pas tout encore), sont le plus proche que j'ai trouvé: sites.utexas.edu/jdm4372/2014/06/04/...

InformationsquelleAutor Dafan | 2014-03-04

47

La théorie:

Commençons par ceci: aujourd'hui, la CPU sont superscalar, ce qui signifie qu'ils peuvent exécuter plus d'une instruction par cycle (IPC). Les dernières architectures Intel peut aller jusqu'à 4 CIB (4 décodeurs d'instructions x86). Ne soyons pas apporter de macro /micro fusion dans le débat pour compliquer les choses plus :).

Généralement, la charge de travail n'atteignent pas la CIB=4 en raison des diverses ressources de querelles. Cela signifie que le CPU est gaspiller des cycles (nombre d'instructions est donné par le logiciel et le PROCESSEUR doit exécuter en quelques cycles que possible).

Nous pouvons diviser le total des cycles étant passé par le PROCESSEUR en 3 catégories:
1. Des Cycles où les instructions de la retraite (utile)
2. Cycles étant passé dans le Back-End (gaspillage)
3. Cycles passé dans le Front-End (gaspillage).
Pour obtenir une classification de 4, le nombre de cycles de retraite d'être au plus près le nombre total de cycles. Gardez à l'esprit qu'à cette étape, tous les micro-opérations (uop) à la retraite à partir de la canalisation et d'engager leurs résultats dans des registres /caches. À ce stade, vous pouvez même avoir plus de 4 uop à la retraite, parce que ce nombre est donné par le nombre d'exécution de ports. Si vous avez seulement 25% des cycles de retraite 4 uop, alors vous allez avoir une vue d'ensemble de l'IPC de 1.

La cycles calé dans le back-end sont une perte de temps parce que le PROCESSEUR doit attendre pour les ressources (généralement la mémoire) ou pour terminer une longue période de latence des instructions (par exemple, transcedentals - sqrt, inverses, les divisions, etc.).

La cycles calé dans le front-end sont un gaspillage, car cela signifie que le Front-End ne se nourrit pas la Fin avec les micro-opérations. Cela peut signifier que vous avez manque dans le cache d'Instructions, ou instructions complexes qui ne sont pas déjà décodé dans le micro-op cache. Juste-à-temps, le code compilé exprime généralement ce comportement.

Une autre raison de décrochage est la branche de prédiction de la miss. Qui est appelé la mauvaise spéculation. Dans ce cas, uOps sont émises, mais ils sont rejetés car la BP prédit mal.

La mise en œuvre dans les profileurs:

Comment interprétez-vous l'ÊTRE et FE impasse des cycles?

Différents profileurs ont des approches différentes de ces mesures. Dans vTune, les catégories 1 à 3 ajouter jusqu'à se donner à 100% des cycles. Que les coutures raisonnable, soit parce que vous avez votre CPU bloqué (pas de uop sont à la retraite), soit il effectue utile de travail (uop) à la retraite. Voir plus ici: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm

En perf cela ne se produit généralement pas. C'est un problème parce que quand vous voyez 125% cycles de l'impasse dans l'extrémité avant, vous ne savez pas comment l'interpréter. Vous pouvez lier l' >1 métrique avec le fait qu'il y a 4 décodeurs, mais si vous continuez le raisonnement, alors la CIB ne correspond pas.

Encore mieux, vous ne savez pas comment l'ampleur du problème. 125% de quoi? Ce qui ne l' #cycles de moyenne alors?

Personnellement, j'ai l'air un peu méfiant sur la perf de l'ÊTRE et de FE impasse des cycles et espérons que ce sera corrigé.

Probablement, nous allons obtenir la réponse finale par le débogage du code à partir d'ici: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c
- Quels sont les événements sont utilisés dans VTune que FE et de l'ÊTRE? Manuel des événements publiés à partir de perf sur le Sandy Bridge. Parfois, le décodeur ne peut pas décoder les 4 instructions (realworldtech.com/sandy-bridge/4 - il y a 3 simples décodeurs qui ne peut pas décoder des commandes complexes).
- C'est vrai il y a aussi un complexe de décodeur, mais il peut être également capable de décoder les instructions simples. J'ai mis à jour mon post avec un lien vers vTune compteurs. Il utilise les mêmes compteurs de perf, mais je pense que vTune combine différemment.
- Vtune utilise software.intel.com/en-us/articles/... "IDQ_UOPS_NOT_DELIVERED.CORE / SLOTS", comme le "Frontend " lié" et "1 - (Front-End Lié + Retraite + Mauvaise Spéculation)." comme le "Backend " lié" où "Retraite = UOPS_RETIRED.RETIRE_SLOTS / SLOTS", "la Mauvaise Spéculation=(UOPS_ISSUED.TOUT – UOPS_RETIRED.RETIRE_SLOTS + 4*INT_MISC.RECOVERY_CYCLES) / SLOTS" et de "SLOTS=4* CPU_CLK_UNHALTED.FIL" avec 4 égal à "la machine pipeline de largeur".
- Et pour Sandy Bridge d'Intel manuel d'Optimisation intel.com/content/dam/www/public/us/en/documents/manuals/... donne le même dans "B. 3.2 Hiérarchique de Haut en Bas la Caractérisation des Performances de la Méthodologie" "%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N ) ; %Bad_Speculation = 100 * ( (UOPS_ISSUED.TOUT – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ; %la Retraite = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ; %BE_Bound = 100 * (1 – (FE_Bound + Retraite + Bad_Speculation) ) ; N = 4*CPU_CLK_UNHALTED.FIL"
- Merci. Maintenant, nous savons ce faire, les mesures dire dans vTune et qu'ils ajoutent jusqu'à 100%. La prochaine question est de savoir pourquoi perf calculer différemment? Est-ce un bug ou est-il un sens derrière tout cela?
- VAndrei, l'un des patchs: lkml.iu.edu/hypermail/linux/kernel/1105.0/02486.html "[PATCH] perf événements, x86: Ajouter SandyBridge au point mort-cycles-frontend/backend événements" Lin Ming @06 Mai 2011 "s'engager 3011203 dit, ce ne sont que des approximations."; En 2011, la situation Eranian dit: cscads.rice.edu/workshops/summer-2011/slides/performance-tools/... "Générique décrochage événements ● deux nouveaux génériques PMU événements: ○PERF_COUNT_HW_STALLED_CYCLES_FRONTEND ○PERF_COUNT_HW_STALLED_CYCLES_BACKEND ○ pas de définitions claires". s'engager 8f62242246351b5a4bc0c1f00c0c7003edea128a
- Ne sais pas comment inv=1 est mis en œuvre (calculée) pour "UOPS_ISSUED.TOUT" (paramètres réels: Cmask = 1, Inv = 1, Any= 1 - UOPS_ISSUED.CORE_STALL_CYCLES - "Cycles où aucun uop ont été émises à l'OOO backend de la pipleine soit par fil logique").
InformationsquelleAutor VAndrei
39

Pour convertir générique événements exportées par perf dans votre PROCESSEUR de la documentation d'événements bruts, vous pouvez exécuter:
```
more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend 
```
Il va vous montrer quelque chose comme
```
event=0x0e,umask=0x01,inv,cmask=0x01
```
Selon la Documentation Intel SDM volume 3B (j'ai un core i5-2520):

UOPS_ISSUED.TOUT:
- Augmente à chaque cycle, le nombre de Uop émis par le RAT de RS.
- Ensemble Cmask = 1, Inv = 1,= 1 pour le comte impasse des cycles de ce noyau.
Pour le point mort-cycles-backend événement se traduisant par événement=0xb1,umask=0x01 sur mon système, le même documentation dit:

UOPS_DISPATCHED.FIL de discussion:
- Compte nombre total de uop à être distribué par thread à chaque cycle
- Ensemble Cmask = 1, INV =1 à compter de décrochage cycles.
Généralement, calé, les cycles sont des cycles où le processeur est en attente de quelque chose (de la mémoire après l'exécution d'une opération de chargement par exemple) et ne pas avoir d'autres trucs à faire. En outre, l'interface de PROCESSEUR est l'élément matériel chargé de récupérer et de décoder des instructions (les convertir en Uop) où comme la principale partie est responsable à l'exécution effective de l'Uop.
- merci pour votre réponse. alors, quelle est la différence entre l'impasse et de repos?
- Impasse des et de repos sont les mêmes. PROCESSEUR est inactif en raison de ses bloqué car l'instruction pipeline n'est pas en mouvement.
- ne devrait pas il devrait y avoir une différence, calé, doit être "nous ne progressons pas parce que la prochaine étape ne le permet pas", et ralenti doit être "il n'y a rien de processus"?
InformationsquelleAutor Manuel Selva
13

Un cycle CPU est “bloqué” lorsque le pipeline ne fait pas avancer pendant.

Processeur pipeline est composé de plusieurs étapes: le front-end est un groupe de ces étapes, qui est responsable de l'extraction et de décoder les phases, tandis que le back-end exécute les instructions. Il y a un tampon entre les front-end et back-end, de sorte que lorsque l'ancien est au point mort ces derniers peuvent avoir encore un peu de travail à faire.

Prises de http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/
- Comment on peut avoir plus de stands que les cycles?
InformationsquelleAutor Milind Dumbare
11

Selon l'auteur de ces événements, ils ont défini de manière vague et sont approchées par des processeurs disponibles compteurs de performance. Que je sache, les perf ne prend pas en charge les formules pour calculer certaines synthétique de l'événement basé sur plusieurs événements de matériel, de sorte qu'il ne peut pas utiliser de front-end/back-end de décrochage de la méthode liée à partir d'Intel manuel d'Optimisation (mise en œuvre en VTune) http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B. 3.2 Hiérarchique De Haut En Bas La Caractérisation Des Performances De La Méthodologie"
```
%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE /N ); 
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) /N) ; 
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/N) ; 
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ; 
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)
```
Droit formules peuvent être utilisées avec certains scripts externes, comme cela a été fait dans l'Andi Kleen du pmu-outils (toplev.py): https://github.com/andikleen/pmu-tools (source), http://halobates.de/blog/p/262 (description):
```
% toplev.py -d -l2 numademo  100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE      Backend Bound:                      72.03%
    This category reflects slots where no uops are being delivered due to a lack
    of required resources for accepting more uops in the    Backend of the pipeline.
 .....
FE      Frontend Bound:                     54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.
```
Commit qui a introduit l'impasse-cycles-frontend et au point mort-cycles-backend des événements au lieu de l'original universelle stalled-cycles:

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a
```
author  Ingo Molnar <mingo@el...>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <mingo@el...>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)
```
perf événements: Ajouter générique front-end et back-end de l'impasse du cycle de définitions d'événements
Ajouter deux génériques des événements de matériel: front-end et back-end impasse des cycles.

Ces événements des conditions de mesure lorsque la CPU est à l'exécution de code mais sa
les capacités ne sont pas pleinement utilisées. La compréhension de ces situations et
en les analysant, est un important sous-tâche de l'optimisation du code des flux de travail.

Les deux événements limiter les performances: la plupart des front-end stands ont tendance à être causée
par branche, les erreurs de prédiction ou d'une instruction fetch cachemisses, backend
stands peut être causée par diverses pénuries de ressources ou inefficace
la planification d'instructions.

Avant la fin de l'étals sont les plus importants: le code ne peut pas courir vite
si l'instruction stream n'est pas maintenu.

Une sur-utilisation de back-end peut entraîner avant la fin de stands et donc
faut garder un œil sur ainsi.

La composition exacte est très logique de programme et les instructions de mélange
dépendante.

Nous utilisons les termes de "décrochage", "front-end" et "back-end" lâche et
essayez d'utiliser les meilleurs événements de certains Processeurs
rapprocher ces concepts.

Cc: Peter Zijlstra
Cc: Arnaldo Carvalho de Melo
Cc: Frédéric Weisbecker
Lien: http://lkml.kernel.org/n/[email protected]
Signed-off-by: Ingo Molnar
```
    /* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
-       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;

-   PERF_COUNT_HW_STALLED_CYCLES        = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_FRONTEND   = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_BACKEND    = 8,
```
- Donc en fin de compte est-il une erreur en perf? Parce que FE + ÊTRE + ? ne pas ajouter à une valeur théorique, il est difficile d'évaluer quel est le problème de votre code. Quand vous voyez 75% de FE de blocage qui doit être comparé à quelque chose. Dire 75% 100% le code est bloqué dans la FE ou a une toute autre signification et la valeur. De ce que je vois, même toplev.py a la même question. Si ce n'est pas un problème, comment interpréter les statistiques? Ce qui rend les mesures de haute ou basse?
- VAndrei, avez-vous des short et reproductible exemple pour SandyBridge (+-1 génération); à la fois pour perf stat avec FE > 100% et pour toplev.py? Je viens de commencer à partir de courtes et simples boucles et 3G cycles pour la 3G instructions (1G sont les branches avec de 0,00% miss taux) avec 2G FE stands (perf stat) et 1G stalles (IPC=1.00). Je pense que le problème est de définir correctement le "décrochage" pour le complexe OOO base et un autre est à interpréter correctement les toplev.py résultats.
- Le code que j'ai posté ici: stackoverflow.com/questions/28961405/... devrait être avant la fin de lié. Il y a beaucoup de succursale de la rate, ce qui permettrait de générer FE stands. Quant à ÊTRE lié vous avez besoin d'une charge de travail qui les attend à partir de données de la mémoire vive. Allouer 1/2 de votre taille de la mémoire physique dans une mémoire tampon, et l'utilisation d'une GRILLE (comme dans mon code) de faire une lecture/modification/écriture à un endroit aléatoire dans la mémoire tampon. Qui génère un petit nombre d'instructions en plus de la RMW transaction et le cœur de décrochage dans l'attente de données de la mémoire vive.
- Générer FE lié à des charges de travail est un défi. S'il vous plaît essayer si la ramification microbenchmark fonctionne, mais si vous avez besoin quelque chose de plus complexe. La FE de décrochage serait générée par le grand nombre d'instructions de défauts de cache. Pour ce faire, vous avez besoin d'un code volumineux avec beaucoup de sauts à travers elle à mener à de multiples I$ de justesse. Je n'ai pas à ce stade une ideea sur la façon de faire une FE tenu de la charge de travail dans un microbenchmark.
- Je pense que vous seriez intéressé par ce lien: stackoverflow.com/questions/1756825/... Vous pouvez utiliser certains de ces discuté des techniques pour rincer le I$ et donc générer des FE stands.
InformationsquelleAutor osgx

Vous devez vous connecter pour publier un commentaire.