Как измерить поздние предварительные выборки и убитые предварительные выборки на микроархитектуре Haswell?

Я использую Intel Xeon 2660 v3 и делаю много предварительных выборок программного обеспечения для использования MLP, а также для сокращения времени простоя. Теперь я хочу профилировать приложение, чтобы получить общий выигрыш за счет предварительной загрузки программного обеспечения.

В статье «Повышение эффективности программной предварительной выборки с помощью адаптивного выполнения» авторы обсуждали поддержку счетчика производительности в оборудовании, связанном с программной предварительной выборкой.

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

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

Я хочу профилировать приложение для микроархитектуры Haswell, но не могу найти такой счетчик производительности в Perf или PAPI. Итак, есть ли какие-либо другие счетчики производительности для получения таких событий и как лучше всего сделать это для небольшой части кода вместо того, чтобы делать это для всего приложения?

Paper Link


x86 intel prefetch intel-pmu
person A-B    schedule 28.12.2017    source источник

Ответы (1)


arrow_upward
3
arrow_downward

ocperf.py - это оболочка для perf с символическими именами для конкретных событий uarch, таких как load_hit_pre.sw_pf (засчитывается, когда загрузка по запросу, отправленная на порт загрузки, попадает в буфер заполнения L1D (FB), выделенный для программной предварительной выборки). ocperf.py list имеет описания, а также имена.

Это, вероятно, полезно для просмотра, но я сам не использовал его, поэтому IDK, если он действительно работает, чтобы быть именно тем, что вам нужно. Обязательно посмотрите список событий (ocperf.py list | less).

Вам также следует посмотреть на коэффициент промахов L1D; при успешной предварительной выборке, которая опережает нагрузку по запросу, фактические инструкции загрузки должны попасть в L1D. (И простой perf может отследить это с помощью L1-dcache-load-misses.)

Для линий измерения, которые были предварительно загружены, но удалены перед использованием, есть l2_lines_out.useless_hwpf. "Подсчитывает количество строк, которые были предварительно загружены на аппаратном уровне, но не использовались и теперь удалены из кэша L2". l2_lines_out.useless_pref - это псевдоним для этого; не похоже, что есть подобное событие, которое включает предварительную выборку SW.

Возможно, вам просто нужно посмотреть на частоту промахов L1D; это должно сказать вам, где находится диапазон наилучших точек для расстояния предварительной выборки. Если load_hit_pre.sw_pf работает так, как я надеюсь, то промахи L1D с низкими счетами для load_hit_pre.sw_pf означают, что расстояние предварительной выборки слишком велико. (Или то, что запросы предварительной выборки SW отбрасываются по какой-то другой причине, но я думаю, что только запросы предварительной выборки HW отбрасываются, когда существует большая загрузка по запросу).

Аппаратные события perf-counter для хранилищ гораздо более ограничены, чем для загрузок, поэтому, если вы пытаетесь выполнить предварительную выборку для потока только для записи, это будет сложнее измерить. Устройство предварительной выборки HW в L1D может вообще не выполнять предварительную выборку для магазинов, поэтому разные шаблоны доступа для потоков только для записи могут сильно пострадать. См. Также комментарий @ BeeonRope к этому ответу: Предварительная выборка SW для магазинов может помочь, если они попадают в L2, но не в L1D. prefetchw идеально, но простой prefetcht0 по-прежнему полезен. (prefetchw работает как NOP на Haswell и ранее.)

См. Также другие ссылки в вики-странице по тегам x86

person Peter Cordes    schedule 28.12.2017
comment
l2_lines_out_useless_hwpf и l2_lines_out_useless_pref - два разных названия одного и того же события. Также обратите внимание, что в последних perf версиях также есть события, относящиеся к арке. Поскольку я обновился до ядра 4.10.x, perf имеет почти те же события, что и ocperf (то есть все события Skylake), включая два, которые вы упомянули. Что касается магазинов и устройств предварительной выборки L1, у меня сложилось впечатление, что устройства предварительной выборки L1 никогда не запускаются хранилищами. Однако вы можете эффективно выполнять предварительную выборку SW для магазинов даже без prefetchw. - person BeeOnRope; 29.12.2017
comment
Привет, Питер, если это не слишком тяжело, не могли бы вы прояснить часть о том, что prefetchw быть NOP? Спасибо! - person Margaret Bloom; 29.12.2017
comment
@MargaretBloom: До Core2 процессоры Intel #UD по инструкции prefetchw 3dNOW. От Core2 до Haswell это NOP. (Windows 8.1 для x86-64 требует, чтобы prefetchw не работал; возможно, Microsoft попросила Intel запустить его хотя бы как NOP.) Начиная с Broadwell, процессоры Intel устанавливали бит функции prefetchw CPUID и запускали его как фактическую предварительную выборку в Эксклюзивное состояние. - person Peter Cordes; 29.12.2017