Suponha que você tenha um cartão "vá para o início da linha" do supermercado. Você vai à loja, enche seu carrinho, vai aos caixas e descobre que não há ninguém na fila. O seu cartão ajuda você a fazer o check-out mais rápido? Não.
As prioridades não afetam a velocidade de processamento, pois um processo de prioridade mais alta não é executado mais rápido ou nem usa mais tempo de CPU ... não se for a única coisa que deseja usar a CPU.
Para realmente falar sobre isso, precisamos mencionar tópicos. Os processos não "são executados" no Windows. Threads, que são partes de processos, são o que são executados. (Embora se um processo tiver apenas um encadeamento, a distinção é bastante vaga do lado de fora.)
(A propósito: a terminologia de marketing pela qual uma CPU possui, por exemplo, "quatro núcleos e oito threads") é enganosa. As CPUs têm núcleos, mas as CPUs não "possuem" threads. Os threads são partes de processos. Um núcleo de CPU sem o hyperthreading ativado, pode executar um thread; com o hyperthreading ativado, um núcleo pode executar dois threads. Mas as CPUs não "têm" threads).
Cada encadeamento está sempre em um dos vários estados de agendamento. Os estados mais comumente vistos são: Em espera (* nix chama isso de "bloqueado"; em ambos os sistemas operacionais isso significa esperar por E / S ou similar, não usa tempo de CPU e não deseja nenhum); Pronto (deseja usar o tempo da CPU, mas não há CPUs disponíveis no momento); e em execução . Somente threads em execução consomem tempo de CPU; ou seja, se um processo não possuir threads em execução, será visto usar zero% de tempo de CPU em ferramentas como o Gerenciador de Tarefas.
Um encadeamento pode ser executado apenas em um núcleo (ou, se o hyperthreading estiver ativado, "processador lógico") de cada vez; portanto, um processo pode usar apenas o número de núcleos (ou LPs) da CPU que possui encadeamentos que desejam executar no momento . (A mesma declaração pode ser feita do sistema como um todo.)
A maioria dos threads na maioria dos sistemas passa a maior parte do tempo no estado de espera. (É por isso que seu processo inativo deve estar excedendo 95% do tempo da CPU quando o sistema não está fazendo nada.) Exceções seriam os threads "funcionais" de coisas como vídeo ou renderização em 3D, jogos, etc. Muito poucos threads realmente podem usar 100% da CPU, porque geralmente precisam trabalhar em alguns dados de entrada que precisam ler de algum lugar e geralmente criam dados de saída que precisam ser gravados em algum lugar. E eles podem se referir a muitos dados diferentes na memória ao longo do tempo, o que pode significar que eles precisam aguardar a resolução de falhas de página.
Mas threads fazendo algo como renderização de vídeo ou renderização de imagem 3D podem passar quase todo o tempo "computando" na CPU, e muito pouco esperando por E / S. Esses encadeamentos geralmente são chamados de "limite de computação", o que significa que seu desempenho geral é principalmente limitado pela velocidade da CPU.
A configuração que você faz no Gerenciador de tarefas realmente estabelece a "prioridade básica" para todos os threads no processo. A prioridade real ou "atual" do encadeamento pode ser maior (mas nunca menor que a base). Mais sobre isso em um momento. As decisões de agendamento ("quem deve executar e em qual CPU") são sempre feitas usando a prioridade atual do encadeamento. Prioridade é significativa apenas para threads prontos e em execução (ou, em outras palavras, prioridade não é significativa para threads em espera).
O Windows usa um algoritmo de agendamento preventivo . Se apenas um encadeamento no sistema deseja usar o tempo da CPU, não importa nem um pouco qual é a sua prioridade; obtém 100% da CPU. Não é como se o agendador "retivesse" uma parte da capacidade da CPU quando um encadeamento de baixa prioridade estivesse em execução, apenas no caso de surgir algo de maior prioridade.
Se dois threads desejam usar uma CPU e têm a mesma prioridade, eles são agendados através do que é chamado de "divisão de tempo" e, com o tempo, cada um recebe cerca de 50% do tempo da CPU. Enquanto que, se tiverem prioridades diferentes, o encadeamento de maior prioridade recebe 100% e o inferior, nada .
(Na prática, ele não recebe nada, porque experimentará um "aumento periódico da prioridade para evitar a fome" que pode lhe dar algumas dezenas de ms a cada 4 ou 5 segundos ou mais. Mas isso não é realmente uma exceção à "prioridade mais alta" vitórias ", porque isso é feito ajustando a prioridade do segmento faminto.)
Se você possui mais de um núcleo de CPU, as coisas ficam mais interessantes e as prioridades em geral têm menos efeito. Suponha que você tenha dois threads que desejam executar. E suponha que você tenha dois ou mais núcleos de CPU que não estejam fazendo outra coisa com prioridade igual ou superior a esses threads. Seus dois threads receberão 100% de um núcleo, independentemente de suas respectivas prioridades .
(Duas pessoas aparecem no supermercado e há duas damas grátis. Um dos clientes tem um cartão "vá para o início da fila". Não importa.)
tl; dr version (até agora): As prioridades não são sobre "quem recebe qual proporção de tempo de CPU", mas "quem começa a executar primeiro".
Não vou falar muito sobre hyperthreading aqui, exceto para dizer que o Windows trata cada um dos dois "processadores lógicos" em um núcleo da mesma maneira que trataria um núcleo se o HT estivesse desativado. isto é, são tratadas como CPUs "reais", com esta exceção: o Windows tentará muito não usar mais de um LP em um núcleo por vez. ou seja, você normalmente não começa a ver os dois LPs em um núcleo sendo usados até ter mais do que um número de threads tentando executar todos ao mesmo tempo. Isso ocorre porque os dois "processadores lógicos" não oferecem nada como o dobro do desempenho de um único núcleo não-hyperthread.
Sobre a "prioridade básica": o Windows ajustará ("reforço" e "deterioração") a prioridade atual dos threads com base no que eles fizeram recentemente. Os encadeamentos que concluíram recentemente as operações de E / S serão normalmente um ou dois pontos acima da base; Os threads da interface do usuário (threads que estão executando uma janela) geralmente são consideravelmente mais altos; Os threads ligados à CPU geralmente estarão em sua base. O objetivo disso é manter a capacidade de resposta na interface do usuário do programa e também manter as solicitações de E / S fluindo para itens como discos.
Um programa (processo) também pode alterar a prioridade básica de cada um de seus encadeamentos, dentro de um intervalo determinado pela prioridade do processo (o que você define no Gerenciador de Tarefas). Mas a grande maioria dos programas não se incomoda. (Mais deles deveriam.)
Há outras coisas acontecendo. Por causa do aumento / decaimento de prioridade, e porque os sistemas de multiprocessamento (multicore, hyperthread ou ambos) são tão comuns hoje em dia e porque sempre há coisas em execução em segundo plano no Windows (mas, esperamos, não gastando muito tempo na CPU), e devido aos efeitos da "afinidade" rígida e flexível, é difícil executar casos de teste e obter os resultados exatos que seriam previstos aqui. Mas isso deve lhe dar uma imagem correta.
Em conclusão...
É razoável deixar a maioria das coisas em "Normal". Caso contrário, você pode facilmente acabar morrendo de fome com algo que realmente gostaria de ter (mesmo que você não saiba que existe), como as funções de limpeza de cache do disco do sistema operacional. De fato, muitos dos processos do sistema operacional serão diferentes do normal e devem ser deixados onde quer que o Windows os coloque.
Um argumento razoável para usar o Gerenciador de Tarefas para se preocupar com as prioridades é se você tiver alguma tarefa que monopoliza a CPU (como renderização em vídeo ou 3D) e está diminuindo a velocidade do uso do sistema durante a execução. A coisa certa é, acredite ou não, diminuir sua prioridade em um ou dois graus. Ele usará felizmente todos os ciclos da CPU que nada mais deseja, mas ficará fora do caminho do uso interativo do sistema. Pode demorar um pouco mais para concluir o trabalho, mas o trabalho será feito com o mínimo de interferência no uso interativo de outros programas. Se você não gosta dessa troca, não faça! Mas defina-o como alta prioridade na tentativa de "acelerar o processo" e poderá travar toda a interface do usuário até que seja concluído.
Nunca defina nada para a chamada classe de prioridade em tempo real.
(Editar - este parágrafo foi adicionado) Ok, essa é uma afirmação extrema. ("Nenhuma afirmação universal é verdadeira - sem exceção desta.") Pelo menos, não sem uma consideração muito cuidadosa. Se seu objetivo é fazer algo correr mais rápido, provavelmente não ajudará. Mas isso pode "travar" seu sistema (exigir uma redefinição ou, na maioria das máquinas modernas, exigir um ciclo de energia). Ou torne-o tão indiferente que também pode ser bloqueado.
Nota: qualquer aplicativo reprodutor de vídeo deve estar optando pelo recurso "Agendamento de classe multimídia" no Vista e versões posteriores. Isso fornecerá automaticamente até 80% de uma CPU, calculada em intervalos relativamente curtos. Se você não conseguir uma reprodução sem falhas, algo está muito errado.
Para obter mais detalhes, consulte os capítulos sobre threads e agendamento no Windows Internals 6th Edition de Solomon, Russinovich e Ionescu.
Consulte também minha resposta aqui para obter informações sobre como as prioridades de processos e threads são definidas e o significado da coluna "Prioridade" no Gerenciador de tarefas.
When should I set [priorities in Task Manager]?quase nunca.