Por que seu código não deve usar 100% da CPU? [fechadas]

Estou falando especificamente sobre um programa C # .NET 4 em execução no Windows XP ou superior, mas respostas gerais também são aceitáveis.

Suponha um programa já otimizado e eficiente. O problema aqui se deve inteiramente aos efeitos do alto uso da CPU no hardware e se um programa de alto uso deve ser controlado para reduzir o desgaste, e não se minha implementação é eficiente.

Um colega hoje sugeriu que eu não visasse a utilização de 100% da CPU nos meus processos de carregamento de dados porque "as CPUs modernas são baratas e se degradam rapidamente em 100% da CPU".

Isso é verdade? E se sim, por quê? Eu estava anteriormente com a impressão de que o uso de 100% da CPU era preferível para uma operação intensiva ou longa e não consegui encontrar nenhuma fonte respeitável sobre o assunto.

Se o resfriamento for insuficiente, a CPU poderá superaquecer. Mas todas elas (bem, pelo menos todas as CPUs modernas de PC) apresentam vários mecanismos de proteção térmica que irão acelerar a velocidade do relógio ou, como último recurso, desligar.

Portanto, sim, em um laptop empoeirado, 100% da carga da CPU pode causar problemas temporários, mas nada irá quebrar ou "degradar" (o que isso significa).

Para problemas ligados à CPU, 100% da carga da CPU é o caminho certo a seguir.

Quanto à capacidade de resposta do aplicativo (UI), esse é um conceito separado da utilização da CPU. É perfeitamente possível ter um aplicativo que não responde que usa 1% da CPU ou um aplicativo responsivo que usa 100% da CPU. A capacidade de resposta da interface do usuário se resume à quantidade de trabalho realizado no encadeamento da interface do usuário e à prioridade do encadeamento da interface do usuário versus outros encadeamentos.

Os programas Windows (winforms / WPF) devem permanecer sempre responsivos. Com uma implementação ingênua de um processo que utiliza recursos de 100% da CPU, é muito fácil tornar seu programa ou mesmo seu sistema lento e paralisado.

Com uma boa implementação (por exemplo: use um thread separado com prioridade mais baixa), isso não deve ser um problema.

Você não deve se preocupar com a quebra da CPU mais cedo.

Geralmente, não há nada de errado com um programa que usa 100% da CPU enquanto está realizando um trabalho útil e não está demorando muito para ser importante . Se uma plataforma de hardware específica é, por exemplo, capaz de usar 100% da CPU continuamente por um segundo antes de voltar a 50% para evitar superaquecimento, geralmente é melhor para um aplicativo que tenha trabalho útil para executarpara executar o mais rápido possível e deixar que a CPU ou o SO lide com qualquer limitação necessária, do que um aplicativo adivinhe com que rapidez "deveria" ser executado. Se um aplicativo ou encadeamento tiver um trabalho de baixa prioridade, o que seria útil, mas nem sempre crítico, pode ser útil para o sistema operacional limitar o uso da CPU da tarefa de baixa prioridade a 50%, de modo que, se a CPU precisar fazer isso algo rapidamente estará pronto para "correr" por um segundo, mas o aplicativo não deve se preocupar com essas coisas além de solicitar uma baixa prioridade de encadeamento.

As maiores situações em que é ruim usar 100% da CPU são:

• O aplicativo está ocupado-à espera de algum evento que não vai ser acelerada por polling persistente [e realmente pode ser adiada se o esforço desperdiçado verificar se a tarefa é feita ocupa recursos da CPU que poderia ser gasto fazendo a tarefa].

