Почему приоритезация процессов не приводит к улучшению скорости?

18

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

Почему это? Происходит ли что-то еще или что еще нужно сделать?

Моисей
источник
6
Это как в реальной жизни. Если у вас более высокий приоритет для посадки на самолет, чем у другого пассажира, это не значит, что полет займет у вас меньше времени!
Мердад

Ответы:

28

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

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

Андон М. Коулман
источник
5
Приоритет помогает, когда узким местом является слишком много работающих потоков. Потоки с более высоким приоритетом в Windows, которые остаются работоспособными в конце своего временного интервала, получат еще один шанс запустить в предпочтении поток с более низким приоритетом (Windows старается не истощать потоки с низким приоритетом и иногда повышает их). Приоритет мало влияет на потоки, ожидающие ввода-вывода - Windows временно повышает приоритет потока после завершения ввода-вывода, в зависимости от типа ввода-вывода, на котором он ожидал.
Майк Диммик
4

Приоритет - процессорное время. Все ли ядра используются на 100% все время? Если нет, то приоритет не будет иметь никакого эффекта. Довольно часто ЦП - это не узкое место, а ресурсы памяти, диска или графического процессора.

Джейсон
источник
3

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

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

В многоядерных / многопроцессорных системах могут быть ограничения, на каких ядрах может работать поток. Кроме того, система пытается сохранить потоки на своем идеальном ядре и в своем узле NUMA, чтобы данные потока, вероятно, все еще находились в кэше этого ядра, и у них был быстрый доступ к данным, которые он создал. Потоки по-прежнему будут работать на неидеальных ядрах, если нет выбора, что делать дальше.

Система использует различные динамические повышения приоритета и динамические квантовые размеры, так что приложение переднего плана получает больше времени (если оно ему требуется), чем фоновые процессы, и поэтому процессы могут быстро реагировать, когда завершаются операции ввода-вывода (включая мышь, клавиатуру и сенсорный ввод). Кроме того, повышение приоритета используется для обхода инверсий приоритетов, когда поток с высоким приоритетом ожидает ресурс, который в настоящее время содержит поток с низким приоритетом. Если также запущен поток со средним приоритетом, он истощит поток с низким приоритетом процессорного времени, удерживая поток с высоким приоритетом. Таким образом, поток с низким приоритетом временно повышается до более высокого приоритета, поэтому он получает время и, как мы надеемся, высвобождает ресурс, необходимый потоку с высоким приоритетом.

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

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

Майк Диммик
источник
0

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

Другие возможные проблемы:

  • Программа может быть неэффективной / плохо написана
  • Это может быть замедлено из-за «медленного» доступа к диску или медленной сети
Джон Онстотт
источник
0

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

В отличие от того, что категорически указано в первом предложении принятого в настоящее время ответа ( /superuser//a/752587/322588 ), изменения приоритетов наиболее эффективны, когда ЦП является узким местом, как объясняется в ответе Майка Диммика. ( /superuser//a/752864/322588 ). Кроме того, утверждение во втором абзаце принятого ответа: «если ваш процесс исчерпывает весь временной интервал, который он выделяет при фактических вычислениях, тогда планирование не собирается ничего там менять», совершенно неверно, если процесс обычно уже не имеет наивысшего приоритета из всех запускаемые потоки всякий раз, когда он ожидает запуска. Это связано с тем, что при любых других обстоятельствах повышение приоритета может привести к увеличению количества временных интервалов за интервал настенных часов.

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

Отказ от ответственности: я не знаю мистера Диммика, хотя могу сказать, что он знает, о чем пишет.

sdenham
источник
Возможно, вы неправильно поняли; вопрос был о процессах, бегущих быстрее. Процессы, связанные с процессором, исчерпают весь свой блок планирования (квант) и в конце переходят в очередь готовых процессов. В настольной операционной системе, такой как Windows, это означает, что процесс имеет шансы 1 / квант-Гц запускаться каждую секунду. Изменение приоритета (как правило) не меняет длину временных интервалов. Для завершения всегда требуется одинаковое количество квантов планирования. Важно отметить , что именно так Windows фактически измеряет время выполнения процесса: количество запланированных квантов.
Андон М. Коулман
Процесс может закончить раньше, но он все еще бежал за такое же количество единиц планирования. Когда процесс, связанный с вводом / выводом, помещает себя в список ожидания, он может получить второй шанс для запуска и выгрузить запущенный процесс с более низким приоритетом, прежде чем его квант истечет, если его операция ввода / вывода завершится. Связанные с процессором процессы не имеют такой свободы, они исчерпывают весь свой временной интервал и затем переходят в готовую очередь. Это является возможным для них работать сразу же после этого , если они имеют достаточно высокий приоритет, но это не имеет ничего общего с тем, как Windows , измеряет время выполнения.
Андон М. Коулман
Приоритет ожидающего процесса ввода-вывода существенно отличается, и он может оказать ощутимое влияние на заявленное время выполнения в Windows. Опять же, Windows измеряет время выполнения как количество квантов, срок действия которых истек (даже если процесс тратит 1 мс из фактически запущенного кванта 10 мс, а затем добровольно ожидает оставшиеся 9 мс для операций ввода-вывода, ядро ​​Windows считает, что это значение составляет 10 мс пользовательского режима выполнения). Вытеснение может помочь приложениям, связанным с вводом / выводом, потребовать меньше квантов для завершения. Другие ядра (например, Linux) могут правильно измерять частичные кванты во время выполнения процесса, но Windows не может.
Андон М. Коулман
@ AndonM.Coleman Начиная с Vista и позже, да, может и делает.
Джейми Ханрахан
@JamieHanrahan: Ну, вы всегда можете позвонить timeBeginPeriod (...), что-нибудь интерактивное уже делает. Игра обычно устанавливает это значение равным 1, когда оно запускается, и это применяет интервал планирования 1 мс по всей доске ко всему, что работает в системе. Он не изолирован только для процесса, который это сделал. Это одна из причин, по которой сложно воспринимать Windows всерьез для многозадачности.
Андон М. Коулман