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

40

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

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

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

Isso é verdade? E se sim, porque? Anteriormente, eu estava com a impressão de que 100% do uso da CPU era preferível para uma operação intensiva ou longa, e não encontrei nenhuma fonte respeitável sobre o assunto de qualquer forma.

    
por Nick Udell 07.10.2014 / 14:47
fonte

10 respostas

56

Se o resfriamento for insuficiente, a CPU poderá superaquecer. Mas todos eles (bem, pelo menos todos os PCs modernos) possuem vários mecanismos de proteção térmica que reduzem a velocidade do clock ou, como último recurso, desligam.

Então, sim, em um laptop empoeirado, 100% da carga da CPU pode causar problemas temporários, mas nada vai quebrar ou "degradar" (o que quer que isso signifique).

Para problemas de limite de 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% de CPU ou aplicativo responsivo que usa 100% da CPU. A capacidade de resposta da interface do usuário resume-se à quantidade de trabalho realizado no thread da interface do usuário e à prioridade do thread da interface do usuário em relação a outros threads.

    
por 07.10.2014 / 15:05
fonte
14

Os programas do Windows (winforms / WPF) devem permanecer sempre responsivos. Com uma implementação ingênua de um processo que usa 100% de recursos de CPU, é muito fácil fazer com que seu programa ou até mesmo seu sistema pareça lento e pendente.

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

Você não deve se preocupar com a quebra de sua CPU antes.

    
por 07.10.2014 / 15:13
fonte
14

Geralmente não há nada errado com um programa usando 100% de CPU enquanto ele está realmente fazendo um trabalho útil e não está tirando tempo de algo mais importante . Se uma plataforma de hardware particular é, e. somente capaz de usar 100% da CPU continuamente por um segundo antes de ter que acelerar até 50% para evitar o superaquecimento, geralmente é melhor para uma aplicação que tenha trabalho útil para executar para rodar tão rápido quanto pode, e deixar a CPU ou o SO manipular qualquer limitação necessária, do que para um aplicativo adivinhar quão rápido ele "deve" ser executado. Se um aplicativo ou encadeamento tiver trabalho de baixa prioridade para fazer, o que seria útil, mas nem sempre crítico, pode ser útil para o sistema operacional limitar o uso da CPU de tarefa de baixa prioridade a 50%, de forma que a CPU precise fazer 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 prioridade de thread baixa.

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

  • O aplicativo está ocupado - aguardando algum evento que não será apressado por sondagens persistentes [e pode realmente ser adiado se o esforço perdido verificar se a tarefa é feita ocupa recursos da CPU que poderiam ser gastos fazendo a tarefa].

  • O aplicativo está redesenhando o display com muita freqüência. A definição de "excessivamente frequente" dependerá, em certa medida, da natureza do dispositivo de exibição e do conteúdo exibido. Se o hardware de exibição puder exibir 120fps, pode haver casos em que a animação pode ser exibida a 120fps sem adicionar desfoque de movimento, mas não pode ser exibida de maneira limpa em taxas de quadros mais baixas sem adicioná-lo. Se renderizar um quadro com desfoque de movimento levaria muito mais tempo do que renderizá-lo sem, renderizar em 120fps em hardware que o suporte poderia na verdade não ser mais caro do que renderizar em uma taxa de quadros mais lenta com desfoque de movimento. [Situação simples: uma roda com 29 raios, girando a uma revolução por segundo. Em 120fps, a roda parece girar com velocidade e direção adequadas; a 60fps, uma roda bruxuleante parece girar lentamente na direção oposta].

O primeiro é claramente reconhecível como ruim. O segundo é um pouco mais sutil. Se um estiver segmentando 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 se preocupar com a duração da bateria, mas querem a melhor qualidade de animação, enquanto outros aceitariam menos qualidade animação em troca de uma melhor duração da bateria. Em vez de o aplicativo tentar adivinhar onde deve ser o compromisso, pode ser útil permitir que o usuário o personalize.

    
por 07.10.2014 / 18:59
fonte
9

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

Eu não acho que alguém tenha realmente abordado a parte "degradada" desta questão. ICs irão degradar quando a temperatura da matriz exceder os limites do fabricante. ICs são normalmente projetados para operar até 125C, embora todo aumento de 10C encurte a vida útil em 50%

Os processadores nem sempre têm regulação térmica. Então alguns AMD Durons experimentaram problemas (supostamente era possível destruir um se rodasse sem o dissipador de calor). Agora, todos os processadores de PC terão sensores de temperatura incorporados que retornarão ao clock da CPU e retardarão o relógio para evitar danos. Assim, você pode descobrir que seu programa está usando 100% da CPU disponível, mas a CPU está funcionando apenas a 75% de 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 tarefas o mais rápido possível e aguardar, suspenso, por entrada ou acesso ao disco. Você deve evitar ocupado-espera e spinlocking se possível, mas como uma cortesia para o resto do sistema.

Tanto o Windows quanto o Linux possuem sistemas "govenor" de CPU que farão o gerenciamento térmico e de desempenho. Como isso é feito no nível do SO, ele pode ser responsável pelo consumo total de CPU do sistema. É responsabilidade do sistema operacional gerenciar o hardware e impedir que os programas do usuário o utilizem de maneira incorreta. É da responsabilidade do proprietário do hardware manter os ventiladores limpos e funcionando, e o fabricante deve se adequar a dissipadores de calor e ventiladores adequados em primeiro lugar.

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

    
por 07.10.2014 / 18:20
fonte
3

