Taverna /dev/All

Conheça seus algoritmos - fim da lei de Moore, inchaço e desempenho

Tendências
#1

image

Acessando o site da ACM Queue hoje topei com este post fenomenal do Kode Vicious: “Know your algorithms” (https://queue.acm.org/detail.cfm?id=3310152) : temos uma questão essencial sobre escalabilidade aqui que é a comparação do custo de desenvolvimento vs custo de hardware.

Quando você olha para jogos mais antigos, tais como os que víamos, por exemplo, no Nintendo (NES) não há como não se maravilhar com o tanto que se conseguia fazer com tão pouco: basta observar que a esmagadora maioria dos jogos tinha menos de 1 Mb de tamanho (a esmagadora maioria tinha menos de 256 kb). Hardware, especialmente memória, era cara.

Com o passar do tempo o hardware foi barateando, memória começou a ficar bem mais acessível e a mão de obra encareceu. Então observa-se a aplicação da lei de Moore (https://pt.wikipedia.org/wiki/Lei_de_Moore) na qual você desenvolve um aplicativo meia boca sabendo que sairá uma versão mais nova do hardware há a chance real do sistema funcionar melhor: e funcionava.

Então hoje temos estes jogos com gigas de tamanho, por exemplo, assim como sistemas operacionais “giganormes” que te fazem pensar: caramba, será que este negócio não tá mal otimizado?

E no final das contas tudo se resume, e sairia bem mais barato e fácil se houvesse maior atenção ao código, aos algoritmos que empregamos em nossos sistemas que, inclusive, poderiam ser usados até mesmo para escolher melhor hardware, o que será fundamental agora que, ao que tudo indica, estamos chegando ao final da Lei de Moore (https://www.technologyreview.com/s/601441/moores-law-is-dead-now-what/).

Gostaria então de saber a opinião de vocês: estamos realmente otimizando nossos sistemas ou será que nos tornamos preguiçosos demais pra isto graças ao hardware que temos hoje? Esta festa está pra acabar? Se sim, quem sobreviverá?

ps: um texto fenomenal a respeito é este, Disenchantment - http://tonsky.me/blog/disenchantment/

1 Curtida
#2

Ainda tem gente que sequer cria os índices mais óbvios no banco de dados, e aí cada consulta é uma leitura full table scan em milhões de registros…

O uso irresponsável de ORMs e frameworks que multiplicam o processamento inútil em coisas simples…

Eu fico imaginando, além do desperdício de recursos computacionais, também o desperdício de recursos naturais, como a energia elétrica gasta inutilmente em cada uma dessas consultas, em cada um desses loops desnecessários, data centers inchados, mais uma vez, desperdiçando eletricidade e resfriamento (que em si já é um sintoma de desperdício).

Quantas instâncias desnecessárias de um sistema são criadas “na nuvem” por pura falta de otimização.

Mais um exemplo de desperdício, gerenciadores de janelas que precisam de gpu pra criar efeitos tridimensionais por conta de um alt-tab.

É, tô ficando ranzinza :slight_smile:

#3

sabe quando é que fica nítido o problema? No momento em que você inicia um computador bem antigo, tipo um MSX com um cartucho encaixado e o boot é instantâneo: um computador com 128 kb de RAM e um processador com menos de 10 Mhz.

Aí você liga seu PC com 8 Gb de RAM e uma CPU de 3 Ghz e vê a coisa lentamente sendo iniciada. Claramente há algo errado: nitidamente estamos atrasados, pra mim é óbvio que poderíamos estar cem anos luz à frente do que temos hoje.

Quando penso na própria Internet, nos protocolos que usamos (todos textuais essencialmente), a situação fica ainda mais nítida: podia ser muito mais eficiente, muito mais seguro, muito mais bem projetado.

Penso que hoje devíamos voltar aos primórdios e repensar toda a estrutura ao nosso redor: desde os sistemas operacionais, passando pelos protocolos, linguagens e até mesmo o modo como pensamos nosso código.

Também to ficando ranzinza. :slight_smile:

1 Curtida
#4

Bem lembrado, quando eu usava, já profissionalmente, visicalc ou dbaseII em máquinas de 8bits (rodando CPM, em clone de apple-II), eu não sabia o que era esperar pra abrir um programa. Claro, quando o sistema de contabilidade (que rodava num CP500) precisava de dois drives de disquete para ordenar os livros contábeis, aí ficava claro que o sistema não estava dando conta :slight_smile:

Nesse sentido, agora muitos anos mais à frente, era uma coisa legal compilar o próprio kernel de seu Linux. Mesmo que isso levasse um dia inteiro, a carga inicial era MUITO mais rápida. Mais tarde com os módulos dinâmicos, você só carregaria o que era necessário,mas mesmo assim, muita coisa inútil é carregada.

E ainda é desesperador dar um ps, ou um lsmod, ou ver o tamanho do kernel compilado.

Entendo retrocompatibilidade, entendo a imensidão de hardware que funciona cada um de um jeito, mas também entendo que uma máquina instalada deveria estar otimizada.

#5

Pra mim isso se resume em ‘obsolescência programada’.
Tanto de hardware quanto de software.

#6

Programo profissionalmente há mais de 10 anos e não me lembro de qualquer projeto em que a ordem de complexidade (https://en.wikipedia.org/wiki/Big_O_notation) de um algoritmo foi motivo de revisão. Infelizmente, existe uma geração de desenvolvedores que parte da premissa que os recursos de hardware estarão disponíveis em quantidade suficiente. Se não tiver, manda buscar…
É de suma importância incluirmos no nosso processo de revisão de código o consumo adequado de recursos, seja memória, rede ou do ORM nosso de cada dia.

1 Curtida
#7

Então o Java não é otimizado? ou os programadores não sabem usar Java?

Então vale a pena apostar na linguagem Golang do google?

Existem diversos cases de sistemas escritos em Java, Python que foram reescritos em Golang e tiveram uma absurda diminuição de custos com hardware e tempo de execução.

Vejam dois cases interessantes:

#8

A questão da troca de ambiente de desenvolvimento é realmente muito interessante: mas no caso de troca de linguagens, não sei se seria certo dizer que obtemos uma economia de recursos computacionais só por que trocamos de linguagem, mas sim por que estamos reescrevendo o sistema e, na esmagadora maioria das vezes, a segunda versão costuma ser bem melhor do que a primeira, por que não cometemos os mesmos erros neste momento.

No caso de linguagens portáveis, como o Java, por exemplo, que é executado sobre uma máquina virtual, há a possibilidade de ganhos de desempenho se você troca a JVM. Me lembro, por exemplo, muitos anos atrás, quando ainda existia a jRockit e haviam relatos de ganhos de desempenho.

Recentemente algo similar está ocorrendo, com a emergência da GraalVM, que promete estes ganhos também.

Por outro lado, já vi ocorrer também o contrário (voltando à mudança de linguagens): sistemas originalmente feitos em Cobol que não escalaram ao serem reescritos em Java no processamento em lotes.

Sendo assim, acho que a premissa é que se mantém: pra obter bom desempenho antes de mais nada tem de ter conhecimento de base mesmo. Algoritmos, estruturas de dados, padrões de projeto.

1 Curtida
#9

Acredito que tudo depende de avaliar o contexto.

Por exemplo, trocar a linguagem de programação de um e-commerce quando o principal gargalo, provavelmente, está na má utilização do banco de dados, não irá resolver o problema. O que vejo acontecer, na maioria dos casos, é o que o @kicolobo comentou, no momento da reescrita de uma linguagem para outra os erros arquiteturais da aplicação são resolvidos com uma abordagem diferente, onde a troca de linguagem foi apenas um dos detalhes.

2 Curtidas

itexto