Por que devo me importar com o micro desempenho e a eficiência?

Se você estiver processando imagens grandes e iterando em todos os pixels, os ajustes de desempenho podem ser críticos.

Deixe-me contar um pouco sobre o porquê por trás da cultura.

Se você está mais perto de 40 do que de 20 e está progredindo para a vida adulta, veio a maioridade quando o C ++ era o único jogo da cidade, e os aplicativos de desktop eram a norma. o hardware ainda estava muito atrasado em termos de recursos de largura de banda / desempenho.

• Costumávamos ter que fazer truques estúpidos de programação para ler arquivos grandes (> 2G) ...
• Costumávamos nos preocupar com o tamanho do executável ...
• Nós nos preocupávamos com a quantidade de memória que nossos programas consumiam ...
• Nós regularmente tomamos tempo algorítmico versus decisões de troca de espaço ...
• Mesmo no back-end, nós tivemos para escrever programas CGI em C ou C ++ para qualquer coisa para lidar com um não decente. de RPS ... Foi várias ordens de magnitude mais rápido.
• Costumávamos executar testes sobre os méritos de desempenho entre delphi / c ++ / vb!

Muito poucas pessoas precisam se preocupar com essas coisas hoje.

No entanto, há 10 anos você ainda tinha que se preocupar com o software sendo baixado por um modem de 56kb, e sendo executado em um PC de 5 anos ... Você se lembra de como os PCs eram ruins em 1996? Pense em termos de 4GB de disco rígido, um processador de 200Mhz e 128Mb de RAM ...

E os servidores de 10 anos atrás? O servidor de "próxima geração" da Dell custava US $ 2.000 e vinha com 2 (!) Processadores Pentium de 1 Ghz, 2 Gb ou Ram, e um disco rígido de 20 Gb.

Era simplesmente um jogo de bola diferente e todos aqueles engenheiros "seniores" que tinham 10 anos de experiência (os caras provavelmente respondiam suas perguntas), cortavam seus dentes     

já há 10 respostas aqui e algumas são muito boas, mas porque essa é uma implicância pessoal minha ...

otimização prematura que a) leva mais tempo do que uma solução simples b) introduz mais código onde a solução simples teria metade do tamanho e metade da complexidade ec) tornar as coisas menos legíveis é ABSOLUTAMENTE deve ser evitada. No entanto, se um desenvolvedor tiver uma opção entre usar std :: map ou std :: vector, ele escolhe a coleção errada por pura ignorância de desempenho que é tão ruim ou pior que a otimização prematura. E se você pudesse alterar um pouco seu código hoje, manter a legibilidade, manter a mesma complexidade, mas torná-lo mais eficiente, você faria isso? Ou você chamaria isso de "otimização prematura"? Eu acho que muitas pessoas nem sequer pensariam nisso de uma forma ou de outra.

Uma vez fui o cara que aconselhou a "micro-otimização" que exigiu muito pouca mudança e recebi a mesma resposta que você acabou de dizer, "você não deve otimizar muito cedo. Vamos apenas fazer com que funcione e nós" irá mudá-lo mais tarde se houver um problema de desempenho ". Levou vários lançamentos antes de consertarmos. E sim, foi um problema de desempenho.

Considere também que muitos problemas de desempenho não ocorrerão em seu ambiente e nem imediatamente. Algumas vezes você terá um cliente que excede o limite ou outro desenvolvedor decide construir em cima de sua estrutura e aumentar o número de objetos em 10 vezes. Com alguns, porém, sobre desempenho agora, você pode evitar redesenhar muito caro posteriormente. E se o problema for encontrado depois que o software for oficialmente lançado, até mesmo uma simples correção se torna 20 vezes mais cara de se aplicar.

Portanto, em conclusão, manter o desempenho em mente em todos os momentos ajuda a desenvolver bons hábitos. Que são tão importantes quanto ter a escrita limpa, o mais simples possível e o código organizado.

Eu suspeito que muito do que você está vendo é um erro simples de amostragem. Quando as pessoas estão lidando com situações diretas, elas escrevem código e esse é o fim das coisas. Eles fazem perguntas quando estão lidando com algo relativamente complicado, como a necessidade de otimizar, especialmente em uma situação em que não é necessariamente óbvio que a otimização seja necessária.

