Que sont les cycles bloqués-frontend et les cycles-bloqués-backend dans le résultat 'perf stat'?
Est-ce que quelqu'un sait quelle est la signification de stalled-cycles-frontend et stalled-cycles-backend dans le résultat de la statistique de performance? J'ai cherché sur internet mais je n'ai pas trouvé la réponse. Merci
$ 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
La théorie:
Commençons par ceci: les CPUs d'aujourd'hui sont superscalaires, ce qui signifie qu'ils peuvent exécuter plus d'une instruction par cycle (IPC). Les dernières architectures Intel peuvent aller jusqu'à 4 IPC (4 décodeurs d'instructions x86). Ne discutons pas de macro/micro fusion pour compliquer les choses :).
En règle générale, les charges de travail n'atteignent pas IPC = 4 en raison de diverses allégations de ressources. Cela signifie que la CPU perd des cycles (le nombre d'instructions est donné par le logiciel et la CPU doit les exécuter en aussi peu de cycles que possible).
Nous pouvons diviser le nombre total de cycles passés par le CPU en 3 catégories:
- Cycles où les instructions sont retirées (travail utile)
- Cycles passés dans le back-end (gaspillés)
- Cycles passés dans le Front-End (gaspillés).
Pour obtenir un IPC sur 4, le nombre de cycles retirés doit être proche du nombre total de cycles. Gardez à l'esprit qu'à ce stade, toutes les micro-opérations (uOps) se retirent du pipeline et engagent leurs résultats dans des registres/caches. À ce stade, vous pouvez avoir encore plus de 4 uOps à la retraite, car ce nombre est donné par le nombre de ports d'exécution. Si vous n'avez que 25% des cycles retirant 4 uOps, vous aurez alors un IPC de 1.
Les cycles bloqués dans le back-end sont un gaspillage car le CPU doit attendre des ressources (généralement de la mémoire) ou terminer de longues instructions de latence (par exemple transcentrales) - sqrt, réciproques, divisions, etc.).
Les cycles bloqués dans le frontal sont un gaspillage car cela signifie que le frontal ne nourrit pas le backend avec des micro-opérations. Cela peut signifier que vous avez des échecs dans le cache d'instructions ou des instructions complexes qui ne sont pas déjà décodées dans le cache micro-op. Le code compilé juste à temps exprime généralement ce comportement.
Une autre raison de blocage est le manque de prédiction de branche. C'est ce qu'on appelle une mauvaise spéculation. Dans ce cas, des uOps sont émis mais ils sont rejetés car le BP a prédit une erreur.
L'implémentation dans les profileurs:
Comment interprétez-vous les cycles bloqués BE et FE?
Différents profileurs ont des approches différentes sur ces mesures. Dans vTune, les catégories 1 à 3 s'additionnent pour donner 100% des cycles. Cela semble raisonnable car soit votre processeur est bloqué (aucune uOps ne se retire), soit il effectue un travail utile (uOps) en se retirant. Voir plus ici: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm
En pratique, cela ne se produit généralement pas. C'est un problème parce que lorsque vous voyez 125% de cycles bloqués dans le frontal , vous ne savez pas vraiment comment interpréter cela. Vous pouvez lier la métrique> 1 au fait qu'il y a 4 décodeurs mais si vous continuez le raisonnement, alors le IPC ne correspondra pas.
Encore mieux, vous ne savez pas quelle est l'ampleur du problème. 125% de quoi? Que signifient alors les # cycles?
Personnellement, j'ai l'air un peu méfiant sur les cycles bloqués BE et FE de perf et j'espère que cela sera corrigé.
Nous obtiendrons probablement la réponse finale en déboguant le code d'ici: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin- stat.c
Pour convertir des événements génériques exportés par perf en événements bruts de votre documentation CPU, vous pouvez exécuter:
more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend
Cela vous montrera quelque chose comme
event=0x0e,umask=0x01,inv,cmask=0x01
Selon le Intel documentation SDM volume 3B (j'ai un core i5-2520):
UOPS_ISSUED.ANY:
- Incrémente à chaque cycle le nombre d'Uops émis par le RAT à RS.
- Définissez Cmask = 1, Inv = 1, Any = 1 pour compter les cycles bloqués de ce noyau.
Pour l'événement stalled-cycles-backend se traduisant par event = 0xb1, umask = 0x01 sur mon système, la même documentation dit:
UOPS_DISPATCHED.THREAD:
- Compte le nombre total d'uops à envoyer par thread à chaque cycle
- Réglez Cmask = 1, INV = 1 pour compter les cycles de décrochage.
Habituellement, les cycles bloqués sont des cycles où le processeur attend quelque chose (la mémoire doit être alimentée après l'exécution d'une opération de chargement par exemple) et n'a rien d'autre à faire. De plus, la partie frontale du CPU est la pièce matérielle chargée de récupérer et de décoder les instructions (les convertir en UOP) alors que la partie backend est chargée d'exécuter efficacement les UOP.
Un cycle de processeur est "bloqué" lorsque le pipeline n'avance pas pendant ce temps.
Le pipeline du processeur est composé de plusieurs étapes: le front-end est un groupe de ces étapes qui est responsable des phases d'extraction et de décodage, tandis que le back-end exécute les instructions. Il y a un tampon entre le front-end et le back-end, donc quand le premier est bloqué, le second peut encore avoir du travail à faire.
Extrait de http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/
Selon l'auteur de ces événements, ils ont été définis de manière lâche et sont approximés par les compteurs de performances CPU disponibles. Comme je le sais, perf ne prend pas en charge les formules pour calculer un événement synthétique basé sur plusieurs événements matériels, il ne peut donc pas utiliser la méthode liée au décrochage frontal/principal du manuel d'optimisation d'Intel (implémenté dans VTune) http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2 Top-Down hiérarchique Méthodologie de caractérisation des performances "
%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)
Les bonnes formules peuvent être utilisées avec certains scripts externes, comme cela a été fait dans les outils pmu d'Andi Kleen (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 les événements stalled-cycles-frontend et stalled-cycles-backend au lieu de l'original universel stalled-cycles:
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)
événements perf: ajout de définitions d'événements génériques de cycles bloqués frontaux et principaux Ajoutez deux événements matériels génériques: cycles bloqués frontaux et principaux.
Ces événements mesurent les conditions lorsque le CPU exécute du code mais que ses capacités ne sont pas pleinement utilisées. Comprendre de telles situations et les analyser est une sous-tâche importante des workflows d'optimisation de code.
Les deux événements limitent les performances: la plupart des blocages frontaux ont tendance à être causés par des erreurs de prédiction de branche ou des cachemisses de récupération d'instructions, les blocages de backend peuvent être causés par diverses pénuries de ressources ou une planification d'instructions inefficace.
Les décrochages frontaux sont les plus importants: le code ne peut pas s'exécuter rapidement si le flux d'instructions n'est pas maintenu.
Un back-end sur-utilisé peut provoquer des décrochages frontaux et doit donc être également surveillé.
La composition exacte est très dépendante de la logique du programme et du mix d'instructions.
Nous utilisons les termes "décrochage", "front-end" et "back-end" de manière lâche et essayons d'utiliser les meilleurs événements disponibles à partir de processeurs spécifiques qui se rapprochent de ces concepts.
Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Lien: http://lkml.kernel.org/n/[email protected] Signé-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,