Измерение времени выполнения выбранных циклов

Question

Я хочу измерить время работы выбранных циклов в программе на C, чтобы узнать, какой процент от общего времени выполнения программы (в Linux) проводится в этих циклах. Я должен быть в состоянии указать циклы, для которых должна быть измерена производительность. За последние несколько дней я опробовал несколько инструментов (vtune, hpctoolkit, oprofile), и никто из них, похоже, не делает этого. Они все находят узкие места в производительности и просто показывают время для них. Это потому, что эти инструменты сохраняют только время, превышающее порог (~ 1 мс). Поэтому, если один цикл занимает меньше времени, то время его выполнения не будет сообщено.

Основная функция подсчета блоков gprof зависит от функции в старых компиляторах, которая не поддерживается сейчас.

Я мог бы написать простой таймер с помощью gettimeofday или что-то в этом роде, но в некоторых случаях он не даст точных результатов. Для экс:

for (i = 0; i < 1000; ++i) 
{ 
    for (j = 0; j < N; ++j) 
    { 
     //do some work here 
    } 
} 

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

Answer 1

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

Любые инструкции по профилированию несут собственные накладные расходы, но, по-видимому, накладные расходы будут одинаковыми независимо от того, где они вставлены, так что «все это выходит в стирку». Предположительно, вы ищете места, где есть значительные различия между циклами двух сравниваемых процессов, где пара вызовов функций, подобных этому, не будет проблемой (так как вам тоже нужен «конец», чтобы получить время delta), поскольку одна процедура будет 2x или более дорогостоящей над другой.

Большинство платформ предлагают какой-то таймер с более высоким разрешением, хотя тот, который мы используем здесь, скрыт за API, так что «клиентский» код является кросс-платформенным. Я уверен, что с небольшим количеством взглядов вы можете это сделать. Хотя даже здесь маловероятно, что вы получите более точную точность, чем 1 мс, поэтому рекомендуется запускать код несколько раз подряд и в течение всего прогона (затем делиться на число циклов, набрать).

Answer 2

Если у вас нет встроенного эмулятора или выпадающего блока вокруг вашего процессора, нет такой вещи, как синхронизация одноточечной или однонаправленной. Вам необходимо объединить свои тестовые прогоны к чему-то, что занимает не менее нескольких секунд, чтобы уменьшить ошибку из-за других вещей, происходящих в CPU, ОС и т. Д.

Если вы хотите узнать, как именно много времени, которое требуется выполнить конкретному циклу для выполнения, и требуется меньше, чем, скажем, 1 секунда для выполнения, вам потребуется искусственно увеличить количество итераций, чтобы получить число, которое находится выше «уровня шума». Затем вы можете взять это число и разделить его на количество искусственно завышенных итераций, чтобы получить цифру, которая показывает, сколько времени пройдет через ваш целевой цикл.

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

Это правда, независимо от того, измеряете ли вы производительность, используя подсмитные высокопроизводительные счетчики, предоставленные ЦП, системные часы даты или настенные часы для измерения прошедшего времени вашего теста.

В противном случае вы просто измеряете белый шум.

Answer 3

Я рад, что вы ищете процент, потому что это легко получить. Просто попробуй. Если он работает быстро, поместите внешний цикл вокруг него, чтобы он занимал много времени. Это не повлияет на проценты. Пока он работает, получите stackshots. Вы можете сделать это с помощью Ctrl-Break в gdb, или вы можете использовать pstack или lsstack. Посмотрите, какой процент стеков показывает код, который вам нужен.

Предположим, что петли занимают некоторую долю времени, например 0,2 (20%), и вы берете N = 20 образцов. Тогда количество образцов, которые должны отображать их, будет в среднем 20 * 0,2 = 4, а стандартное отклонение количества образцов будет sqrt (20 * 0,2 * 0,8) = sqrt (3,2) = 1,8, поэтому, если вы хотите получить больше точности , возьмите больше образцов. (Я лично думаю, что точность переоценена.)