Está mudando a prioridade do processo de um jogo para ruim em tempo real para a CPU?

Question

No Windows, mudei frequentemente a prioridade de um processo de jogos para 'alto' ou 'tempo real' para obter um aumento de desempenho. Isso nunca resultou em problemas com meu hardware. Eu estava pensando que talvez eu pudesse fazer isso no Linux usando o comando chrt para mudar a prioridade em tempo real do processo de jogos, já que renice ing, até mesmo para -20 (a prioridade mais alta) não parece fornecer qualquer sinal perceptível impulso. No entanto, tenho receio de fazer isso sem saber se isso pode ser ruim para minha CPU. Alguém pode me informar sobre os riscos?

    

Answer 1

A alteração da prioridade de um processo determina apenas com que frequência esse processo será executado quando outros processos estiverem competindo pelo tempo de CPU. Não tem impacto quando o processo é o único que usa o tempo da CPU. Um processo de prioridade mínima em um sistema inativo recebe 100% do tempo de CPU, o mesmo que um processo de prioridade máxima.

Assim, você pode executar seu jogo com uma prioridade mais alta, mas isso não fará com que ele seja executado mais rapidamente, a menos que alguma outra coisa no sistema esteja usando uma quantidade significativa de tempo de CPU.

Eu recomendo manter a prioridade menor do que o servidor X, porque se o servidor X quer tempo de CPU, é provável que seja porque o jogo está pedindo para mostrar algo complexo, e a exibição é geralmente uma tarefa exigente da CPU (mas depende de quanto do trabalho é feito na GPU - as prioridades da CPU não influenciam a GPU).

As CPUs são projetadas para executar código. Mudar as prioridades do processo não afetará a quantidade de trabalho que o processador faz, mas, mesmo se o fizesse, isso não danificaria o processador, apenas o tornaria mais quente, fazendo com que os ventiladores do computador se danificassem mais.

    

Answer 2

Você está falando sobre alterar a quantidade de demanda da CPU enquanto está executando o encadeamento?

O CPU moderno realmente usa um escalonamento de velocidade extremamente rápido. Por exemplo, se você fez uma análise do clock de um Intel Core i5 / i7, você pode ver as velocidades de clock piscando para cima e para baixo realmente muito rapidamente. É parte da maneira pela qual a Intel pode ajustar o desempenho em relação à quantidade de energia consumida. Você pode ter muita energia disponível em um PC de mesa, mas o material está sendo convertido em calor quando a CPU está trabalhando mais, por isso é importante obter o maior número de watts por watt.

Eu só sei disso pelo que li em outros fóruns de jogos. Eu não sou um cientista da CPU.

Eu não acho que você faria algum dano ao ajustar um tópico para o máximo de "malícia". A única coisa que você deve ficar de olho é quão quente sua CPU está ficando, mas a menos que você tenha usado overvolting na BIOS, então é bem impossível cozinhar a CPU antes que ela desligue.

As CPUs modernas são projetadas para mudar rapidamente a velocidade. Faça uma busca por Intel Speed Stepping e 'CPU C states' e você verá o que quero dizer.

    

Answer 3

Usar renice em um programa Linux não queima sua CPU, mas não necessariamente fará o que você quer fazer.

As prioridades têm nada relacionadas à rapidez com que uma CPU executa o código. Executa códigos de programas em diferentes níveis de prioridade igualmente rápido. Quais prioridades mudam é qual programa o sistema operacional escolhe para executar quando é dada uma escolha. As CPUs podem executar apenas um "encadeamento" de execução de cada vez (tecnicamente 1 por núcleo para CPUs com vários núcleos). Se precisar fazer mais do que isso, ele depende da multitarefa - ele alterna entre executar programas diferentes para dar a ilusão de executar mais threads do que os CPUs. Ao escolher quanto tempo dar para cada uma dessas tarefas, ele faz isso usando a prioridade como uma dica.

O que "realtime" significa para um computador é menos "executar tão rápido" e mais "não antecipar este processo". A programação em tempo real é muito importante em muitos campos. Por exemplo, se eu estava escrevendo softwares que gerenciam freios antitravamento em um carro, eu realmente não quero que minha tarefa seja executada alguns milissegundos atrasada porque o sistema operacional decidiu que precisava executar um diagnóstico os limpadores de para-brisa. Assim, o software de gerenciamento de freios antitravamento em carros é executado em uma prioridade "em tempo real".

Na verdade, no Linux, o nível de prioridade "tempo real" é um pouco inapropriado. Isso é por causa de como o Linux agenda seus processos. No Windows, se você tiver um processo em execução em uma prioridade mais alta, os processos em execução em prioridades mais baixas não receberão tempo de CPU, a menos que a tarefa de maior prioridade esteja aguardando alguma coisa - nenhuma. Somente os processos do kernel podem rodar no topo de uma tarefa do Windows "em tempo real". O Windows tem um tonelada de bloatware sendo executado em segundo plano o tempo todo, então aumentar a prioridade para "tempo real" impede que todo esse lixo seja executado.

No entanto, há um problema com isso. Às vezes, sua tarefa de prioridade mais alta depende de uma dessas tarefas de prioridade mais baixa. Isso é chamado de "inversão de prioridade" e é um grande tópico no mundo da programação multithread. Quando isso acontece, a tarefa de prioridade mais alta pode diminuir a tarefa de prioridade mais baixa, sem perceber que ela está parando sozinha! No Linux, isso não acontece porque no Linux, as prioridades são vistas como uma maneira de determinar qual parte da CPU é dada a cada programa, ao invés de uma abordagem de tudo ou nada. Um processo rodando a -20 recebe substancialmente mais tempo de CPU do que um rodando a 0, mas mesmo na presença de um programa -20, o programa 0 obtém algum tempo de CPU. Se a memória serve, o escalonador atual do Linux dá a um programa -1 vezes mais poder de CPU que um 0, e um programa a -2 duas vezes mais que -1, e assim por diante. Isso significa que 0.9999046% do seu tempo de CPU irá para o programa que está em -20, mas alguma pequena fração faz ir para o programa em 0. O programa em 0 parecerá que está rodando em um 200kHz processador!

Se você quiser true em tempo real, onde você pode impedir que qualquer outra coisa o anteceda, você terá que escrever um driver de kernel ou usar uma extensão em tempo real para o Linux. Redhat tem um chamado MRG, que permite o processamento em tempo real real com o Linux. Nesse caso, "tempo real" significa algo específico. Sob o MRG, os usuários do grupo "tempo real" têm permissão para usar essas extensões em tempo real (o que poderia manter o processador sempre ocupado, porque eles não estão usando intencionalmente um bom programador Linux amigável).