Должно ли время процессора показывать одинаковое время между прогонами?

У меня есть большой проект, написанный на C ++. Это может иметь некоторые проблемы со стабильностью (то есть случайное время выполнения), но я не уверен в этом. Я понимаю, что время выполнения, измеряемое временем настенных часов, может отличаться для разных запусков из-за многозадачности ОС. Но я не знаю, нормально ли для стабильной программы иметь различное время выполнения, измеряемое временем процессора, среди прогонов с одним и тем же вводом. Я пытался использоватьclock() от time.h, и

boost::chrono:::process_user_cpu_clock::now();

Но в обоих случаях я вижу шипы на графике. Я приведу вам пример таких графиков. Здесь ось Y - время выполнения, ось X - последовательные запуски одной и той же программы на одних и тех же входных данных. Красный график - время настенных часов, красный - время процессора, взятое clock () из time.h

Конечно, мы предполагаем, что наша программа стабильна и не имеет случайного поведения. Так возможно ли это? Платформа Windows 7.

 Ibraim Ganiev25 мая 2016 г., 20:41
@NathanOliver, да, X - это каждый прогон.
 Ibraim Ganiev25 мая 2016 г., 20:42
@ user4581301, я знаю о многозадачности :), я только что спросил, нормально ли время процессора, чтобы быть таким случайным? Кроме того, если вы знаете какое-либо программное обеспечение, которое может помочь в обнаружении таких проблем (случайное время выполнения) - дайте мне советы.
 NathanOliver25 мая 2016 г., 20:14
@sleeptightpupper Ось у в секундах. Это говорит о том, что в ключе. Я просто предполагаю, что х каждый прогон.
 Andrew Komiagin25 мая 2016 г., 20:16
Проверять, выписыватьсяstackoverflow.com/questions/17432502/...
 Ibraim Ganiev25 мая 2016 г., 20:41
@WeatherVane, Windows 7.
 Weather Vane25 мая 2016 г., 20:09
Какая платформа? Linuxclock() время процессора, Windowsclock() AFAIK время настенные часы.
 uh oh somebody needs a pupper25 мая 2016 г., 20:13
График бесполезен без единиц измерения, помеченных осей, масштаба и т. Д. Вы действительно беспокоитесь о разнице в минутах (например, в диапазоне от 1,21 до 1,33, скажем, в миллисекундах)?
 Ibraim Ganiev25 мая 2016 г., 20:41
@sleeptightpupper, единицы измерения - это секунды, но этот график действительно нехорош, я просто не могу найти хороший пример, для расчета которого потребуется больше времени.
 user458130125 мая 2016 г., 20:15
Десятая доли секунды - это арахис. ОС, готовая сделать что-то более важное, чем выполнение кода, может внедрить всевозможные забавные артефакты, которые замедляют вас на более чем 100 мс. Рекомендую запускать вашу программу через некоторое реальное программное обеспечение для профилирования.

Ответы на вопрос(3)

ОП говорит, что использует Windows 7, если это MSVCсправочная страница говорит

Функция часов сообщает, сколько часов настенного времени использовал вызывающий процесс. Обратите внимание, что это не совсем соответствует стандарту ISO C99, в котором в качестве возвращаемого значения указывается чистое время ЦП. Чтобы получить процессорное время, используйте функцию Win32 GetProcessTimes.

Вот почему кажущееся время выполнения противоречиво.

 Ibraim Ganiev25 мая 2016 г., 20:52
Хм, спасибо за ваш ответ, на самом деле я тоже использовал GetProcessTimes, но он дал мне почти тот же результат. В любом случае, спасибо.
 chux25 мая 2016 г., 22:16
Хорошая цитата, чтобы объяснить вещи

Это абсолютно нормально. Есть много эффектов, которые вызывают это. На самом деле повторяемость для экспериментов по производительности очень трудно достичь.

Кэш-память

Любая производительность с использованием памяти сильно зависит от того, используется ли кэш или нет:

Операционная система планирует другой поток в вашем ядре? Даже если время в этом потоке не учитывает ваши часы процесса, оно может вытеснить ваши рабочие данные из кэша, и ваша программа впоследствии будет работать медленнее.

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

Операционная система решает запустить другой поток, интенсивно использующий память, параллельно (на другом ядре)? Ваше приложение имеет меньший общий кэш и доступную пропускную способность памяти.

аппаратные средства

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

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

Точность часов

Часы тоже не идеальны. Они имеют ограниченное разрешение и точность. Они могут дрейфовать со временем - или различаться между ядрами. Как указывает Weather Vane, программное обеспечение на верхней части часов также может быть неправильным.

Это далеко не полный список, только некоторые примеры.

Решение Вопроса

Конечно, мы предполагаем, что наша программа стабильна и не имеет случайного поведения. Так возможно ли это?

Если ваша программа работает на рабочем столе, эта изменчивость типична, и я бы сказал, что она неизбежна. Прерывания, активность каналов ввода-вывода и сам Ethernet потребляют процессорное время, часто с удивительно большими «блоками времени» (см. Tcp / ip SAR, пропуски кэша и т. Д.), Большинство из которых находится вне контроля вашей программы и не находится в Синхронизировать с вашими сроками.

Я видел только один пример программного обеспечения, работающего в «стабильном» режиме, на который вы намекаете. Этот компьютер представлял собой SBC (одноплатный компьютер) с 1 процессором (не Intel или AMD), со всеми статическими оперативными памятьми (т.е. без динамического оперативного памяти и без операций обновления), без Ethernet, но с двумя каналами ввода-вывода с фиксированной скоростью, и он запускал одну программу в уменьшенной операционной системе (не Linux, не настольная ОС) ... точность была такой, как если бы поведение было простой hw-логикой.

Будучи руководителем группы, я узнал необычное, поэтому я спросил ее, есть ли у нее время, чтобы подключить логический анализатор и область действия ... она продемонстрировала, что ни один из инструментов не демонстрирует никакой разницы во времени, от края до края, от сообщения к сообщению. Ее программная логика была для меня впечатляюще простой. В этой системе, если вам не нужно прерывание, вы просто не включаете его.

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

Да. Не только возможно, но и неизбежно, что у рабочего стола есть разновидности (по времени), которые вы видите.

И все же можно добиться стабильности, на которую вы намекали, только не на рабочем столе. Требуется специальное оборудование и тщательное кодирование.

Ваш ответ на вопрос