Бенчмаркинг - Как подсчитать количество команд, отправленных на процессор, чтобы найти потребленные MIPS - PullRequest
0 голосов
/ 25 апреля 2018

Предположим, у меня есть программное обеспечение и я хочу изучить его поведение, используя черный ящик .У меня 3,0 ГГц процессор с 2 разъемами и 4 ядрами.Как вы знаете, чтобы узнать количество команд в секунду (IPS), мы должны использовать следующую формулу:

IPS = sockets*(cores/sockets)*clock*(instructions/cycle)

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

Но теперь у меня есть два вопроса: независимо от того, какое программное обеспечение работаетНа моей машине и использовании процессора, есть ли способ подсчитать количество команд в секунду, отправляемых в ЦП (Миллионы команд в секунду (MIPS))?И можно ли найти тип набора инструкций (добавить, сравнить, ввести, перейти и т. Д.)?

Буду признателен за любую рекомендацию скрипта или инструмента (на любом языке).

1 Ответ

0 голосов
/ 01 мая 2018

perf stat ./my_program в Linux будет использовать счетчики производительности процессора, чтобы записывать, сколько инструкций он выполнил, и сколько тактов ядра потребовалось. И сколько процессорного времени он использовал, и рассчитает для вас средние инструкции за такт ядра, например
3,496,129,612 instructions # 2.61 insn per cycle. Это обычно более интересно, чем инструкции за секунду . uops за часы обычно еще более интересны с точки зрения того, насколько вы близки к максимальному увеличению внешнего интерфейса.

Но см. Как рассчитать MIPS с использованием perf stat для получения более подробной информации о instructions / task-clock против instructions / elapsed_time, если вы действительно хотите получить общее или среднее значение MIPS по ядрам и подсчет сна или нет.


Пример выходных данных его использования в крошечном цикле микробенчмарка в статическом исполняемом файле см. Может ли MOV x86 действительно быть «свободным»? Почему я вообще не могу воспроизвести это?

Как получить информацию в режиме реального времени во время выполнения

Вы имеете в виду, что внутри программы нужно профилировать только ее часть? Есть Perf API, где вы можете сделать perf_event_open или что-то еще. Или используйте другую библиотеку для прямого доступа к счетчикам производительности HW.

perf stat отлично подходит для микробенчмаркинга цикла, который вы изолировали в изолированной программе, которая просто запускает горячий цикл в течение секунды или около того.

Или, может быть, вы имеете в виду что-то еще. perf stat -I 1000 ... ./a.out будет печатать значения счетчика каждые 1000 мс (1 секунда), чтобы увидеть, как поведение программы изменяется в реальном времени с любым временным интервалом, который вы хотите (с интервалами до 10 мс).

Также есть perf record --timestamp для записи метки времени с каждым образцом события. perf report -D может быть полезно вместе с этим. См. http://www.brendangregg.com/perf.html,, он упоминает что-то о -T (--timestamp). Я действительно не использовал это; Я в основном изолирую отдельные петли, которые настраиваю.


И можно ли найти тип набора инструкций (добавить, сравнить, войти, прыгать и т. Д.)?

Процессоры Intel x86, по крайней мере, имеют счетчик для команд ветвления, но другие типы не отличаются, кроме инструкций FP. Это, вероятно, характерно для большинства архитектур, у которых вообще есть счетчики производительности. Но с процессорами Intel есть ocperf.py , оболочка для perf с символическими именами для более микроархитектурных событий, поэтому вы можете

ocperf.py stat -e task_clock,cycles,instructions,fp_arith_inst_retired.128b_packed_single,fp_arith_inst_retired.scalar_double,uops_executed.x87 ./my_program

Он не предназначен для того, чтобы сообщать вам, какие инструкции выполняются, вы уже можете определить это по трассировке выполнения . Большинство инструкций полностью конвейерны, поэтому интересно, какие порты испытывают наибольшее давление. Исключение составляет единица деления / квадрат: есть счетчик для arith.divider_active: « Циклы, когда единица деления занята выполнением операций деления или квадратного корня. Учет целочисленных операций и операций с плавающей запятой ». Делитель не полностью конвейеризован, поэтому новый divps или sqrtps не всегда может запуститься, даже если ни один более старый моп не готов к выполнению на порту 0. (http://agner.org/optimize/)

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


Для точного динамического количества команд вы можете использовать инструментальные средства, такие как Intel PIN, если вы используете x86 . https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool.

На последних процессорах Intel имеется поддержка HW для записи того, как проходили условные / непрямые ветви, так что вы можете точно определить, какие инструкции выполнялись в каком порядке, при условии, что самомодифицирующегося кода не будет, и вы все равно сможете читать любые буферы JIT. Intel PT .


Извините, я не знаю, какие эквиваленты у процессоров AMD.

...