Реальное время выполнения кода

Проще всего и правильнее так: https://github.com/google/benchmark

Но надо понимать, что из-за всяких кешей, мнопоточностей и LTO результат с точки зрения реального мира будет почти бесполезен.

Или вопрос на самом деле про профайлинг?

callgrind позволит измерить это в тактах некоего процессора, который он эмулирует.

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

Думаю steady_clock реализованы именно так.

Во многих случаях может хватить high_resolution_clock, особенно если замешано i/o.

callgrind считает колиество выполненных инструкций, а не такты

Если только лишь замерить время выполнения функции, то rdtsc(). Если это бенчмарк, то https://github.com/david-grs/geiger основанный на perf.

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

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

callgrind позволит измерить это в тактах некоего процессора, который он эмулирует.

Скорее всего это не имеет никакого отношения к работе реального процессора, а потому на практике малополезно. Например, обращение к регистру занимает 1 такт, кеш L1 - 4 такта, L2 - 8-12, L3 ~40, в память 80-120 тактов, обращение к соседней NUMA ноде еще больше, а если сокетов 4 штуки и обращение через одну ноду... Таким образом, время чтения данных сильно зависит, лежат ли они в кеше и в каком.

а что Вы скажете насчёт Celero? Годный для тестинга?

Честно говоря, не пробовал. По описанию — примерно то же самое, что у гугла, может пофункциональнее.

Какая-то утилита из валгринда умела эмулировать работу кеша.