Dito isto, há, sem dúvida, alguma otimização prematura envolvida também. Corretamente ou não, C e C ++ têm uma reputação de desempenho, o que tende a atrair pessoas que se preocupam com o desempenho - incluindo aquelas que podem fazer otimização tanto por prazer quanto porque é realmente necessário.

Algumas das outras respostas mencionam sistemas incorporados e gostaria de expandir isso.

Existem muitos dispositivos que contêm processadores de baixo custo, por exemplo: o controlador de caldeira em sua casa, ou uma simples calculadora de bolso, ou as dezenas de chips dentro de um carro moderno.

Para poupar dinheiro, estes podem ter quantidades de flash (para armazenar código) e RAM, que parecem pequenas para aqueles que escreveram apenas código para PCs ou smartphones. Para economizar energia, eles podem funcionar com taxas de clock relativamente baixas.

Para dar um exemplo, a família STM32 dos microcontroladores vai de 24 MHz, 16 KB de flash e 4 KB de RAM , até 120 MHz, 1 MB de flash e 128 KB de RAM .

Ao escrever códigos para chips como esses, economizará muito tempo se você quiser tornar seu código o mais eficiente possível. Obviamente, a otimização prematura continua sendo uma má ideia; mas com a prática, você aprende como problemas comuns podem ser resolvidos rapidamente e / ou com recursos mínimos e códigos de acordo.

Estas são essencialmente linguagens de baixo nível, quando se encontra um caso de desempenho patológico onde um detalhe que não importa 99% do tempo está causando o o gargalo, na verdade, tem a oportunidade de trabalhar diretamente em torno do problema (ao contrário da maioria das outras linguagens); mas, é claro, muitas vezes, como fazê-lo com maior eficácia, não é imediatamente aparente. Daí a metade das questões de micro-otimização estranhas / interessantes feitas aqui.

A outra metade só vem daqueles curiosos sobre o quão perto eles podem chegar ao metal. Estas são essencialmente linguagens de baixo nível, afinal ...

O desempenho é sempre um tópico importante quando você está lidando com C e C ++. Com relação a quão longe uma pessoa deve ir, você sempre pode enlouquecer ao ponto de inserir o ASM ou usar a aritmética de ponteiros para uma iteração mais rápida. No entanto, chega-se a um ponto em que se gasta tanto tempo otimizando que o trabalho no desenvolvimento do programa geral é interrompido.

Ao lidar com esses problemas, há desempenho de programador e desempenho de código. Em quais destas questões focará sempre questões interessantes. No final, a questão mais importante é como é perceptível para o usuário. O usuário estará trabalhando com dados que criam arrays com centenas ou milhares de elementos? Nesse caso, codificar para fazer as coisas rapidamente pode fazer com que o usuário se queixe de que as operações padrão do programa são lentas.

Depois, há o usuário que trabalhará com pequenas quantidades de dados. Alguns arquivos aqui e ali, onde fazer coisas como classificação e operações com arquivos não será tão perceptível para o usuário se você estiver usando funções de alto nível que facilitam as coisas para você manter ao custo de algum desempenho.

Este é apenas um pequeno exemplo dos problemas que você enfrentará. Outros assuntos incluem o hardware do usuário alvo. Você terá que se preocupar com o desempenho muito mais se lidar com sistemas embarcados, se seus usuários tiverem, digamos, máquinas dual core com gigs de memória ram.

Por que os programadores se importam tanto? Há idéias tolas povoando suas cabeças, como resolver problemas de desempenho antes que eles saibam que os têm, e não entender quando eles estão adivinhando .

É complicado porque, na minha experiência, existem alguns problemas de desempenho que um deve pensar com antecedência. É preciso experiência para saber o que eles são.

Dito isto, o método que uso é semelhante ao seu, mas não é o mesmo:

1. Comece com o design mais simples possível. Em particular, a estrutura de dados deve ser tão normalizada e mínima quanto possível. Na medida em que tem redundância inevitável, deve-se ter poucas notificações como forma de mantê-lo consistente. É melhor tolerar inconsistência temporária e repará-la com um processo periódico.

2. Quando o programa estiver em desenvolvimento, faça o ajuste de desempenho periodicamente, pois os problemas de desempenho têm um jeito de entrar discretamente. O método que uso é pausa aleatória , porque eu acho que é o melhor.

Veja um exemplo de golpe a golpe o que quero dizer.

