Нестабильное времени выполнения кода

[Missir]

В начале программы есть небольшой участок кода, время выполнения которого весьма нестабильно. Чаще всего он выполняется за 1,5 мс, но иногда бывает что за 0,3 мс. Если повторить этот начальный фрагмент в цикле несколько тыс. раз, то среднее время выполнения получается около 0,3 мс. Время выполнения определяется с помощью clock_gettime(CLOCK_MONOTONIC_RAW), и оно примерно совпадает с результатами измерения другими функциями, например clock().
Есть ещё одна особенность, если запустить программы в режиме сбора статистики Oracle Development Studio, то интересующий фрагмент всегда выполняется за 0,3мс. Хотя, сборщик статистики должен замедлять, а не ускорять выполнение кода.
Такое впечатление, что в начале выполнения программы, в течение 1мс, что то происходит, и это не связано с самой программой.
Что это может быть?

[Sender]

Если речь не об ОС реального времени, это может быть всё что угодно.

[Missir]

Sender
можно это как то стабилизировать? например установить приоритет выполнения?

[Dmitriy40]

Missir
А зачем? Почему Вас волнует однократная (не в цикле) задержка на 1мс?

[Missir]

Dmitriy40 я оптимизирую этот участок кода и нужно знать что тормозит, код или система
в общем сделал $ sudo nice -n -20 ./example
время выполнения стало 0,25 мс. Причём, после этого оно остаётся таким и при запуске в обычном режиме, но потом снова становится 1,5мс. Надо полагать всё дело в приоритете выполнения

-- 07.09.2024, 16:28 --

да, точно, похоже всё из-за этого

[Dmitriy40]

Ну, я могу придумать ситуацию (правда под винду, не уверен что прокатит и под линуксом) когда никакой приоритет не спасёт от тормозов. Тезисно: инициализация стека (локальных переменных) из свопа. Запуск в ОС без свопа и с рам диска спасёт, но могу придумать когда и это не поможет.

Так что если оптимизируете по скорости, то допустимо брать меньшее время из серии идентичных запусков. Остальное будет на совести ОС.

[Missir]

Dmitriy40 в сообщении #1653663 писал(а):

допустимо брать меньшее время из серии идентичных запусков

по идее да, но были определённые сомнения, хотелось разобраться

[bondkim137]

Dmitriy40 в сообщении #1653663 писал(а):

правда под винду, не уверен что прокатит и под линуксом

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

[Missir]

bondkim137 в сообщении #1658386 писал(а):

Приоритет никак на это не влияет, запретить системе прерывать поток невозможно

и тем не менее, при запуске с высоким приоритетом, программа работает стабильно

[bondkim137]

Missir в сообщении #1658603 писал(а):

и тем не менее, при запуске с высоким приоритетом, программа работает стабильно

При запуске с высоким приоритетом просто реже происходит перехват кванта времени, если конкурентные потоки/процессы работают с более низким приоритетом. Потому искажаются результаты ваших опытов. Приоритет влияет на вероятность, но принципиально никак не исключает возможность получить спонтанную задержку.

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

А низкоприоритетные конкурентные жадные процессы/потоки всегда будут отъедать у вас целый квант (~миллисекунды). Просто это будет случаться реже, из-за разницы в приоритетах. Под жадными потоками я имею в виду те, которые добровольно не возвращают управление системе в короткое время (меньше кванта).