- Se a otimização de software realmente for a prioridade, mais sistemas do que se imagina poderão funcionar até mesmo em hardware antigo
- Se os sinais de preço de mercado atuarem sobre recursos computacionais escassos, aumentará a pressão para criar software mais eficiente
- Um exemplo disso é refazer produtos baseados em linguagens interpretadas e microsserviços como uma base de código nativa monolítica
- Mas sem computação ultrabarata e altamente escalável, pode se tornar muito mais raro experimentar e lançar novos produtos inovadores
- Só a otimização de desempenho não basta; computação barata e escalável é o que determina a frequência de experimentação e lançamento de produtos
Experimento mental com prioridade na otimização
- Se a otimização de software realmente for a prioridade, mais sistemas do que se imagina poderão operar sobre hardware antigo
- Se os sinais de preço atuarem fortemente sobre recursos computacionais escassos, o mercado passará a exigir software mais eficiente
Formas possíveis de implementação e limitações
- Um exemplo é refazer produtos baseados em linguagens interpretadas e microsserviços como uma base de código nativa monolítica
- Ainda assim, sem computação ultrabarata e altamente escalável, novos produtos inovadores podem se tornar muito mais raros
1 comentários
Opiniões no Hacker News
É possível argumentar que o mercado compra software cheio de bugs e ineficiente tão bem quanto software bem-acabado, e que um dos dois é o software mais barato possível de se produzir
Isso se parece com a história do “mercado de limões”. O mercado vende todos os produtos como se fossem de alta qualidade, mas reduz discretamente a qualidade para cortar o custo marginal. Como o comprador não consegue distinguir alta qualidade de baixa qualidade antes da compra, a demanda fica artificialmente parecida, e a causa é a assimetria de informação
Em IA, isso já acontece e vai piorar. Usuários não conseguem diferenciar um app sofisticado de aprendizado de máquina de chamar o ciclo de centrifugação de uma lavadora de IA. O próprio rótulo de IA cria um prêmio de preço, e o usuário acaba pagando muito a mais pela lavadora
Pagar a mais acreditando que um software bagunçado foi projetado e escrito por técnicos e especialistas é essencialmente a mesma coisa. 99% do software é escrito por IC1~3, e na maioria das empresas de tecnologia uma única pessoa de QA é o único mecanismo que eleva a qualidade além de “atende aos critérios de aceite”. Às vezes um bando de estagiários recita o mantra “LGTM”, mas até isso é raro
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
Eu tinha certeza de que um produto melhor convenceria as pessoas e cresceria viralmente, mas não foi o que aconteceu. Cresceu, mas tão devagar que o dinheiro acabou em poucos anos, antes de atingir o ponto de equilíbrio
O que percebi é que, em um mercado competitivo, baixo custo — e portanto baixa qualidade — é uma vantagem competitiva. Quanto maior fica a escala do produto, maior fica a pressão para reduzir custos, e como as pessoas querem coisas baratas, alguém corta “custos”, ou seja, qualidade, para torná-lo mais barato. A empresa paga apenas o mínimo necessário para sobreviver e dar lucro
Empresas jovens às vezes tentam fazer alta qualidade ou aumentam os gastos por um tempo, mas no fim surge uma tendência de escorregar para uma mediocridade estável. Isso é um pouco diferente de um mercado de limões e parece levar mais à mediocridade espalhada por toda parte do que a um colapso de mercado
Mas, se você pedir a uma pessoa comum para escolher entre o Slack e o Weechat, um cliente IRC rápido, é provável que ela veja a UI de terminal, a ausência de chamadas de vídeo, de integração com webhooks e de avatares ou emojis personalizados como baixa qualidade
Desempenho também é uma funcionalidade. Um grande motivo pelo qual o Internet Explorer perdeu para o Chrome foi que, na época do lançamento, o Chrome era muito mais rápido, e o fato de desenvolvedores Python estarem migrando rapidamente para uv/ruff também se deve à melhoria de desempenho. Mas, quando a execução do Slack leva 5 segundos em vez de 10 ms, pouquíssimas pessoas se importam
Isso às vezes acontece com software cheio de bugs, mas, em geral, as pessoas querem pagar menos e, no processo, aceitam alguns bugs. Basta pensar em quanto seria preciso cobrar para seguir um processo em que cada linha de código é revisada por vários engenheiros e se gasta muito tempo com QA rigoroso
Quando eu morava em Padova, fiz um software para uma pequena livraria; como era para um amigo, fiz rápido e não cobrei muito. Não era perfeito, mas eu corrigia quando surgia um problema, não havia muitos problemas, e meu amigo ficou satisfeito com o acordo. Como sabia que estava pagando barato, também tinha paciência
Eu disse várias vezes que, se nossa equipe dissesse a um cliente “o projeto está concluído, mas tem tantos bugs e pesadelos de UI quanto essa plataforma de back-office”, seríamos repreendidos e rebaixados ou demitidos
Isso inclui empresas como o Google, que têm pouco suporte humano. O suporte aparece em várias formas: há informações como documentação, vídeos e blogs; há pessoas que ajudam, como em “mãe, é assim que se usa o Google”; há suporte ao alvo de uso, como sistema operacional, navegador e formatos; e há também algo como o Excel, que sustenta o próprio jeito como trabalho
Por fim, há pessoas reais. Esse é o fator número 1 que mantém vivo até o pior ERP da face da Terra. Marketing e vendas também são sinais de que existe suporte. Para clientes corporativos, ver apenas engenheiros pode ser um mau sinal. Desenvolvedores muitas vezes não conseguem fazer outras coisas, e essas outras coisas são um suporte importante
Mesmo um bom produto morre se não tiver suporte. Para competir com produtos piores, é sensato reduzir a necessidade de suporte — bugs, problemas de desempenho, plataformas — a fim de diminuir o custo da minha equipe, mas é indispensável acrescentar suporte em outras dimensões. Para uma equipe pequena, o mais fácil é alocar o recurso de suporte mais escasso: pessoas; depois disso, é preciso criatividade
Também é preciso comunicar bem os pontos fortes. Algumas pessoas valorizam mais certos tipos de suporte, como “poder ter o código vs. produto proprietário”. Muitas pessoas preferem um produto proprietário com suporte a ter o código
Desde 1980, costuma-se considerar que o desempenho computacional aumentou cerca de 1000 vezes
Mesmo que a verificação de limites de arrays dinâmicos custe 5%, na prática é bem menos que isso; se ela fosse ativada em todos os lugares, os computadores seriam “só” 950 vezes mais rápidos
Se voltássemos a 1980 e pedíssemos para escolher entre “um computador 950 vezes mais rápido, sem uma grande classe de vulnerabilidades de segurança de memória e com depuração algumas ordens de magnitude mais fácil” e “um computador 1000 vezes mais rápido, mas com software ainda cheio de bugs, ou pior, e depuração de pesadelo”, as pessoas teriam ficado chocadas mesmo com apenas 950 vezes
Só que o que escolhemos foi a segunda opção e, pessoalmente, acho que a turma dos 1000 vezes estragou tudo para o resto
No fim, quando eles o otimizaram para rodar de forma eficiente no Sparc 20, a empresa passou a ter uma base para vencer em um mercado mais amplo. Otimização deve ser tratada como vantagem competitiva e, em alguns casos, pode ser a vantagem competitiva mais importante
Por isso, se a verificação de limites for obrigatória, essa linguagem perde competitividade em certas tarefas
Na grande maioria dos casos isso não importa nem um pouco e fica muito abaixo de 5%. Acho que uma boa solução é separar escopos seguros/inseguros ou gerais/de desempenho
CPUs mainstream estão mais próximas de ser 1 milhão a 2 milhões de vezes mais rápidas que máquinas dos anos 80. Por algumas centenas de dólares, ainda dá para comprar um computador corporativo recondicionado na faixa de 1 milhão de vezes mais rápido
O fenômeno de os computadores atuais serem lentos e parecerem lentos não acontece simplesmente porque os computadores sejam lentos, mas ainda assim acontece. Parte da causa é que linguagens de script continuam alocando memória para pequenas operações e, por causa da tipagem dinâmica, precisam seguir ponteiros para cada variável; também há pessoas usando programas extremamente ineficientes em ambientes já ruins
A maioria dos programas hoje é escrita não do jeito que o usuário gostaria, mas do jeito que o autor quer trabalhar. Muita gente não tem noção de otimização nem de quais coisas rodam mais rápido; depois de fazer funcionar, pensa: “então este programa tem essa velocidade”
A própria ideia de que o mesmo software poderia ficar mais rápido é uma forma de pensar de nicho, e nem mesmo no Hacker News todo mundo pensa assim
Linguagens com coleta de lixo muitas vezes usam várias vezes mais memória. Elas não liberam imediatamente a memória que já não é usada e, para começo de conversa, tendem a exigir mais alocações
Trabalhar no Google e no Facebook me fez perceber como hardware é barato e como, na maioria dos casos, otimizar código tem pouco valor
O Google começou a gerenciar o uso de recursos de data center há mais de 10 anos, e cada projeto tinha orçamentos para coisas como núcleos de CPU, espaço em disco rígido, armazenamento flash, spindles de disco e memória. Em geral, esses recursos podiam ser convertidos entre si, então era possível ver o custo relativo
Na época, armazenamento flash era cerca de 20 vezes mais caro que disco rígido, mas por causa de gargalos de spindles muitas vezes saía mais barato no custo total
Tudo isso podia ser convertido em “mili-SWE”, ou seja, um milésimo do esforço de um SWE trabalhando por um ano. Um projeto podia economizar hardware e contratar mais pessoas, ou contratar menos pessoas e receber mais hardware dentro do orçamento atual
Não me lembro exatamente quantos núcleos de CPU correspondiam a 1 SWE, mas acho que eram milhares. Se você gastar um ano de trabalho de um SWE otimizando um projeto inteiro e não economizar 5000 núcleos de CPU, é prejuízo líquido
Projetos muito grandes usavam muito mais do que isso, então a otimização fazia sentido; mas, especialmente se havia grande chance de o código escrito ser substituído algum dia, muitas vezes otimizar não era a escolha certa
Por outro lado, a web tem um problema geral de usabilidade. A web não deveria consumir tantos recursos quanto consome hoje. Quem conhece alguém que já trabalhou com entrada de dados sabe que o mouse é bastante ineficiente. Terminais baseados em texto de 30 a 40 anos atrás ofereciam interfaces muito eficientes consumindo pouquíssimos recursos
Eu achava que um dia a web seria “resolvida”, no sentido de que a stack tecnológica geralmente esperada ficaria definida e passaríamos para outros problemas, mas isso não aconteceu. Ainda existe o “framework da semana”, e fazemos a idiotice de reimplementar em código de usuário barras de rolagem que não funcionam direito com a roda do mouse. Não sei como esse problema poderia ser resolvido, nem se ele sequer pode ser “resolvido”
O Google dedicou esforço enorme a dois outros aspectos de desempenho: latência e utilização geral dos equipamentos. Ambos vieram como diretrizes de cima, consumiram tempo e atenção de milhares de engenheiros e também tiveram alto custo de pessoal
Mas, se equipamento é a restrição, mesmo que cada núcleo individual seja barato, você não quer deixá-lo ocioso sem motivo. O custo de oportunidade de esperar a construção de um novo data center é grande. Se o uso é muito sensível a latência, faz sentido cortar milissegundos não para reduzir custo de hardware, mas por causa de métricas de negócio
A avaliação deve ser feita pelo custo marginal. Mesmo que economize só alguns centavos por ano para cada dólar, ainda é melhor fazer esse trabalho do que deixar um engenheiro ocioso
O problema é que quase ninguém faz isso. O modo de decisão não tem relação com cálculo econômico; a maioria simplesmente copia “o que o Google faz”. Isso explica muitas disfunções
Mas empresas comuns, até grandes empresas, não chegam a esse ponto. Parece um exemplo clássico de que “Facebook/Google/Netflix etc. são uma classe à parte, e a maior parte das práticas deles não funciona para você”
Dá para imaginar um universo alternativo em que recursos humanos são despejados em otimização, mas esse universo seria completamente diferente do atual. Cada engenheiro a mais em otimização é um engenheiro a menos em desenvolvimento de funcionalidades. Para quê? Para economizar alguns ciclos de CPU? Dá vontade de rir
Só pelo título, achei que Carmack estivesse criticando software mal otimizado e defendendo melhorar o desempenho em hardware antigo
Os tweets de fato não são nada disso: eles tratam de um experimento mental em que o avanço do hardware parou, e concluem que “sem computação escalável de baixíssimo custo, produtos novos inovadores naturalmente seriam muito mais raros”
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
Eu vejo o contrário: nos 18 anos desde os smartphones, vimos pouca grande inovação, porque o capital se apoia no avanço do hardware para vender aos consumidores produtos que, em essência, são iguais ao que eles já têm
Claro, depois do primeiro tweet eu não consegui ler
Haverá estagnação, mas não uma estagnação contínua
Se é possível contratar pessoas e torná-las produtivas com linguagens menos complexas, o mercado de trabalhadores se amplia e os custos caem
No texto original, Carmack basicamente argumenta que “bons desenvolvedores inteligentes são caros e há coisas maiores a fazer, então não se paga para que eles otimizem código e sistemas até o fim, e por isso o software é lento”
Portanto, a implicação é que, se bons desenvolvedores de repente ficassem muito baratos, todos os comprariam e os colocariam para otimizar, e muito software poderia ficar subitamente mais rápido. Então por que bons desenvolvedores poderiam de repente ficar baratos?
Seria bom se pudéssemos estender a vida útil do hardware por 5 ou 10 anos além da “obsolescência programada”
Isso reduziria muito o lixo eletrônico, manteria terras-raras no subsolo e também diminuiria bastante as emissões de gases de efeito estufa
Mas as forças de mercado da produção de software não pagam por essas externalidades. É muito mais barato lançar rápido, testar e iterar do que planejar e projetar visando desempenho. Algumas organizações da indústria de games encontraram uma fórmula para obter bom desempenho e boas vendas ao mesmo tempo, mas isso não se espalhou de forma uniforme
Em software corporativo e de consumo, não há grande incentivo para colocar critérios de desempenho nos requisitos. Projeta-se para o nível que os usuários conseguem tolerar e, como é preciso continuar lançando mudanças e recursos, deixa-se a maior folga possível. Toda mudança é uma dívida que pode afetar desempenho e satisfação do usuário, então reserva-se margem no orçamento para lidar com taxas de erro
É bem diferente da forma de projetar e desenvolver a portas fechadas “até estar pronto”
Deveríamos ter uma economia centrada em cuidado e manutenção, e alinhar nossos esforços macro em torno do bem de toda a humanidade, não da riqueza percebida de poucos
Se tivéssemos nos concentrado em manter veículos antigos, reutilizar computadores antigos etc., os aterros teriam sido menores em relação ao crescimento
Claro, imagino que também exista uma construção de teoria dos jogos mostrando que o preservacionista é uma estratégia objetivamente inferior
Já faz mais de 10 anos que é possível rodar o mecanismo de casamento de ordens de uma bolsa inteira em uma única thread
Acho que a capacidade de computação para uma certa classe de processamento de transações estritamente serializado não cresceu tão rápido quanto outros indicadores sugerem. Adicionar 31 núcleos não torna um mecanismo de casamento de ordens mais rápido; pode até deixá-lo mais lento
Se o produto processa menos de alguns milhões de transações por segundo e ainda assim está procurando um cluster de máquinas, é preciso dar uns 15 passos para trás e recomeçar do zero
O projeto original ainda teria atendido 99% dos casos de uso, e, considerando a capacidade de computação local de hoje, daria até para rodar o mercado inteiro em uma única máquina
Será que simplesmente não há computação suficiente além de ordenar por tempo e preço?
Se fosse necessário um processamento mais complexo por transação, não daria para processar tantos casos. Mas é difícil imaginar que processamento mais complexo seria necessário sem ser alguém daquele domínio
É verdade. Isso é um problema econômico, ou seja, um problema de alocação de recursos
É uma escolha entre fazer alguém gastar mais tempo otimizando software ou criar mais funcionalidades. Se a segunda opção gerar mais dinheiro, vão mandá-lo fazer isso; se a primeira se tornar importante para o fluxo de caixa, vão mandá-lo fazer isso
Este é um caso claro de externalidade negativa que as empresas de software impõem ao público. Como a maioria das empresas de software não paga o custo real da energia, do tempo perdido e do lixo eletrônico adicional, elas não se importam com otimização
Muitas vezes uma otimização rigorosa não faz tanto sentido, mas a ideia de simplesmente adicionar mais servidores em vez de reescrever é um estado triste
Não uso a maioria dos novos recursos do macOS, Windows e Android. O que quero é um ambiente eficiente para rodar apps e melhorias de segurança. Várias melhorias, como o app Ajustes do macOS, também não são muito satisfatórias
Com software de design é a mesma coisa. Não uso a maioria dos novos recursos que a Adobe colocou, e poderia estar perfeitamente feliz com o Illustrator ou o Photoshop de 10 anos atrás. O que quero é software menos inchado
Em áudio e produção musical, o fluxo de trabalho ainda está melhorando, então quero recursos novos, mas não ao custo da eficiência
Para editores de código, os recursos do VSCode já são suficientes. Não preciso de mais nada; quero LSPs melhores, mas isso não é o núcleo do editor. Só queria que o VSCode fosse mais rápido e consumisse menos memória
Otimização de software é atraente de um jeito parecido. Mas, se o problema for “gastar algumas horas de engenharia cara otimizando” versus “colocar mais RAM barata”, a opção mais barata vence. Às vezes o problema é grande o bastante para valer a pena otimizar
O mercado decidirá qual escolha vale a pena perseguir. Quando chegarmos aos retornos decrescentes de simplesmente jogar mais hardware no problema, vamos otimizar software. A Lei de Moore está desacelerando, mas parece que ainda não chegamos a esse ponto
Mas a realidade parece mais próxima do contrário. Se vier com um preço menor, eles também vão preferir uma versão com desempenho pior
Mais do que uma refutação ao Carmack, há um exemplo concreto em que penso de vez em quando
Apps Electron ficam em algum lugar entre algo que os consumidores toleram e algo que odeiam por problemas de desempenho, mas provavelmente foram a única inovação que tornou prático usar um notebook Linux no trabalho. Por exemplo, poder entrar em uma reunião do MS Teams sem instalar nada é realmente útil
Então todo mundo lamenta que hoje em dia não há nada tão densamente codificado quanto o Winamp, mas esquece as três primeiras letras
Há uma boa chance de ele rodar também no Linux, mas software Electron é péssimo em qualquer plataforma
Em 2010, eu trabalhava como faxineiro e fazia o trabalho de responsável por TI como um bico
Na época, disse à empresa que notebooks dos últimos 5 anos, mais ou menos qualquer coisa de Nehalem em diante, tinham desempenho suficiente para trabalhar com planilhas. Era basicamente só isso que eles faziam, e 2 núcleos, 16 GB de RAM e um SSD SATA de 500 GB bastavam. Só algumas pessoas de marketing precisavam de máquinas um pouco mais fortes, mas não era uma diferença grande, e economizamos muito dinheiro por não comprar notebooks topo de linha de última geração
Hoje não trabalho mais lá, mas tenho certeza de que aqueles computadores ainda deveriam ser perfeitamente bons para planilhas. O fluxo de trabalho não mudou muito; o que mudou foi o software. Se tivessem continuado atualizando, nem sei se hoje conseguiriam “rodar” MS Windows 10 ou 11, mas é bem provável que a produtividade tenha caído bastante por causa do inchaço e, especialmente, das planilhas exclusivamente online
A internet de lá também era horrível. As opções eram um DSL assimétrico de cerca de 16 Mbit por US$ 300 por mês, por ser “empresarial”, ou cabo Comcast de 120 Mbit por US$ 500 por mês. Mesmo 120 Mbit mal dá conta de planilhas somente online, e 16 Mbit certamente não basta. Pior ainda é que, se a internet cai, o negócio para
É exatamente isso que outro comentário chamou de roubo, e concordo totalmente. Não há motivo algum para um notebook que edita e atualiza planilhas em um escritório exigir internet, recursos absurdos de computação/armazenamento ou muita largura de banda
Não há desculpa para o desempenho terrível dos computadores de hoje além de repassar o custo aos clientes, tanto pessoas físicas quanto empresas
https://news.ycombinator.com/item?id=43971960
O mundo funciona em cima de funcionalidades, não de software elegante, rápido e sem bugs
Para o usuário final, não há diferença entre não ter uma funcionalidade e haver um bug. Também não há diferença significativa entre levar 5 minutos para concluir uma tarefa por causa de desempenho ruim e o usuário ter de fazer manualmente a mesma coisa por 5 minutos porque a funcionalidade não existe. Ambos são “lentidão”
Se você continuar maximizando o valor para o usuário final, inevitavelmente acabará criando software lento e cheio de bugs. Além disso, se você perguntar aos usuários se eles preferem menos funcionalidades em troca de algo mais rápido e com menos bugs, surpreendentemente eles dizem que não. Mais importante ainda: no mundo corporativo, muitas vezes quem compra o software não é o usuário final, e essas pessoas querem mais funcionalidades e menos desempenho e elegância
Com o mesmo conjunto de funcionalidades, usuários e compradores escolheriam o software mais rápido, com menos bugs e mais elegante. Mas, se faltar uma única funcionalidade, ele perde. O motivo para manter o software rápido e elegante é que isso maximiza a chance de continuar adicionando funcionalidades sem virar um produto com menos recursos
Uma solução rápida e elegante pode receber boas avaliações e elogios por ser agradável de usar. Por isso, pode parecer um fator importante. Mas, no fim, se ela não faz o que a pessoa quer, ela nem compra. Se houver uma funcionalidade essencial necessária, ela escolherá uma bagunça lenta, irritante e cheia de bugs
Também é preciso lembrar que a Microsoft agora precisa arrastar os usuários, aos chutes e gritos, para a próxima versão do Windows. Se a decisão ficasse por conta deles, muita gente não teria atualizado depois do Windows XP. Mesmo com várias funcionalidades novas e bonitas nas versões posteriores
Concordo que empresas e investidores querem funcionalidades em si, mas os usuários certamente não
Se pudessem, ninguém mais atualizaria nada. Basta ver o quanto a Microsoft se esforça para fazer as pessoas atualizarem. Nunca ouvi alguém dizer que queria uma nova versão do Windows, Office, Slack, Zoom etc.
Esse também é o motivo de tudo, como o Photoshop, ser forçado para a nuvem. A grande maioria das pessoas não quer as novas funcionalidades oferecidas, e isso inclui compradores corporativos. A resposta para manter a receita é fazer as pessoas comprarem, independentemente de oferecer ou não funcionalidades
Mas usuários existentes já estão fazendo o que precisam com o software, então novas funcionalidades podem permitir eliminar outro software ou fazer algo novo. Porém, se esse novo algo fosse realmente extremamente importante, eles já teriam encontrado outro software para isso, o que significa que conseguiram viver sem ele até agora. Por isso, acho que, se usuários existentes fossem realmente reflexivos, primeiro pediriam melhorias de desempenho e talvez algumas pequenas melhorias
Por outro lado, usuários potenciais ainda não conhecem o software ou precisam de alguma outra funcionalidade antes de achá-lo útil. São eles que procuram novas funcionalidades de forma racional
Portanto, a decisão “funcionalidades vs. desempenho” também é um sinal de se a prioridade do desenvolvedor é conquistar novos usuários ou satisfazer os existentes. É natural que pessoas técnicas prefiram a segunda opção. Elas já passaram por esse jogo e sabem que querem ser prioridade durante o longo período em que realmente usam o produto, não durante a aquisição
Software cheio de bugs e lento, mas rico em funcionalidades, domina o mercado também porque as empresas priorizam crescimento primeiro. A história está cheia de softwares bonitos e elegantes dos quais os usuários sentem saudade, mas que não se espalharam o suficiente para sustentar a empresa
A troca existe de verdade nos dois sentidos. A maioria das pessoas passa mais tempo como usuário do que como usuário potencial. É muito provável que isso seja uma grande causa da percepção geral de que o software e os computadores de hoje são inacreditavelmente ruins
O dinheiro gasto em RAM e CPUs melhores em computadores domésticos e de escritório permite que todo o software que roda neles seja lançado mais barato e com mais funcionalidades