Para representar o defensor do diabo: De certa forma, um programa que não alcança 100% de utilização poderia causar um desgaste pior: a menos que seja suspenso aguardando uma tecla, é provável que ele seja suspenso esperando pela maioria das E / S do disco. Tempo. E os discos são (ainda geralmente) grandes dispositivos mecânicos que estão sujeitos a desgaste mecânico ou o risco de choque / efeitos giroscópicos quando se movem, para não mencionar o consumo de energia.

    
por 07.10.2014 / 20:01
fonte
3

"..modern CPUs are cheap and will degrade quickly at 100% CPU".

Você não precisa se preocupar com a "degradação da CPU". CPUs modernas não são de menor qualidade que antigamente.

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

link

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

Eu posso listar várias razões pelas quais eu consideraria que CPUs modernas tendem a ser mais de qualidade do que em "tempos antigos".

Mas apenas o mais importante: Vantagens nos testes. A eletrônica moderna é "projetada para teste". Quer o software ou hardware, o amplo insight de avaliar os testes em quase todo o resto, não é tão antigo. Para CPUs, os testes são mesmo tomados para formar os diferentes tipos de preço e frequência, e. as melhores CPUs são vendidas com frequências mais altas. Apesar disso, os processadores mais baratos são capazes de operar com maior freqüência do que vendidos - eles são prejudicados apenas porque o fabricante quer vender alguns processadores de "alto nível" com preços mais altos.

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

Existem ainda mais razões para não se preocupar com a degradação da CPU no seu programa:

  • A primeira razão é que os CPUs modernos diminuem sua frequência ou aceleração, se estão ficando muito quentes.

    Deve ficar claro que se você utilizar a CPU 100% 24/7 o ano todo, ela normalmente morrerá mais cedo do que uma CPU usada apenas a cada duas semanas em uma hora. Mas isso é verdade para os carros, também, a propósito. Somente nesses casos, eu pensaria sobre a utilização da CPU e o potencial para você mesmo.

  • O segundo motivo é que é realmente muito difícil escrever um programa que use 100% da CPU do sistema operacional (por exemplo, no Windows). Além disso, 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 tem apenas 50% em uma CPU dual core (simplificada, mas vista em cenários reais).

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

"I was previously under the impression that 100% CPU usage was preferable for an intensive or long operation.."

Sim, fique com isso. Mas, por exemplo, se você esperar e voltar para outro processo, em outras palavras, não fazer nada, não seria muito ruim se você Thread.Sleep () alguns milissegundos nesse loop, dando tempo extra para os outros. Considerando que não é necessário para um bom sistema operacional multitarefa, eu resolvi alguns problemas com isso, por exemplo, para Windows 2000. (Isso NÃO significa, obviamente, usar Sleep () em cálculos, por exemplo.

    
por 07.10.2014 / 17:00
fonte
2

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

Dito isto, a eletromigração acontece mesmo com 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. / p>

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

É claro que as CPUs geralmente são projetadas com temperaturas mais altas em mente, então elas normalmente podem durar anos a 85 ° C 24/7 100% de operação de carga. Então eu sugiro que você não se preocupe em "esgotar" a CPU, e só se preocupe se uma carga de 100% é apropriada do ponto de vista da engenharia de software.

    
por 08.10.2014 / 21:47
fonte
1

Se você estiver executando seu código em clientes, 100% da utilização da CPU significa que os computadores clientes nesse período não podem ser usados para mais nada, exceto tarefas com prioridade mais alta. Como a maioria dos aplicativos geralmente é executada com prioridade padrão, os usuários que usam esses computadores notarão o congelamento do computador e não conseguirão fazer isso em seus computadores. Mesmo se estivermos falando de rajadas curtas, os usuários que estiverem trabalhando em algo ainda perceberão isso.

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 desktop, fique longe de 100% de utilização da CPU. Não por causa da degradação da CPU, mas porque não é boa forma de interromper os usuários durante o trabalho.

    
por 07.10.2014 / 15:12
fonte
1

Então a situação é esta: você tem algum código que roda por cinco horas usando 100% de todas as CPUs, que é otimizado o máximo que você puder, o dono da máquina está bem com a máquina inutilizada por cinco horas, e seu colega afirma que seria melhor rodar seu código em 6 horas usando 83,33% de todos os processadores, porque ele coloca menos desgaste no computador.

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

Todo Mac que eu possuo tem, em algum momento de sua vida, código de execução com 100% de uso da CPU por dias de cada vez. Em um caso eu tive que desligar o monitor, porque eu não tinha o carregador original para um laptop, e com 4 núcleos e hyper threading ele usava mais energia do que o carregador fornecido - então a bateria caiu, e quando chegou 5 por cento o computador abrandou a velocidade do relógio até que a bateria foi até 10%! (Com a tela desligada, ela funcionou em velocidade máxima por vários dias). Em nenhum caso, quaisquer efeitos nocivos.

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

    
por 08.10.2014 / 18:13
fonte
0

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

    
por 07.10.2014 / 15:17
fonte