У меня есть 2 приложения, которые используют много системных ресурсов. Когда я уменьшаю приоритет одного в диспетчере задач, одновременно увеличивая другой, я не замечаю какого-либо значительного улучшения скорости в приложении с более высоким приоритетом.
Почему это? Происходит ли что-то еще или что еще нужно сделать?
Приоритет не помогает, когда узким местом является сам процессор. Что на самом деле делает приоритет, так это влияет на алгоритм планирования , который операционная система использует для определения того, какой процесс запускается следующим, поскольку в большинстве систем недостаточно процессоров для непрерывной работы каждого процесса.
Задача с более высоким приоритетом будет быстрее достигать вершины очереди, так что это помогает с общей задержкой, но если ваш процесс исчерпывает весь временной интервал, который он выделяет при фактических вычислениях, тогда планирование ничего не изменит там. Изменение приоритета более полезно, когда у вас есть процесс, ожидающий ввода-вывода, и вы хотите, чтобы он был более отзывчивым.
Приоритет - процессорное время. Все ли ядра используются на 100% все время? Если нет, то приоритет не будет иметь никакого эффекта. Довольно часто ЦП - это не узкое место, а ресурсы памяти, диска или графического процессора.
Приоритет имеет значение только в том случае, если потоков больше, чем доступных ядер ЦП. Когда это происходит, приоритет определяет, какие потоки запускаются. В большинстве систем не хватает вычислений для любого конфликта на CPU: все потоки заблокированы, ожидая, что что-то произойдет. Возможно, вам придется что-то набрать, переместить мышь, коснуться экрана или получить данные, поступающие с диска, из сети, с другого подключенного устройства или до завершения работы другого потока с критически важными данными. состав. Возможно, что часть программы будет ждать чтения с диска или некоторой памяти, которая была выгружена для повторного чтения, а не явно читать файл.
В Windows планировщик поддерживает очередь запускаемых потоков на каждом уровне приоритета. Когда он принимает решение о планировании - либо то, что поток исчерпал свой квант (разрешенное время, прежде чем что-то еще должно быть запущено), это означает, что другой поток должен получить ход, либо поток заблокирован и больше не работает, либо имеет более высокий приоритет поток стал разблокированным - будет запланирован следующий поток в очереди с верхним уровнем приоритета со всеми работающими потоками. Если запущенный поток использовал свой квант, он помещается в конец очереди. Если это единственный поток на своем уровне приоритета, который является работоспособным, и нет других потоков с более высоким приоритетом, но не работающих, он получит другой ход.
В многоядерных / многопроцессорных системах могут быть ограничения, на каких ядрах может работать поток. Кроме того, система пытается сохранить потоки на своем идеальном ядре и в своем узле NUMA, чтобы данные потока, вероятно, все еще находились в кэше этого ядра, и у них был быстрый доступ к созданным им данным. Потоки по-прежнему будут работать на неидеальных ядрах, если нет выбора, что делать дальше.
Система использует различные динамические повышения приоритета и динамические квантовые размеры, так что приложение переднего плана получает больше времени (если оно ему необходимо), чем фоновые процессы, и поэтому процессы могут быстро реагировать, когда завершаются операции ввода-вывода (включая мышь, клавиатуру и сенсорный ввод). Кроме того, повышение приоритета используется для обхода инверсий приоритетов, когда поток с высоким приоритетом ожидает ресурс, который в настоящее время содержит поток с низким приоритетом. Если также работает поток со средним приоритетом, он истощит поток с низким приоритетом процессорного времени, удерживая поток с высоким приоритетом. Таким образом, поток с низким приоритетом временно повышается до более высокого приоритета, поэтому он получает время и, как мы надеемся, освобождает ресурс, необходимый потоку с высоким приоритетом.
До Windows Vista приоритет потока не влиял на скорость выполнения операций ввода-вывода. Начиная с Windows Vista, операции ввода-вывода также могут иметь приоритет, который по умолчанию исходит из приоритета потока.
Резюме: вы в значительной степени не увидите никакого эффекта от изменения приоритетов потоков, если ваш ЦП не сильно загружен, и даже в этом случае эффект, как правило, будет минимальным. Если процесс должен ждать ввода-вывода или он не конкурирует с другими процессами в течение процессорного времени, он уже работает максимально быстро, и изменение приоритета не сделает его быстрее.
В общем случае требуется приложить дополнительные усилия, чтобы программа использовала более одного процессора (добавив многопоточность). Таким образом, даже если программа имеет самый высокий доступный приоритет, она может использовать только одно ядро.
Другие возможные проблемы:
Даже повышение приоритета ввода / вывода для процесса, связанного с вводом / выводом, не обязательно заставит его работать быстрее. Например, если он является потребителем данных, созданных отдельным, возможно, удаленным, процессом, и он соответствует скорости, с которой этот источник создает данные, он не может работать быстрее или иметь более высокую пропускную способность.
В отличие от того, что категорически указано в первом предложении принятого в настоящее время ответа (https://superuser.com/a/752587/322588), изменения приоритетов наиболее эффективны, когда ЦП является узким местом, как объяснено в ответе Майка Диммика. (https://superuser.com/a/752864/322588). Более того, утверждение во втором абзаце принятого ответа:«если ваш процесс исчерпывает весь временной интервал, который он выделяет при фактических вычислениях, тогда планирование не собирается ничего там менять», совершенно неверно, если процесс обычно уже не имеет наивысшего приоритета из всех запускаемые потоки всякий раз, когда он ожидает запуска. Это связано с тем, что при любых других обстоятельствах повышение приоритета может привести к увеличению количества временных интервалов за интервал настенных часов.
Майк Диммик указал на проблемы с этим ответом пару дней назад и дал гораздо лучший ответ, но первый необъяснимым образом продолжает набирать голоса. Заявление его автора о том, что он просто обдумывает свой ответ для нас, чайников, не правдоподобно, поскольку оно не просто или даже упрощенно, оно совершенно неверно, по крайней мере, в отношении процессов, связанных с процессором.
Отказ от ответственности: я не знаю мистера Диммика, хотя могу сказать, что он знает, о чем пишет.
