Por que a priorização de processos não produz uma melhoria de velocidade?

18

Eu tenho 2 aplicativos que usam muitos recursos do sistema. Quando diminuo a prioridade de um no Gerenciador de Tarefas, enquanto aumento o outro, não percebo nenhuma melhora significativa na velocidade do aplicativo com a prioridade mais alta.

Por que isso? Há mais coisas acontecendo ou há mais a ser feito?

    
por Moses 12.05.2014 / 17:31

5 respostas

29

A prioridade não ajuda quando o gargalo é a própria CPU. O que a prioridade realmente faz é afetar o algoritmo de agendamento que o sistema operacional usa para determinar qual processo é executado a seguir, pois não há processadores suficientes na maioria dos sistemas para executar cada processo continuamente.

Uma tarefa de prioridade mais alta chegará ao topo da fila mais rapidamente, portanto, isso ajuda com a latência geral, mas se o processo estiver esgotando toda a fatia de tempo, ela será alocada na computação real e o agendamento não alterará nada lá. Alterar a prioridade é mais útil quando você tem um processo que está esperando na E / S e quer que ele seja mais responsivo.

    
por 12.05.2014 / 19:00
4

A prioridade é o tempo da CPU. Todos os núcleos são 100% utilizados o tempo todo? Se não, a prioridade não teria efeito. Com muita frequência, a CPU não é o gargalo e seus recursos de memória, disco ou GPU.

    
por 12.05.2014 / 17:45
3

A prioridade só é importante quando há mais encadeamentos executáveis que os núcleos de CPU disponíveis. Quando isso acontece, a prioridade controla quais segmentos devem ser executados. Na maioria dos sistemas, não há computação suficiente para qualquer contenção na CPU: os threads estão todos bloqueados , esperando que algo aconteça. Isso pode estar esperando que você digite algo, mova o mouse, toque na tela ou que os dados cheguem do disco, da rede, de algum outro dispositivo que você conectou ou de outro encadeamento para terminar de trabalhar com dados críticos. estrutura. Ele pode estar esperando que parte do programa seja lida do disco ou alguma memória que foi trocada para ser lida de volta, em vez de ler explicitamente um arquivo.

No Windows, o agendador mantém uma fila de threads executáveis em cada nível de prioridade. Quando toma uma decisão de escalonamento - ou que um thread esgotou seu quantum (tempo permitido antes que algo precise ser executado), o que significa que outro thread deve ter um turno, ou o thread foi bloqueado e não é mais executável ou um encadeamento de prioridade mais alta foi desbloqueado - o próximo encadeamento na fila no nível de prioridade máxima com qualquer encadeamento executável será agendado. Se o encadeamento em execução esgotou seu quantum, ele será colocado no final da fila. Se for o único segmento em seu nível de prioridade que é executável, e não houver outros executáveis executáveis, mas não em execução, ele terá outro turno.

Em sistemas multicore / multiprocessadores, pode haver restrições em quais núcleos um thread pode ser executado. Além disso, o sistema tenta manter os threads em seu núcleo ideal e dentro de seu nó NUMA, de modo que os dados do segmento provavelmente ainda estejam no cache desse núcleo e tenham acesso rápido aos dados que ele criou. Threads ainda serão executados em núcleos não ideais se não houver escolha sobre o que executar em seguida.

O sistema faz uso de vários reforços de prioridade dinâmica e tamanhos quânticos dinâmicos para que o aplicativo em primeiro plano obtenha mais tempo (se necessário) do que os processos em segundo plano e para que os processos reajam rapidamente quando as operações de E / S forem concluídas , entrada de teclado e touchscreen). Além disso, o aumento de prioridade é usado para contornar inversões de prioridade, em que um encadeamento de alta prioridade está aguardando um recurso que um encadeamento de baixa prioridade está retendo atualmente. Se houver um encadeamento de prioridade média também em execução, ele reduzirá o encadeamento de baixa prioridade do tempo do processador, mantendo o encadeamento de alta prioridade. Assim, o encadeamento de baixa prioridade é temporariamente aumentado para a prioridade mais alta, de modo que ele consiga tempo e libere o recurso que o encadeamento de alta prioridade precisa.

Antes do Windows Vista, a prioridade do encadeamento não afetava a rapidez com que as operações de E / S eram concluídas. Desde o Windows Vista, as E / Ss também podem ter uma prioridade, que por padrão vem da prioridade do encadeamento.

Resumo: você não verá nenhum efeito de alterar as prioridades de thread, a menos que sua CPU esteja sobrecarregada e, mesmo assim, o efeito seja normalmente mínimo. Se o processo tiver que esperar pela E / S ou não estiver competindo com outros processos pelo tempo de CPU, ele já estará sendo executado da maneira mais rápida possível e a alteração da prioridade não tornará isso mais rápido.

    
por 13.05.2014 / 12:01
0

Em geral, é preciso um esforço extra para fazer um programa usar mais de uma CPU (adicionando multi-threading). Portanto, mesmo que o programa tenha a maior prioridade disponível, ele pode estar usando apenas um núcleo.

Outros possíveis problemas:

  • O programa pode ser ineficiente / mal escrito
  • Pode ser retardado devido ao acesso ao disco "lento" ou a uma rede lenta
por 12.05.2014 / 23:59
0

Até mesmo aumentar a prioridade de E / S de um processo de E / S não necessariamente fará com que ele seja executado mais rapidamente. Por exemplo, se é um consumidor de dados produzidos por um processo separado, possivelmente remoto, e está acompanhando a taxa na qual aquela fonte produz os dados, então ele não pode ir mais rápido ou ter uma taxa de transferência maior.

Ao contrário do que é categoricamente declarado na primeira frase da resposta atualmente aceita ( link ), as alterações de prioridade são mais eficaz quando a CPU é o gargalo, como explicado na resposta de Mike Dimmick ( link ). Além disso, a declaração no segundo parágrafo da resposta aceita, "se o seu processo está esgotando toda a timeslice é alocado na computação real, então o agendamento não vai mudar nada lá" é completamente errado a menos que o processo já tenha a mais alta prioridade encadeamentos executáveis sempre que ele estiver esperando para ser executado. Isso ocorre porque, em todas as outras circunstâncias, o aumento da prioridade provavelmente trará mais timeslices por intervalo de relógio de parede.

Mike Dimmick apontou os problemas com essa resposta há alguns dias e forneceu uma resposta muito melhor, mas o primeiro inexplicavelmente continua a ganhar votos. A afirmação de seu autor de que ele está meramente simplificando sua resposta para nós bobos não é plausível, porque não é simplesmente simples, ou mesmo simplista, é totalmente errada, pelo menos no que diz respeito a processos ligados à CPU.

Disclaimer: Eu não conheço o Sr. Dimmick, embora eu possa dizer que ele sabe sobre o que ele está escrevendo.

    
por 15.05.2014 / 18:41