Às vezes, você só tem algoritmos que não podem ser melhores do que o tempo linear para o qual ainda há uma strong demanda por desempenho.

Um exemplo é o processamento de vídeo, onde você não pode tornar uma imagem / quadro mais brilhante como um exemplo básico sem fazer um loop em cada pixel (bem, eu suponho que você pode com algum tipo de estrutura hierárquica indicando propriedades herdadas por crianças que acabam descendo em blocos de imagens para nós de folha, mas então você adiaria um maior custo de loop através de cada pixel para o renderizador e o código provavelmente seria mais difícil de manter do que o filtro de imagem mais otimizado do que o micro).

Há muitos casos assim no meu campo. Costumo estar fazendo mais loops de complexidade linear que precisam tocar tudo ou ler tudo do que aqueles que se beneficiam de qualquer tipo de estrutura ou algoritmo de dados sofisticados. Não há trabalho que possa ser ignorado quando tudo tiver que ser tocado. Então, nesse ponto, se você está inevitavelmente lidando com a complexidade linear, você precisa tornar o trabalho realizado por iteração mais barato e mais barato.

Portanto, no meu caso, as otimizações mais importantes e comuns são frequentemente representações de dados e layouts de memória, multithreading e SIMD (normalmente, nesta ordem, a representação de dados é a mais importante, pois afeta a capacidade de fazer os dois últimos). Eu não estou correndo em tantos problemas que são resolvidos por árvores, tabelas de hash, algoritmos de classificação e coisas desse tipo. Meu código diário é mais na veia de, "para cada coisa, faça alguma coisa."

É claro que é outro caso para falar sobre quando as otimizações são necessárias (e mais importante, quando não são), micro ou algorítmico. Mas, no meu caso particular, se um caminho de execução crítico precisa de otimização, os ganhos de velocidade 10x + são geralmente atingidos por otimizações de nível micro, como multithreading, SIMD e reorganização de layouts de memória e padrões de acesso para melhor localização de referência. Não é tão frequente que eu consiga, digamos, substituir um tipo de bolha por um introsort ou um tipo de radix ou detecção de colisão de complexidade quadrática com um BVH, mas encontrar hotspots que, por exemplo, se beneficiam da divisão de campo quente / frio. p>

Agora, no meu caso, meu campo é tão crítico em desempenho (raytracing, motores de física, etc) que um raytracer lento mas perfeitamente correto, que leva 10 horas para renderizar uma imagem, é muitas vezes considerado inútil ou mais do que rápido. completamente interativo, mas gera as imagens mais feias com raios vazando em todos os lugares devido à falta de raio / tri interseção à prova d'água. A velocidade é indiscutivelmente a principal métrica de qualidade de tal software, sem dúvida até mais do que correção em algum ponto (já que "correção" é uma idéia difusa com raytracing desde que tudo está se aproximando, desde que não esteja batendo ou algo parecido). E quando esse é o caso, se eu não pensar na eficiência inicial, eu acho que tenho que realmente mudar o código no nível de design mais caro para lidar com designs mais eficientes. Então, se eu não pensar suficientemente sobre eficiência ao projetar algo como um raytracer ou motor de física, é provável que eu tenha que reescrever a coisa toda antes que possa ser considerada útil o suficiente na produção e pelos usuários reais, não por os engenheiros.

O jogo é outro campo semelhante ao meu. Não importa o quão correta é a lógica do seu jogo ou quão fácil e fácil é manter sua base de código se o seu jogo for executado a 1 quadro por segundo, como uma apresentação de slides. Em determinados campos, a falta de velocidade pode realmente tornar o aplicativo inútil para seus usuários. Ao contrário dos jogos, não há métricas "boas o suficiente" em áreas como o raytracing. Os usuários sempre querem mais velocidade, e a concorrência industrial é predominantemente na busca de soluções mais rápidas. Isso nunca será bom o suficiente até que seja em tempo real, em que os jogos estarão usando rastreadores de caminho. E então provavelmente ainda não será bom o suficiente para efeitos visuais, desde então os artistas podem querer carregar bilhões de polígonos e fazer simulações de partículas com auto-colisão entre bilhões de partículas a 30+ FPS.

