Инструкции по профилированию

Вы можете использовать Valgrind Callgrind с флагом --dump-instr=yes для достижения этой цели

Это общий совет, а не специфичный для Linux: вместо этого вас должны интересовать циклы процессора. Забудьте о количестве инструкций как о показателе производительности. Одна инструкция может стоить столько же, сколько остальные 10 вместе, так что она вам ни о чем не скажет.

Вы должны сосредоточиться на циклах ЦП и в многопоточных средах (в большинстве, если не во всех сегодняшних) на времени перевода потока в спящий режим («переключается/выключается»), что даст вам представление о том, сколько времени ожидает I/ O, DB и т. д. для завершения, и это влияет на привилегированное время ЦП.

Если вам действительно нужно подсчитывать инструкции, то вам, вероятно, лучше всего сгенерировать ассемблер, а затем передать вывод интеллектуальному эквиваленту grep. Для gcc попробуйте переключатель -S.

Intels vtune бесплатна для пользователей Linux, AFAIK (при условии, что мы говорим о Linux-машине на базе Intel x86). Это даст вам всю необходимую информацию и НАМНОГО больше.

Вы можете использовать pin-instat, который является PIN. Чтобы использовать его, вам нужно установить PIN-код. Однако само по себе количество инструкций мало что говорит о производительности. Промах кеша, предсказание ветвления также играют большую роль.

Отказ от ответственности: я автор pin-instat.

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

Я знаю, что во времена «простых» процессоров можно было разумно предположить, что каждый код операции будет выполняться ровно столько-то наносекунд процессорного времени, но в наши дни со всеми сложными схемами кэширования памяти, на- переупорядочивание кода операции fly, конвейерная обработка, суперскалярная архитектура и все остальное, что было добавлено в современный ЦП, дает ли простой подсчет выполнения кода операции хорошее представление о том, сколько времени потребуется для выполнения кода? Или время выполнения будет зависеть от (например) шаблонов доступа к памяти и последовательности, в которой выполняются коды операций, а также от исходной частоты выполнения кодов операций?

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