Лучший счетчик событий для измерения времени настенных часов с помощью инструментов perf

Простой, но сложный вопрос:

Какой счетчик использовать, чтобы получить инструменты для измерения времени на настенных часах?

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

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

В настоящее время занимаюсь:

perf record -g -e ref-cycles -F 999 -- <cmd>

Я думаю, что это немасштабированная частота процессора и, следовательно, пропорциональна количеству времени настенных часов, в котором выполняется часть кода. Но кто, черт возьми, знает?


person Peter    schedule 12.02.2020    source источник
comment
Да, ref-циклы на современном ЦП тикают с постоянной частотой всегда, даже когда частота ядра остановлена. (Функция ЦП - это constant_tscnonstop_tsc, что на самом деле является одним и тем же битом функции: Как получить счетчик циклов ЦП в x86_64 из C ++?) .) Конечно, есть также программное событие task-clock, основанное на измеренном ядром процессоре. IDK, будет ли это работать хорошо или нет.   -  person Peter Cordes    schedule 12.02.2020
comment
О, но событие ref-cycles perf действительно останавливается, когда останавливаются тактовые частоты ядра. Это отдельно от фактического TSC. (Настоящее событие HW на современном Intel - это cpu_clk_unhalted.ref_tsc или cpu_clk_unhalted.ref_xclk_any). На это влияют даже остановки часов для изменения частоты процессора: Потерянные циклы на Intel? Несоответствие между rdtsc и CPU_CLK_UNHALTED.REF_TSC. И это для работы, которая не спит. Таким образом, ref-cycles подходит для поиска горячих точек ЦП, но не для общих профилей, в которых время ожидания ввода-вывода имеет значение.   -  person Peter Cordes    schedule 12.02.2020
comment
Есть ли у вас какие-либо рекомендации по измерению общей WCT? Есть ли какое-нибудь мероприятие, которое просто читает TSC? Или это вообще неправильная идея?   -  person Peter    schedule 12.02.2020
comment
В порядке. Думаю, я неправильно понял ваш комментарий. Вы сказали, что cpu_clk_unhalted.ref_tsc - это то, что я ищу, или вы сказали, что это связано с остановками?   -  person Peter    schedule 12.02.2020
comment
Мой первый комментарий был отчасти бредом, 2-й комментарий - поправка. Думаю, мне следовало удалить / репостить исправленную версию.   -  person Peter Cordes    schedule 13.02.2020


Ответы (1)


Вы можете использовать task-clock.

Это явное время настенных часов во время выполнения процесса, и в качестве бонуса переносимо, потому что оно не зависит от каких-либо событий PMU.

person BeeOnRope    schedule 12.02.2020
comment
Знаете ли вы какой-нибудь авторитетный источник этого утверждения, потому что быстрый поиск в Интернете приводит к множеству спекулятивных и частично противоречивых заявлений о том, что это такое. - person Peter; 12.02.2020
comment
@Peter - Я не думаю, что есть какие-либо сомнения в том, что часы задач - это настенные часы (на поток). Он также присутствует в списке событий по умолчанию и используется для расчета производных показателей, таких как МГц, поэтому вы можете быть уверены, что он работает нормально (в отличие от, скажем, cpu-clock). Если вам нужны исчерпывающие доказательства, вам, вероятно, придется взглянуть на источник. - person BeeOnRope; 12.02.2020