Agora, se é de algum conforto, apesar disso eu ainda escrevo cerca de 90% do código em uma linguagem de script (Lua) sem nenhuma preocupação com o desempenho. Mas eu tenho uma quantidade anormalmente grande de código que realmente precisa percorrer milhões para bilhões de coisas, e quando você está passando de milhões a bilhões de coisas, você começa a notar uma diferença épica entre código ingênuo de thread único que invoca uma falha de cache a cada iteração vs., digamos, código vetorizado sendo executado em paralelo acessando blocos contíguos onde nenhum dado irrelevante é carregado em uma linha de cache.

Para ser honesto, depende de qual é o seu objetivo e se você está programando profissionalmente ou como hobby.

Hoje em dia, os computadores modernos são máquinas realmente poderosas. Independentemente de quais operações básicas você decidir fazer, se você está tentando otimizar micro ou não, elas podem tornar seu trabalho notavelmente rápido. Mas, claro, se você está fazendo outra coisa (por exemplo, supercomputação para campos como física ou química), você pode querer otimizar o quanto quiser.

Os primeiros programadores do MIT não nasceram para fazer coisas incríveis; Eles começaram a simplificar e alimentar algoritmos existentes. O orgulho deles era fazer com que o 2 + 2 desse quatro em dois segundos a menos que o algoritmo existente (isso é apenas um exemplo, você entendeu a ideia). Eles constantemente tentaram usar menos cartões perfurados nas suas máquinas TI-83 para desempenho.

Além disso, se você estiver programando para sistemas embarcados, certamente terá que ficar de olho no micro desempenho. Você não quer ter um relógio digital lento que marca um segundo 5 nanossegundos antes de outro relógio digital.

using an O(N2) vs O(NlogN) algorithm on a 100 item list.

Eu estava em uma situação semelhante recentemente. Eu tinha uma série de itens. No caso esperado, havia dois (!) Itens na lista e, mesmo no pior dos casos, eu não esperava mais do que quatro ou oito.

Eu precisava classificar essa lista. Acontece que substituir std::sort por uma rede de classificação (basicamente muitos if s aninhados) reduziu uma grande porcentagem do tempo de execução (não me lembro do número, mas era algo como 10-20%). Este é um benefício enorme de uma micro-otimização, e o código é absolutamente crítico para o desempenho.

Claro, eu só fiz isso depois de perfil. Mas o ponto é, se eu usar uma linguagem que é tão inconveniente e complicada como C ++ (para não mencionar suas regras irritantemente complexas para resolução de sobrecarga), então eu quero colher todos os benefícios.

Uso de energia cumulativa

Há uma resposta que eu sempre acho que está faltando nessas discussões e que me incomoda um pouco - uso cumulativo de energia .

Claro, talvez não importe muito se você escrever seu programa em uma linguagem interpretada de alto nível e deixá-lo rodar em um navegador com algumas camadas de indireção, ou se seu loop demorar 0,01 segundos ao invés de 0,001 segundo. Ninguém notará, ou seja, nenhum usuário individual notará.

Mas quando dezenas de milhares, ou mesmo milhões de usuários, em alguns casos usam seu código, toda essa ineficiência extra é acrescentada. Se a sua ferramenta impedir que uma CPU entre no estado de suspensão por apenas dez segundos por dia e um milhão de usuários a usem, seu algoritmo ineficiente acabou gastando um extra de 140 kWh ^[1] por dia.

Eu raramente vejo isso discutido, e acho isso triste. Eu suspeito strongmente que os números são muito piores para frameworks populares, como o Firefox, e aplicações web interativas sofisticadas, e seria interessante pesquisar.

^{[1] Acabei de fazer isso, 10 milhões de segundos vezes 50 Watts. O número exato depende de muitas coisas.}

Como você mencionou, o cuidado com os problemas de micro desempenho é inútil antes de considerar alguns problemas realmente causados por esses problemas

É realmente impossível responder a essa pergunta em geral. A maioria dos softwares que estão sendo construídos hoje são sites internos e aplicativos LOB, e para esse tipo de programação seu raciocínio é bem correto. Por outro lado, se você está escrevendo algo como um driver de dispositivo ou um mecanismo de jogo, nenhuma otimização é "prematura"; É provável que o seu software funcione em sistemas muito diferentes com diferentes restrições de hardware. Nesse caso, você deve projetar para o desempenho e garantir que você não escolha um algoritmo sub-ótimo.

Eu acho que o problema do programador, que se preocupa tanto com o desempenho, é que às vezes, em sua vida, ele precisava escrever código de micro desempenho, talvez com muita urgência, e ele aprendeu, aprendeu, aprendeu e, no final. ele conhecia muitas coisas e truques.

