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

[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 писал(а):

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

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

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

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

[Dmitriy40]

С приоритетами под виндой не всё так красиво как хотелось бы, недавний случай из практики: две вычислительные задачи, каждая запускает ровно столько потоков сколько их есть в системе (и когда запущены по одной грузят комп на 100%), потоки сидят и считают, винду не трогают вообще (кроме вызова критических секций пару раз в секунду, т.е. сильно дольше кванта планировщика) и управления не возвращают, две задачи запускаются с приоритетами idle и normal, по идее задача normal должна забирать 99% времени, ан нет, реально получилось ровно пополам, 50% на каждую. Т.е. разница в приоритетах вообще не повлияла. Два одинаковых проца, Win10PEx64. Третью задачу запускать не стал, возможно дело в наличии двух физических (и по NUMA) процов. Или я неправильно понимаю механизм наследования приоритета дочерними потоками ...

[bondkim137]

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

С приоритетами под виндой не всё так красиво как хотелось бы

Красота - понятие субъективное =)

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

Или я неправильно понимаю механизм наследования приоритета дочерними потоками

В первом приближении (не учитывая affinity-политику и NUMA в многопроцессорных системах) работает так: там есть матрица, отображающая приоритет процесса (priority class) + приоритет потока (priority level) в скалярную величину (base priority), которая уже используется при шедулинге всех потоков.

В частности, если приоритет потока - idle, то не важно, какой приоритет процесса (кроме realtime) - время делиться будет поровну, т.к. base priority везде будет 1.

Подробно почитать можно тут

[Dmitriy40]

У меня в том случае потоки запускались без изменения приоритета (голой CreateThread), т.е. с THREAD_PRIORITY_NORMAL, так что BASE=4 для IDLE процесса и BASE=8 для NORMAL процесса. А время делилось 50%/50%.

[bondkim137]

Dmitriy40
С NUMA двухпроцессорным все сложнее, ибо по-существу это два отдельных компьютера (node) со своей локальной памятью и условно медленным механизмом доступа к памяти соседа. По умолчанию система старается минимизировать потери, в первую очередь разнося процессы по разным нодам. Это можно изменить с помощи affinity-маски (установить жестко и/или рекомендательно, на каких ядрах можно работать тому или иному процессу), перед этим узнав, к каким нодам относятся те или иные ядра. В случае Windows - GetNumaNodeProcessorMask, SetProcessAffinityMask.

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