^{Мужик приходит устраиваться работать на стройку. Его спрашивает мастер:
— Что делать умеешь?
— Могу копать…
— А что еще?
— Могу не копать…}

Не секрет, что современные процессоры работают очень быстро. Работа их заключается в постоянном извлечении из памяти инструкций и выполнения предписанных в них действий. Однако оказывается, по тем или иным причинам часто требуется притормозить этот процесс. В прикладных программах редко приходится задумываться о том, что при этом происходит с процессором. Но вот для создателей системного софта это далеко не праздный вопрос.

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

В статье фокус делается на программной стороне вопроса состояний процессора. Я не буду концентрироваться на деталях реализации (напряжения, пины, частоты и т.д.), так как 1) они существенно различаются между поколениями и моделями процессоров даже одной архитектуры, тогда как программный интерфейс остаётся обратно совместимым; 2) они не видны напрямую программам и ОС. Это попытка просуммировать информацию, разбросанную по многим страницам справочника Intel IA-32 and Intel 64 Software Developer Manual.

Начнём с простой и всем знакомой ситуации — процессор включён, бодр и весел.

1. целевая функция является статической – она сразу присутствует в памяти загруженного модуля;
   
2. адрес целевой функции легко определить (через таблицу экспорта модуля или функцию GetProcAddress).
   

Пользовательский интерфейс должен быть быстрым, очень быстрым, невероятно быстрым.

КДПВ

От переводчика:
Большинство моих знакомых для измерения времени в разного вида бенчмарках в С++ используют chrono или, в особо запущенных случаях, ctime. Но для бенчмаркинга гораздо полезнее замерять процессорное время. Недавно я наткнулся на статью о кроссплатформенном замере процессорного времени и решил поделиться ею тут, возможно несколько увеличив качество местных бенчмарков.

P.S. Когда в статье написано "сегодня" или "сейчас", имеется ввиду "на момент выхода статьи", то есть, если я не ошибаюсь, март 2012. Ни я, ни автор не гарантируем, что это до сих пор так.
P.P.S. На момент публикации оригинал недоступен, но хранится в кэше Яндекса

Функции API, позволяющие получить процессорное время, использованное процессом, отличаются в разных операционных системах: Windows, Linux, OSX, BSD, Solaris, а также прочих UNIX-подобных ОС. Эта статья предоставляет кросс-платформенную функцию, получающую процессорное время процесса и объясняет, какие функции поддерживает каждая ОС.

Результат и выводы для тех кто не любит длинный текст

Min:	1 ms
Max:	1 ms
Mean:	1 ms
Median:	1 ms
Abs: 1

Min:	1 ms
Max:	1 ms
Mean:	1 ms
Median:	1 ms
Abs: 1

Min:	7 ms
Max:	8 ms
Mean:	7,5 ms
Median:	7,5 ms
Abs: 1

Min:	5 ms
Max:	6 ms
Mean:	5,2 ms
Median:	5 ms
Abs: 1

Min:	32 ms
Max:	36 ms
Mean:	32,75 ms
Median:	32,5 ms
Rel: 32

Min:	35 ms
Max:	44 ms
Mean:	36,5 ms
Median:	36 ms
Rel: 36

Min:	333 ms
Max:	399 ms
Mean:	345,5 ms
Median:	338 ms
Rel: 45

Min:	362 ms
Max:	385 ms
Mean:	373,6 ms
Median:	376 ms
Rel: 75

Min:	64 ms
Max:	71 ms
Mean:	65,05 ms
Median:	64,5 ms
Rel: 64

Min:	72 ms
Max:	86 ms
Mean:	75,95 ms
Median:	75 ms
Rel: 75

Min:	659 ms
Max:	730 ms
Mean:	688,8 ms
Median:	689,5 ms
Rel: 92

Min:	746 ms
Max:	869 ms
Mean:	773,4 ms
Median:	765 ms
Rel: 153

Min:	16 ms
Max:	18 ms
Mean:	16,2 ms
Median:	16 ms
Rel: 16

Min:	21 ms
Max:	25 ms
Mean:	22,15 ms
Median:	22 ms
Rel: 22

Min:	168 ms
Max:	187 ms
Mean:	172,8 ms
Median:	170,5 ms
Rel: 22.7

Min:	218 ms
Max:	245 ms
Mean:	228,8 ms
Median:	227 ms
Rel: 45.4

Min:	11 ms
Max:	14 ms
Mean:	11,5 ms
Median:	11 ms
Rel: 11

Min:	12 ms
Max:	14 ms
Mean:	12,5 ms
Median:	12 ms
Rel: 12

Min:	124 ms
Max:	147 ms
Mean:	132,1 ms
Median:	130 ms
Rel: 17

Min:	127 ms
Max:	144 ms
Mean:	131,5 ms
Median:	129,5 ms
Rel: 26

Min:	4 ms
Max:	4 ms
Mean:	4 ms
Median:	4 ms
Rel: 4

Min:	4 ms
Max:	5 ms
Mean:	4,15 ms
Median:	4 ms
Rel: 4

Min:	46 ms
Max:	55 ms
Mean:	50 ms
Median:	50,5 ms
Rel: 6.7

Min:	47 ms
Max:	51 ms
Mean:	47,7 ms
Median:	47 ms
Rel: 9.4

# Создание набора данных
col1 <- runif (12^5, 0, 2)
col2 <- rnorm (12^5, 0, 2)
col3 <- rpois (12^5, 3)
col4 <- rchisq (12^5, 2)
df <- data.frame (col1, col2, col3, col4)

Тестирование и анализ производительности — тема, которую хотелось бы обсуждать побольше. Мы начинаем публикацию перевода руководства от небезызвестной команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод — спасибо Игорю Щегловитову из Лаборатории Касперского, нашему бессменному автору материалов про тестирование. Остальные наши статьи по теме тестирования можно найти по тегу mstesting