• O aplicativo está redesenhando a exibição excessivamente. A definição de "excessivamente frequentemente" dependerá, em certa medida, da natureza do dispositivo de exibição e do conteúdo exibido. Se o hardware da tela puder exibir 120 qps, pode haver casos em que a animação possa ser mostrada a 120 qps sem adicionar desfoque de movimento, mas não possa ser mostrada corretamente em taxas de quadros mais baixas sem a adição. Se a renderização de um quadro com desfoque de movimento demorar muito mais do que renderizá-lo sem, então renderizar a 120fps no hardware que o suporta pode realmente não ser mais caro do que renderizar em uma taxa de quadros mais lenta com o desfoque de movimento. [Situação simples: uma roda com 29 raios, girando a uma rotação por segundo. A 120 fps, a roda pareceria girar com a velocidade e direção adequadas; a 60fps,

O primeiro é claramente reconhecível como ruim. O segundo é um pouco mais sutil. Se alguém tiver como alvo uma plataforma móvel, pode ser desejável, em alguns casos, permitir que os usuários selecionem a taxa de quadros de animação desejada, pois alguns usuários podem não estar preocupados com a duração da bateria, mas desejam a melhor animação de qualidade, enquanto outros aceitariam qualidade inferior animação em troca de uma melhor duração da bateria. Em vez de fazer com que o aplicativo tente adivinhar onde deve estar a troca, pode ser útil permitir que o usuário a personalize.

"CPUs modernas são baratas e degradam rapidamente em 100% da CPU".

Eu não acho que alguém tenha realmente abordado a parte "degradar" desta questão. Os CIs se degradam quando a temperatura da matriz exceder os limites do fabricante. Os CIs geralmente são projetados para operar até 125 ° C, embora cada aumento de 10 ° C diminua a vida em 50%

Os processadores nem sempre têm regulação térmica. Em seguida, alguns AMD Durons tiveram problemas (supostamente era possível destruir um se executado sem dissipador de calor). Agora, todos os processadores de PC terão sensores de temperatura embutidos que retornam ao clock da CPU e desaceleram o relógio para evitar danos. Portanto, você pode achar que seu programa está usando 100% da CPU disponível, mas a CPU está executando apenas 75% da sua velocidade nominal porque seu resfriamento é inadequado.

Dentro de um programa do usuário não é o local correto para tentar gerenciar o consumo da CPU. Geralmente, seu programa deve alternar entre fazer as coisas o mais rápido possível e esperar, suspenso, pelo acesso a entrada ou disco. Você deve evitar a espera ocupada e o bloqueio, se possível, mas como cortesia para o resto do sistema.

O Windows e o Linux têm sistemas de "govenor" de CPU que farão o desempenho e o gerenciamento térmico. Como isso é feito no nível do sistema operacional, pode ser responsável pelo consumo total da CPU do sistema. É de responsabilidade do sistema operacional gerenciar o hardware e impedir que os programas do usuário o usem incorretamente. É de responsabilidade do proprietário do hardware manter os ventiladores limpos e funcionando, e o fabricante instalar os dissipadores de calor e ventiladores adequados em primeiro lugar.

Existem alguns casos em que os dispositivos têm refrigeração inadequada, mas uma enxurrada de retornos ensina os fabricantes a não fazer isso.

Para interpretar o advogado do diabo: De certa forma, um programa que não pode atingir 100% de utilização pode causar um desgaste pior: a menos que seja suspenso aguardando um pressionamento de tecla, é provável que ele seja suspenso aguardando E / S de disco na maioria das vezes. E os discos são (ainda geralmente) grandes dispositivos mecânicos sujeitos a desgaste mecânico ou ao risco de choque / efeitos giroscópicos quando se movem, sem mencionar o consumo de energia.

"..as CPUs modernas são baratas e degradam-se rapidamente a 100% da CPU".

Você não precisa se preocupar com "degradação da CPU". As CPUs modernas não têm menos qualidade do que antigamente.

É muito caro (e está ficando mais caro a cada dois anos) fazer CPUs, alguns bilhões para construir uma nova fábrica não são incomuns (veja o link).

http://en.wikipedia.org/wiki/Semiconductor_fabrication_plant

Os custos de produção de uma CPU dependem no máximo de não. de unidades produzidas. Este é um fato bem conhecido na economia. Essa é a razão pela qual eles podem ser vendidos (relativamente) "baratos" depois de tudo. (Eu acho que nenhum link é necessário aqui)

Posso listar uma série de razões pelas quais consideraria as CPUs modernas tendem a ter mais qualidade do que nos "tempos antigos".

Mas apenas o mais importante: vantagens em testar. Os eletrônicos modernos são "projetados para teste". Seja software ou hardware, o amplo insight de avaliar testes em quase todo o resto não é tão antigo. Para CPUs, os testes são feitos para formar os diferentes tipos de preço e frequência, por exemplo, os melhores CPUs são vendidos com as frequências mais altas. Apesar disso, os processadores mais baratos costumam operar com maior frequência do que os vendidos - eles são prejudicados apenas pelo motivo em que o fabricante deseja vender alguns processadores de "alto nível" a preços mais altos.

(Por outro lado, é claro que existem mais erros possíveis para um processador com mais de 1,5 bilhão de transistores normalmente hoje em dia do que com alguns milhares de transistores de um processador dos anos setenta. Mas isso não contradiz a minha resposta IMO. Processadores em geral tendem a ter muitos erros conhecidos, pelo menos no microcódigo, mas isso não está sujeito aqui.)

Há ainda mais motivos para não se preocupar com a degradação da CPU do seu programa:

• A primeira razão é que as CPUs modernas diminuem a frequência ou o acelerador, se estiverem ficando muito quentes.

  Deve ficar claro que, se você utilizar a CPU 100% 24 horas por dia, 7 dias por semana, durante todo o ano, ela normalmente morrerá mais cedo do que uma CPU usada apenas a cada segunda semana uma hora. Mas isso também é verdade para os carros. Somente nesses casos, eu pensaria na utilização da CPU e no potencial que você dorme.

• A segunda razão é que é realmente muito difícil escrever um programa que use 100% da CPU do sistema operacional (por exemplo, no Windows). Além disso, as CPUs modernas (normalmente) têm pelo menos 2-4 núcleos. Portanto, um algoritmo tradicional que tende a usar 100% de uma CPU de núcleo único, agora possui apenas 50% em uma CPU de núcleo duplo (simplificado, mas visto em cenários reais).

• Além disso, o sistema operacional tem o controle sobre a CPU e não o seu programa; portanto, se houver outros aplicativos com a mesma ou maior prioridade (qual é o padrão), seu programa estará obtendo o máximo de CPU possível, mas os outros aplicativos não morrer de fome. (Claro que essa é apenas a teoria simplificada e, é claro, a multitarefa do Windows, Linux e outras não é perfeita, mas no geral eu consideraria isso como verdade).

"Eu estava anteriormente com a impressão de que o uso de 100% da CPU era preferível para uma operação intensiva ou longa .."

Sim, fique com isso. Mas, por exemplo, se você espera e faz um loop por outro processo, ou seja, não faz nada, não seria tão ruim se você Thread.Sleep () alguns milissegundos nesse loop, dando tempo extra a outros. Considerando que não é necessário para um bom sistema operacional multitarefa, resolvi alguns problemas com isso, por exemplo, para o Windows 2000. (Isso NÃO significa, é claro, usar Sleep () em cálculos, por exemplo.

Essa degradação é teoricamente possível e é chamada de " eletromigração ". A eletromigração depende da temperatura, acelerando à medida que a temperatura aumenta. Se é um problema prático para as CPUs modernas, está em debate. As práticas modernas de design do VLSI compensam a eletromigração e é mais provável que os chips falhem por outros motivos.

Dito isso, a eletromigração acontece mesmo em cargas e temperaturas normais , mas é lenta o suficiente para que um chip bem projetado se torne obsoleto muito antes de falhar ou falhe por outro mecanismo primeiro.

A taxa de eletromigração depende da temperatura do chip, com a vida útil dobrando a cada 10 ° C (aproximadamente). Essa é, de fato, a base de um teste chamado "HTOL" (vida operacional em alta temperatura), que mede quanto tempo leva para um chip morrer a, digamos, 125 ° C. Um chip rodando a 125 ° C falhará aproximadamente 100 vezes mais rápido que um chip rodando a 55 ° C; portanto, se for projetado para durar pelo menos 10 anos a 55 ° C, um chip poderá falhar dentro de 1 mês a 125 ° C. Se rodar a algo mais razoável como 85 ° C, esse chip ainda falhará pelo menos 5 a 10 vezes mais cedo do que foi projetado.

Obviamente, as CPUs são geralmente projetadas com temperaturas mais altas em mente, para que possam durar anos a 85 ° C 24/7 operação de carga de 100%. Por isso, sugiro que você não se preocupe em "desgastar" a CPU e apenas se uma carga de 100% é apropriada da perspectiva da engenharia de software.

Se você estiver executando seu código em clientes, 100% de utilização da CPU significa que os computadores clientes nesse momento não podem ser usados ​​para mais nada além de tarefas com maior prioridade. Como a maioria dos aplicativos geralmente é executada com prioridade padrão, os usuários que usam esses computadores perceberão o congelamento do computador e não poderão fazer mais em seus computadores. Mesmo se estivermos falando de rajadas curtas, os usuários trabalhando em alguma coisa ainda perceberão.

Como outros disseram, você era bastante reservado sobre a configuração, então não posso dizer com certeza. Mas, se seus clientes são computadores de mesa, fique longe da utilização de 100% da CPU. Não por causa da degradação da CPU, mas porque não é uma boa forma de atrapalhar os usuários durante o trabalho.

Portanto, a situação é a seguinte: você tem um código que é executado, digamos, por cinco horas, usando 100% de todas as CPUs, que é otimizado o máximo possível, o proprietário da máquina fica bem com a máquina sendo inutilizável por cinco horas e seu colega alega que seria melhor executar seu código em 6 horas usando 83,33% de todas as CPUs, porque isso causa menos desgaste no computador.

Depende do computador que você está usando. Sei que um fabricante de computadores recusou os reparos da garantia dentro do prazo de garantia em computadores domésticos baratos usados ​​em um ambiente científico que funcionava 24 horas por dia, 7 dias por semana. Eles claramente queriam que o cliente comprasse seus servidores mais caros ou computadores "comerciais". Se eles tiveram sucesso, não sei.

Todo Mac que possuo possui, em algum momento de sua vida, código de execução com 100% de uso da CPU por dias seguidos. Em um caso, tive que desligar a tela, porque não tinha o carregador original de um laptop e, com 4 núcleos e hiperfiação, ele usava mais energia do que o carregador fornecido - então a bateria descarregou e quando chegou 5% o computador diminuiu a velocidade do relógio até a bateria chegar a 10%! (Com o visor desligado, funcionou a toda velocidade por vários dias). Em nenhum caso, quaisquer efeitos negativos.

Portanto, com um computador bem projetado, você está certo. Com um computador barato e mal projetado, seu colega pode estar certo. Por outro lado, você pode considerar o custo do seu tempo de espera versus o custo da compra de um computador de substituição.

Se possível, torne seu código uma tarefa de prioridade mais baixa e mantenha o segmento pesado da CPU separado da GUI. Então você pode ter 100% de utilização, mas o usuário sempre pode executar outras tarefas e permanecer responsivo. Por si só, uma CPU é projetada para permanecer funcionando com 100% de uso por um tempo ou não seria liberada. A menos que o usuário final faça modificações sérias e perigosas no hardware, você não poderá danificar nada.