Что такое застопоренные циклы-frontend и stalled-cycles-backend в результате "perf stat"?

Ответ 1

Теория:

Начнем с этого: в настоящее время ЦП являются суперскалярными, что означает, что они могут выполнять более одной инструкции за цикл (IPC). Последние архитектуры Intel могут поддерживать до 4 IPC (4 декодера команд x86). Давайте не будем обсуждать макро/микросинтез, чтобы усложнить ситуацию :).

Как правило, рабочие нагрузки не достигают IPC = 4 из-за разногласий в ресурсах. Это означает, что ЦП теряет циклы (количество инструкций задается программным обеспечением, и ЦП должен выполнять их как можно меньше циклов).

Мы можем разделить общее количество циклов, затраченных процессором, на 3 категории:

1. Циклы, где инструкции удаляются (полезная работа)
2. Циклы, проводимые в Back-End (впустую)
3. Циклы, проведенные в Front-End (впустую).

Чтобы получить IPC 4, количество выходящих из цикла циклов должно быть близко к общему количеству циклов. Помните, что на этом этапе все микрооперации (uOps) удаляются из конвейера и фиксируют свои результаты в регистрах/кэшах. На этом этапе вы можете удалить даже более 4 мегапикселей, потому что это число определяется числом портов выполнения. Если у вас есть только 25% циклов, выходящих на пенсию 4 uOps, тогда у вас будет общий IPC 1.

Циклы, остановленные в бэкэнде, являются пустой тратой, потому что ЦП должен ждать ресурсы (обычно память) или завершать инструкции с большой задержкой (например, transcedentals - sqrt, взаимные ответвления, деления и т.д.).

Циклы, остановленные во внешнем интерфейсе, являются пустой тратой, потому что это означает, что внешний интерфейс не питает внутренний конец микрооперациями. Это может означать, что в кеше инструкций есть ошибки или сложные инструкции, которые еще не декодированы в кеше микроопераций. Скомпилированный код точно в срок обычно выражает это поведение.

Еще одна причина задержки - промах прогнозирования ветвей. Это называется плохой спекуляцией. В этом случае uOps выдаются, но они отбрасываются, потому что BP предсказал неверно.

Реализация в профилировщиках:

Как вы интерпретируете застойные циклы BE и FE?

Различные профилировщики имеют разные подходы к этим метрикам. В vTune категории с 1 по 3 складываются, давая 100% циклов. Это кажется разумным, потому что либо ваш процессор остановлен (ни один uOps не удаляется), либо он выполняет полезную работу (uOps), удаляясь. Подробнее здесь: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm

В перфе такого обычно не бывает. Это проблема, потому что, когда вы видите, что 125% циклов остановились во внешнем интерфейсе, вы не знаете, как на самом деле это интерпретировать. Вы можете связать метрику> 1 с тем фактом, что имеется 4 декодера, но если вы продолжите рассуждение, то IPC не будет совпадать.

Даже лучше, вы не знаете, насколько велика проблема. 125% из чего? Что же тогда означают циклы?

Я лично выгляжу немного подозрительно по поводу циклов PER и FE, которые застопорились, и надеюсь, что это будет исправлено.

Вероятно, мы получим окончательный ответ, отладив код здесь: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c

Ответ 2

Чтобы преобразовать общие события, экспортированные perf, в исходные события документации процессора, вы можете запустить:

more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend 

Он покажет вам что-то вроде

event=0x0e,umask=0x01,inv,cmask=0x01

В соответствии с Intel документации SDM том 3B (у меня есть ядро ​​i5-2520):

UOPS_ISSUED.ANY:

• Увеличивает каждый цикл # Uops, выданный RAT на RS.
• Установить Cmask = 1, Inv = 1, Any = 1 для подсчета циклов с задержкой этого ядра.

Для события stalled-cycles-backend, переводящего событие = 0xb1, umask = 0x01 в моей системе, в той же документации говорится:

UOPS_DISPATCHED.THREAD:

• Подсчитывает общее количество отправителей, отправляемых за каждый цикл.
• Установите Cmask = 1, INV = 1 для подсчета циклов сваливания.

Обычно заторможенные циклы - это циклы, в которых процессор что-то ждет (память может быть подана после выполнения операции загрузки, например) и не имеет каких-либо других действий. Кроме того, интерфейсная часть CPU представляет собой часть аппаратного обеспечения, ответственного за выборку и декодирование команд (преобразование их в UOP), где, поскольку бэкэнд-часть отвечает за эффективное выполнение UOPs.

Ответ 3

Цикл процессора "заторможен", когда трубопровод не продвигается во время его работы.

Конвейер процессора состоит из нескольких этапов: front-end представляет собой группу этих этапов, которая отвечает за фазы выборки и декодирования, в то время как back-end выполняет инструкции. Существует буфер между front-end и back-end, поэтому, когда первый застопорился, последний может по-прежнему выполнять некоторую работу.

Взято из http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/

Ответ 4

По словам автора этих событий, они определяются свободно и приближаются доступными счетчиками производительности процессора. Как я знаю, perf не поддерживает формулы для вычисления синтетического события на основе нескольких аппаратных событий, поэтому он не может использовать метод привязки к интерфейсу front-end/back-end stall из руководства по оптимизации Intel (реализован в VTune) http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2 Иерархическая методология определения производительности сверху вниз"

%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)

Правые формулы могут использоваться с некоторыми внешними скриптами, как это было сделано в Andi Kleen pmu-tools (toplev.py): https://github.com/andikleen/pmu-tools (источник), http://halobates.de/blog/p/262 (описание):

% 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, в котором введены события с остановками циклов - frontend и stalled-cycles-backend вместо оригинального универсального stalled-cycles:

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a

author  Ingo Molnar <[email protected]>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <[email protected]>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

perf events: добавьте общие определения событий цикла переднего и заднего конца Добавьте два общих аппаратных события: передние и задние блокированные циклы.

Эти события измеряют условия, когда процессор выполняет код, но его возможности не используются в полной мере. Понимание таких ситуаций и их анализ является важной подзадачей рабочих процессов оптимизации кода.

Оба события ограничивают производительность: большинство передних ларьков, как правило, вызывают по неверному предсказанию ветвления или сбору выборки команд, бэкэнд киоски могут быть вызваны нехваткой ресурсов или неэффективными планирование инструкций.

Заключительные палатки более важны: код не может быстро работать если поток команд не поддерживается.

Перегруженный back-end сервер может вызвать передние стойки и, следовательно, также нужно следить.

Точная композиция - это очень программная логика и сочетание команд зависимыми.

Мы используем термины "стойло", "front-end" и "back-end" свободно и попытайтесь использовать наилучшие доступные события от определенных процессоров, которые приблизить эти понятия.

Cc: Питер Зийлстра Корабль: Арнальдо Карвалью де Мело Cc: Фредерик Вайсбеккер Ссылка: http://lkml.kernel.org/n/[email protected]Подписано: Инго Молнар

    /* 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,