Использование ЦП процесса не изменяется для другого приоритета

626
TheGoodUser

Я написал бесконечный цикл в Python для печати Нет! на выходе.

while True: print("No!") 

Когда я выполняю его, я вижу его процесс (pythonw.exe) в Windows-Task-Manager, который использует 60% ЦП. Я щелкнул правой кнопкой мыши по его процессу и изменил приоритет на Низкий . он снова использует 60% процессора! Затем я меняю приоритет на Real-Time . Это все еще использует 60% центрального процессора!

Обновление: мое общее использование процессора для всего процесса составляет 80% !!! и 20% бесплатно! Почему этот цикл Python не использует эти 20% ?!

Что не так с приоритетом? Почему это не меняется?

0
Поскольку инструкции x86, необходимые для этого, не занимают более 60% одного такта Ramhound 9 лет назад 1
Не могли бы вы объяснить это более ясно, как ответ? Почему эти инструкции не занимают более 60% одного такта в x86? это отличается в x64? TheGoodUser 9 лет назад 0
X64 - это расширение архитектуры x86, какая часть, вы точно не понимаете Ramhound 9 лет назад 0
@Ramhound 1- ** x86 инструкции, необходимые для этого, не занимают более 60% одного такта. ** Почему ?! ** И ** 2- Почему, когда я устанавливаю его приоритет на _Low_, он все еще использует 60%? Почему это не уменьшает? TheGoodUser 9 лет назад 0
Поскольку дельта загрузки, вызванная этим сценарием, и загрузка без сценария, процессор не должен расставлять приоритеты потоков. Что касается другой части, если вы не знаете сборку x86, любые дополнительные детали не будут полезны Ramhound 9 лет назад 0
@Ramhound Не могли бы вы попробовать меня! Я немного знаю сборку: D, может, она мне пригодится! TheGoodUser 9 лет назад 0
Не стесняйтесь скрыть это для сборки, чем понимать, что на самом деле происходит Ramhound 9 лет назад 0

1 ответ на вопрос

2
AFH

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

В вашем случае процесс Python - это единственный процесс, требующий много процессорного времени, поэтому он получит все, о чем просит. Если бы ваша система была иначе занята, то вы бы увидели, что ваш 60% -ный спад намного больше, чем если бы он имел обычный приоритет.

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

:Loop dir /s c:\ goto Loop 

Тогда вы увидите последствия изменения приоритета вашего конкурирующего процесса. Обратите внимание, что требования к ЦП в этом примере будут различаться, в зависимости от скорости ЦП, количества файлов c:\и размеров дискового кэша; перенаправление dirвывода на >nul:увеличит нагрузку на процессор.

эта программа пакетного файла использует только 3 процента! и снова это не изменится, даже если я изменю его приоритет! для этой программы на Python загрузка процессора зафиксирована на 60%, а общая загрузка процессора составляет 80%! Я имею в виду, мой процессор имеет 20% бесплатно! TheGoodUser 9 лет назад 0
Вы не можете заставить программу тратить больше времени за такт, чем нужно Ramhound 9 лет назад 0
@ TheGoodUser-Sp - я не хотел делать это _too_ интенсивным, но если вы перенаправите вывод, как в `dir / sc: \> nul:`, это увеличит нагрузку на процессор. Если вы закомментируете строку `dir`, вы создадите цикл CPU. AFH 9 лет назад 0
@ TheGoodUser-Sp. В качестве дополнения стоит отметить, что, если для других процессов не требуется более 40% ЦП, то 60% требований вашей программы Python всегда будут доступны. Вы также можете попробовать запустить две копии вашей программы и изменить приоритет одной из них: они не могут получить 60%, что гарантирует чрезмерную нагрузку на ЦП, так что приоритеты будут учитываться при распределении ресурсов. ЦПУ. AFH 9 лет назад 1
Команда dir не особо загружает процессор - она ​​привязана к диску. Jamie Hanrahan 8 лет назад 0
Забавно, но запись в консоль (т. Е. В окно командной строки) в приложении в текстовом режиме (например, cmd) не только вовлекает процессорное время в процесс записи. Приложение символьного режима не имеет кода GUI (пользовательский или GDI-вызовы), иначе оно не будет приложением символьного режима. Записи в стандартный вывод (или что-то еще) обрабатываются путем отправки сообщений другому процессу (например, `conhost`), который запускает окно для вас. Так что нет, вы не увидите процессорного времени только в процессе приложения в текстовом режиме. Запуск приложения с графическим интерфейсом, который просто пишет текст в собственное окно, на самом деле более эффективно! Jamie Hanrahan 8 лет назад 0
@JamieHanrahan - Конечно, вы технически правы, что именно потоки потребляют процессорное время, но я не уверен, что ваше обновление добавляет что-либо к моему ответу, так как требование процессора к программе - это совокупность требований ее потоков, и это это общее количество, которое обычно отображается системными мониторами, такими как TaskManager, ProcExp и т. д. В отношении CMD против приложений с графическим интерфейсом, но для моей иллюстрации я хотел процесс с высокой нагрузкой на ЦП, хотя и не на 100%. AFH 8 лет назад 0
Это может немного добавить к ответу, но я считаю, что для правильного понимания планирования Windows важно различать процессы и потоки. Таким образом, с таким же успехом можно использовать правильный термин, даже если речь идет об однопоточном процессе. Различие, конечно, не повредит ответу и может помочь избежать путаницы в будущем. Jamie Hanrahan 8 лет назад 0
@AFH «Windows Internals Book Tools» - своего рода дополнение к инструментам sysinternals - включает в себя забавную небольшую вещь под названием «cpustres», которую вы можете использовать для создания от одного до четырех потоков, которые занимают настраиваемые порты времени процессора, примерно от От 25% до 100%. `cpustres` используется во многих« экспериментах »в главе планирования _Windows Internals_. https://technet.microsoft.com/en-us/sysinternals/bb963901.aspx?f=255&MSPPError=-2147217396 Jamie Hanrahan 8 лет назад 0