E agora é difícil esquecer, e sem a medição prévia, que mostra que ele não precisa se preocupar, ele está do lado seguro, usando código rápido.

É sempre bom mostrar seu conhecimento profundo, suas habilidades e alguns truques e reutilizar algo que você aprendeu. Isso faz com que você se sinta valioso, e o tempo, gasta aprendendo, valendo a pena.

Às vezes, na minha vida, aprendi que o incremento de prefixo é mais rápido ...

for (int i = 0; i < MAX; ++i)

... do que o incremento de postfix:

for (int i = 0; i < MAX; i++)

Agora, se o MAX é baixo, isso não importa, e se houver um trabalho real no loop, isso também não importará. Mas não há uma razão para usar a versão do postfix, mesmo que o compilador de hoje otimize o código por conta própria.

Talvez os que buscam desempenho precisem de um objetivo adicional, além de escrever 'código de trabalho', como 'código de trabalho e legível', para ter uma diretriz no grande mar de opções.

have I just been lucky enough to not to have to worry too much about it, or am I a bad programmer?

Você se importa com suas necessidades? Se o desempenho não é um requisito, não se preocupe. Passar um tempo significativo é um desserviço ao seu empregador.

Até certo ponto, o desempenho é sempre um requisito. Se você pode acertar sem pensar, você está justificado em não pensar nisso.

Pessoalmente, sou mais motivado pelo desempenho quando meus testes demoram para passar. Eu sou muito impaciente para esperar 5 minutos enquanto um conjunto de testes passa. Mas isso geralmente é resolvido brincando com os testes.

My question is why is it that a large number of programmers care so much? Is it really an issue for most developers,

Há um grande número de programadores que se justificam em quanto se importam. Existem números grandes que não são. Vamos falar sobre aqueles que não são.

Uma das primeiras coisas que os programadores aprendem na escola, depois de como fazer as coisas realmente funcionarem, é uma grande notação. Muitos deles aprendem a lição corretamente e, portanto, concentram-se adequadamente em coisas dramaticamente impactadas por n. Outros não entendem a matemática e apenas tiram a lição de que, uma vez que ela funcione, ela precisa ser rápida. Pior, alguns desses alunos nunca aprendem mais sobre o que é importante fazer com o seu código, além de fazê-lo funcionar e fazer com que ele funcione rápido. As lições perdidas: tornar legível, projetar bem, não brincar por aí sem motivo.

Knuth estava certo: a otimização prematura é a raiz de todo o mal. Mas uma vez que funciona, qual é o próximo passo? Rápido certo? NÃO! O próximo passo é legível. Legível é o primeiro, o próximo, o meio e o último passo. Muitas das pessoas que acho que estão fazendo otimizações de desempenho desnecessárias estão jogando legibilidade sob o barramento.

Alguns até ficam perplexos com o quão ilegível é o código deles. Eles tiveram que sofrer olhando duro para entender o código criado por outros, então agora é a sua vez no retorno.

Eu sei disso porque eu costumava fazer isso. Certa vez, refacionei uma linha perfeitamente legível se estruturei até uma expressão booleana de uma linha indecifrável e orgulhosamente a enviei para o meu professor esperando impressionar, já que eu poderia criar algo tão compacto e intimidador. Eu não recebi o elogio que eu esperava.

Se o código permanecer legível, é mais fácil fazer isso rapidamente. É por isso que Knuth enfatiza "prematuro" e não "desnecessário". Porque com certeza, mais rápido é melhor. Mas melhor só é melhor dependendo do que você se sacrifica por isso. Então espere até que você saiba qual o desempenho que você realmente precisa antes de fazer sacrifícios por isso. Relutância do sacrifício porque, uma vez que tenha passado, é difícil voltar.

Além da legibilidade, está todo o mundo do design de software. O que este site é sobre. Alguns não têm ideia do que fazer no que diz respeito ao design. Então, como eles não podem impressionar com o design, eles fazem uma bagunça indecifrável, então as pessoas não podem dizer que não têm nenhuma pista. Como ninguém nunca conserta seu código, deve ser um bom código, certo?

Para alguns, o desempenho é pegar toda a desculpa para fazer o que quiserem. Os programadores têm muito poder e autonomia. Confiança foi colocada neles. Não abuse da confiança.