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

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

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

[![]()](/imgs/8mJW0.png)

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

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

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

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

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

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

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

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



ОП говорит, что использует Windows 7, если это MSVC[справочная страница](https://msdn.microsoft.com/en-us/library/4e2ess30.aspx) говорит

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

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



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

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

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

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

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

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

Современные процессоры имеют много эвристик, которые влияют на производительность. Например, предсказатель ветвления угадывает, какую ветвь вы выберете для перехода, основываясь на прошлом «опыте». Ваша производительность сильно зависит от того, правильно ли это предположение или нет, как подробно описано в этом[эпический ответ](https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-an-unsorted-array/11227902#11227902), Есть и другие компоненты, такие как, например, prefetchers.

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

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