- Mais sistemas do que muita gente imagina conseguem funcionar muito bem em hardware antigo
- Se houver otimização de software de verdade, é muito provável alcançar esse nível de eficiência
- Os sinais de preço de mercado de recursos computacionais escassos incentivam a eficiência de software
- Há necessidade de migrar produtos existentes de microsserviços baseados em interpretadores para uma arquitetura monolítica construída em código nativo
- Por outro lado, sem recursos de computação muito baratos e escaláveis, é provável que o desenvolvimento de novos produtos inovadores aconteça com muito menos frequência
1 comentários
Comentários no Hacker News
Dá para argumentar que, no mercado, software cheio de bugs e ineficiente vende tão bem quanto software perfeito; um dos dois é simplesmente o software mais barato de produzir. Isso se parece com a história do “mercado de limões”: o mercado negocia como se todos os produtos fossem de alta qualidade, mas na prática sacrifica qualidade para reduzir custos. Como o comprador não consegue distinguir alta de baixa qualidade antes da compra, a demanda pelos dois fica artificialmente parecida; isso acontece por assimetria de informação. Esse fenômeno já é real e está ficando cada vez mais real também em IA. O usuário não consegue diferenciar uma aplicação sofisticada de machine learning de uma máquina de lavar que só leva o nome de “AI”. O rótulo AI por si só gera prêmio de preço, então o usuário paga caro demais pela máquina de lavar. Cobrar por um software ruim porque o comprador acha que é “software projetado e escrito por especialistas” é, no fundo, a mesma coisa. Quase todo software é escrito em nível IC1-3, e a pessoa de QA acaba sendo, sozinha, o único indicador de melhora de qualidade na maioria das empresas. Às vezes ainda se espera melhoria com estagiários recitando o mantra “LGTM”, mas na prática nem isso é comum
Tentei criar uma startup de software diferenciada por qualidade; eu tinha certeza de que, se o produto fosse melhor, as pessoas perceberiam e ele teria sucesso, mas na prática não foi assim. Houve crescimento, mas lento demais, e o caixa acabou antes de dar lucro. O que percebi é que custo baixo, e portanto qualidade baixa, vira vantagem competitiva em mercado competitivo. Eu ouvia isso desde a faculdade, mas só senti até os ossos depois dessa experiência. É por isso que tudo no mercado tende ao mediano, e por isso até produtos populares pioram em qualidade. Quanto mais um produto cresce, maior a pressão para cortar custos. As pessoas querem comprar barato, então alguém corta custo (qualidade) para vender mais barato. As empresas pagam só o mínimo necessário para sobreviver e lucrar. Claro, às vezes há exceções, mas no fim a tendência é de redução gradual de custos. Deve haver até um nome para isso; é um pouco diferente do mercado de limões. O mercado não colapsa, mas cria uma mediocridade estável em todo lugar
Há uma contestação à ideia de que o “mercado” vende tudo como se fosse de alta qualidade. O importante aqui é o que significa “alta qualidade”. Parece que o sentido é “baixa qualidade se o desempenho for ruim”, mas na prática apps considerados lentos ou ruins de desempenho, como Teams, Slack e Jira, têm concorrentes com desempenho muito melhor. Só que, se você disser ao usuário para trocar o Slack por um Weechat sem vídeo, sem emoji e com UI de terminal, a maioria vai achar o segundo de qualidade inferior. Desempenho também é só uma funcionalidade. Por exemplo, o sucesso inicial do Chrome veio da velocidade, e desenvolvedores Python também migram para uv/ruff por ganho de desempenho. Mas se o Slack abrisse em 10 ms em vez de 5 segundos, a maioria dos usuários nem ligaria
Não concordo que software ineficiente exista por causa da estrutura de mercado de limões. Isso só vale quando há assimetria de informação. Na maior parte dos casos, as pessoas não se importam com alguns bugs e preferem um preço mais baixo. Se você passar por um processo de QA muito rigoroso e revisão de código por múltiplos engenheiros, quando comparar os preços fica bem claro. Já fiz um software para uma livraria pequena: foi feito rápido e eu não cobrei muito. Não era perfeito, mas sempre que surgia um problema eu corrigia na hora, e o cliente ficou satisfeito porque sabia que tinha feito um bom negócio
Já usei portais horríveis de RH, reembolso, controle de horas e seguros em grandes empresas. Eram tão ruins que eu ficava me perguntando se quem aprovou o pagamento realmente tinha usado o produto. Se um time entregasse aos clientes um produto cheio de bugs e com UI de pesadelo, isso seria motivo imediato para bronca, rebaixamento ou até demissão
A essência de o mercado comprar bem “software cheio de bugs e ineficiente” é que o mercado está comprando <i>suporte</i>. Isso vale até para Google ou para empresas com pouco suporte humano. “Suporte” aparece de várias formas — documentação, vídeos, informações em blogs, pessoas que ajudam, suporte ao meu ambiente de uso (sistema operacional, navegador etc.), suporte ao que eu quero fazer e assim por diante. O fator número um que mantém vivo até o pior ERP no fim das contas são pessoas reais. A presença ou ausência de suporte define a linha de morte do produto. Se um time pequeno quiser vencer essa disputa, é inteligente reduzir a “necessidade de suporte” e inserir suporte em outra dimensão. O jeito mais fácil é adicionar humanos. E é preciso comunicar bem os pontos fortes. Cada tipo de suporte é avaliado de forma diferente; por exemplo, código open source vs. código proprietário. Muita gente prefere o lado proprietário se houver mais suporte, mais do que se importa com o código em si
Uma das grandes razões de eu gostar de fazer compras no Costco é que eles geralmente não vendem coisas lixo. O filtro nem sempre bate com o meu padrão, mas ainda assim é um filtro de qualidade significativo
Mesmo que o usuário consiga decidir com base em qualidade e desempenho de software, se eu olhar minha lista de apps abertos, nenhum deles pode ser substituído simplesmente porque outro tem desempenho melhor. Por exemplo, uso Docker, iterm2 e WhatsApp por razões específicas. Mesmo que exista a solução mais rápida, não consigo trocar. A própria existência de um software que atenda minhas necessidades desde o início é um fator mais importante do que desempenho
99% do software é escrito sem considerar desempenho. Até no HN há uma tendência a tratar melhoria de desempenho como tabu. Mesmo engenheiros de nível L4/5 ou acima muitas vezes têm pouca noção de performance. Do ponto de vista do negócio, também não se liga para eficiência até o hardware deixar de conseguir rodar aquele software. E mesmo assim, a prioridade é resolver com mais hardware
A estrutura atual de mercado faz software cheio de bugs e ineficiente dominar porque sempre dá para comprar hardware e rodar. O software se expande para preencher a capacidade de processamento do hardware — é a lei do “o que Andy dá, Bill toma”. Por isso não há incentivo para criar software enxuto e de alta qualidade. Mas, se chegar um mundo em que não seja mais possível obter chips de ponta — por exemplo, por crise geopolítica ou destruição em massa de fábricas —, software que economiza recursos passa a ter grande valor econômico. Software inflado deixaria de rodar. Carmack diz que, numa situação dessas, ainda existe margem suficiente para otimização e no fim daria para fazer o software rodar até em chips antigos
Software bem projetado é fácil de substituir. Já um amontoado de código espaguete cheio de bugs ninguém quer tocar, então fica para sempre. Se olhar só pela ótica da evolução pura, o software ruim acaba dominando
O mercado de carros usados é um mercado de limões porque é difícil distinguir um carro bem cuidado de um prestes a quebrar. Mas o mercado de carros novos não entra nisso porque é rigidamente controlado. Software é sempre novo. Assim como a qualidade dos carros aumentou por décadas, a do software também pode aumentar. Dá para exigir que só seja vendido se cumprir certo padrão, fazer recall em caso de bug grave e punir a venda deliberada de produto defeituoso. Todas as outras indústrias funcionam assim
Graças ao Web 2.0 “beta perpétuo” e ao modelo SaaS, a tolerância do usuário também mudou. A Microsoft passou gerações incutindo a ideia de que “software naturalmente quebra”. Como todo mundo se acostumou a software ruim, acabou ficando difícil perceber o valor de software bom
Eu realmente comprei essa máquina de lavar com selo de AI. Achei o marketing engraçado, mas o preço era razoável, então comprei
Talvez isso esteja falando só de falhas de segurança. Se Excel ou Photoshop fossem cheios de problemas de desempenho e outros bugs, as pessoas largariam rápido. Mas segurança o usuário só percebe quando o problema já aconteceu, e mesmo se for invadido talvez nem saiba a causa. Não há incentivo para o desenvolvedor. Já desempenho, depois que passa de um certo nível, ninguém quer investir mais recursos em otimização. É a lei dos retornos decrescentes
Mesmo que o usuário não consiga diferenciar uma IA sofisticada de uma “máquina de lavar AI” de fachada, uma boa IA pode ajudar o próprio usuário a superar essa assimetria de informação. No fim, se existir uma maneira de escolher a boa IA, isso pode ser resolvido
Eu não acho que fazer “o software mais barato” seja necessariamente barato. Em nível de startup, algo feito nas coxas sai barato, mas em escala grande custa mais caro. Até companhias aéreas tentam cortar custo tirando uma azeitona do prato, então me pergunto por que otimizar com desenvolvedores não seria eficiente. A gente só adiciona recurso novo, mas no fim o usuário sente o software ficar mais lento a cada update. Em contrapartida, quando fica mais rápido, ele comemora. O engenheiro age como MBA e só repete que “não tem valor”, mas o “valor” de corrigir bug em software é bastante subjetivo. A missão do engenheiro é corrigir bugs. Marca também importa, mas as grandes marcas atuais ignoram seu valor de marca. Talvez porque o consumidor troque pouco, mas mesmo trocando ele só ganha uma nova UI e mais coisas para aprender, sem falar que até a Apple já não é intuitiva
O mundo de hoje até poderia rodar em hardware antigo, mas como CPU e hardware continuam ficando mais rápidos, não há motivo real para tornar o código mais eficiente
O problema de assimetria de informação pode ser superado em produtos FOSS ou proprietários de “shared source”. Se você olhar o código diretamente, consegue ver se a qualidade geral é boa. Mesmo sem encontrar bugs concretos, dá para perceber uma cultura de desenvolvimento responsável pelo tamanho das funções, comentários, nomenclatura etc. Quando você vê um produto proprietário caro com schema de banco todo bagunçado, a confiança simplesmente não aparece
Software ruim, no longo prazo, custa mais caro para produzir e manter
É por isso que se diz que a marca cumpre o papel de guardiã da qualidade
Assim como a lei proíbe vender comida tóxica, vencida ou com aditivos viciantes, software também deveria ser regulado. Mas, até a criação do GDPR, a regulação era quase inútil, e mesmo hoje violação ainda é rotina
O poder computacional aumentou cerca de 1000 vezes desde 1980. Se a perda de desempenho por checagem dinâmica de limites de array fosse de 5% — na verdade é bem menos —, mesmo com essa checagem ligada ainda poderíamos usar computadores 950 vezes mais rápidos. Se você voltasse a 1980 e perguntasse “você quer um computador 950 vezes mais rápido, com menos bugs e depuração mais fácil, ou um 1000 vezes mais rápido, ainda cheio de bugs e mais difícil de depurar?”, a maioria escolheria 950x. Mas acabamos escolhendo 1000x. Pessoalmente, acho que os 1000Xers estragaram a situação
Mas esse desempenho 1000x está sendo desperdiçado não com checagem de limites, e sim com abstrações sem fim e ineficiência
Já obriguei um fornecedor a fazer seu software lento e cheio de bugs rodar em um Sparc 20. O resultado foi que eles otimizaram o software, e isso virou a base para a empresa ter sucesso no mercado. Otimização é vantagem competitiva
Isso só vale desde 1980. Num vídeo recente, o resumo era: “os computadores de hoje não são tão mais rápidos do que os de 20 anos atrás, a menos que você otimize especificamente para sentir isso”. O autor ignorou coisas como otimização de compilador, mas na prática o ganho de desempenho foi bem mais modesto do que se imagina; ele falou em só 2x em 15 anos
Foi dito que checagem de limites de array custa só 5%, mas nem todo algoritmo é tão simples. Dependendo do número de operações, só introduzir essa checagem pode aumentar o custo em 3x ou 4x. Em certos usos, forçar checagem faz a própria linguagem perder competitividade. Na maioria dos casos isso não importa, mas me parece melhor separar entre modo seguro e modo normal
Se pensar só em checagem de limites, o custo é baixo, mas a sobrecarga de uma linguagem segura é bem maior. Linguagens com GC podem multiplicar o uso de memória em várias vezes
Não se pode esquecer a lei dos grandes números. Em um sistema só, perder 5% de desempenho pode não ser nada demais, mas se essa perda de 5% se acumula em todo o ambiente computacional do mundo, o impacto é enorme
Concordo com a natureza humana de preferir ganhos de curto prazo, mas checagem dinâmica de limites não resolve por si só o problema de segurança. Ainda não existe solução definitiva
A causa fundamental de termos chegado a isso é estarmos presos ao navegador
A primeira resposta é basicamente a correta. Só o fato de C continuar amplamente usado já mostra que o problema é uma estrutura ineficiente na base da pilha
Esse “5%” parece mal fundamentado. Não confio muito em qual critério foi usado para calcular esse custo. Também fico curioso se checar a cada atribuição em array não acabaria custando mais que o dobro na prática
Atualmente, a maioria das linguagens de programação já dá suporte a checagem de limites de array por padrão
Isso me lembra quando o Node.js apareceu. A grande vantagem era unir programação de cliente e servidor, mas hoje virou um pesadelo de segurança; então linguagens minimalistas com base de código menor também têm suas vantagens
Se tivéssemos percebido mais cedo que uma única string pode conter dados em escala de gigabytes, as strings terminadas em nulo teriam desaparecido e todo mundo teria sofrido menos
Na verdade, os 1000Xers que desfrutam de um produto 1000 vezes mais rápido são minoria extrema. O software de desktop que o usuário comum enfrenta continua lento
Na realidade, ficou algo como 100 mil vezes mais rápido. Só o clock subiu 1000x, os núcleos 10x, e as próprias instruções, com AVX e afins, mais 10x; estruturalmente ficou de 1 a 2 milhões de vezes mais rápido. E, ainda assim, isso não afeta a velocidade percebida
Cita Robert Barton chamando esse tipo de gente de “sumos sacerdotes de um culto degradado”
Desde 1980, sim, ficou rápido; mas olhando desde 2005, a melhora foi de cerca de 5x
O clock foi 2000x, SIMD e afins elevaram o IPC em 80x, e multiplicando pelos núcleos acaba dando algo entre 1 e 2 milhões de vezes mais rápido. Ainda assim, a maioria dos programas é escrita por gente que simplesmente pensa “se funciona, essa é a velocidade”. Pensar em otimização é coisa de uma minoria muito pequena, inclusive entre usuários do HN
Em 2001, um CPU de 1 GHz deveria ter sido o padrão de execução para software básico, mas até minha experiência com IA foi bastante decepcionante. Eu esperava que LLM conseguisse fazer bem coisas como transformação de linguagem e otimização de código, mas a realidade não é essa. Já pedi para uma IA portar código Unix sed para uma linguagem da JVM, e fora o básico ela falhou completamente em qualquer coisa de nível intermediário para cima. No fim, todo esse movimento tem como objetivo “reduzir empregos”, não melhorar a qualidade do software. A IA vai produzir ainda mais software ruim
Isso é exatamente o JavaScript, e o futuro do usuário
Trabalhando no Google (e no Facebook), deu para perceber como hardware é barato e como otimizar código na maior parte do tempo não vale a pena. Já há mais de 10 anos, no Google, gestão de recursos de datacenter era obrigatória e cada projeto tinha orçamento. Fazia-se trade-off entre CPU, HDD, flash e outros recursos para calcular custo relativo. Mesmo que flash fosse 20 vezes mais caro que disco, muitas vezes acabava saindo mais barato ao considerar o gargalo real. Esses recursos eram convertidos em algo como tempo de engenheiro de software (1 SWE = 1 pessoa-ano). Se a otimização não economizasse pelo menos mais de 5000 núcleos de CPU, dava prejuízo. Só em projetos grandes otimizar fazia sentido; no resto, o código seria substituído em pouco tempo de qualquer forma, então otimizar não valia nada. Além disso, do ponto de vista de usabilidade Web, a interface de mouse é extremamente ineficiente, e terminais baseados em texto de 30 ou 40 anos atrás eram muito mais eficientes. Eu esperava que “a Web fosse se padronizar e avançar para o próximo estágio”, mas isso não aconteceu. Ainda sai framework novo toda semana, e estão até reimplementando a mesma barra de rolagem sem compatibilidade com hardware. Não sei qual é a solução para isso
Na minha visão, isso só vale para empresas com custo de engenharia alto, margem grande e vários projetos. Se realmente sobra qualquer dinheiro, vale mais colocar engenheiro para otimizar. Na prática, cada empresa só imita o Google, então toma decisões sem relação com a lógica econômica, e isso explica muitos problemas
Eu também vim do Google. O Google fala muito em otimizar uso por CPU, mas na prática enfatizava muito duas coisas: latência e utilização total dos servidores. Ambos eram KPIs importantes das camadas superiores da organização, então recebiam um volume enorme de recursos de engenharia. Quanto mais máquinas você tem, menos quer deixá-las paradas, e negócios sensíveis a latência fazem esforço até para reduzir poucos milissegundos
O critério do Google faz sentido porque, para ele, o custo por núcleo é grande. Para a maioria das empresas comuns, isso não se aplica de forma alguma. É uma lógica que só vale na escala de Facebook/Google/Netflix etc.
O Google também criou compressão melhor e formatos de serialização binária melhores para melhorar a própria rentabilidade
Quando vi o título do artigo, achei que o Carmack estava criticando otimização de software para hardware fraco. Na verdade, não; ele está propondo um experimento mental em que o avanço do hardware para, e a conclusão é que “sem computação barata e escalável, há menos produtos inovadores”
Isso se relaciona com a thread de ontem
Sobre a conclusão de que “sem computação barata e escalável a inovação diminui”, na prática quase não tivemos inovação desde o smartphone, e como o capital depende do avanço do hardware, os novos produtos também deixaram de ser essencialmente diferentes dos antigos
Pessoalmente, não concordo com essa afirmação. Mesmo que o desenvolvimento de funcionalidades pare por um tempo, depois de preparação suficiente a inovação volta. Haveria queda, mas não duraria para sempre
O ponto central é que o “inchaço” não é simples desperdício; ele vem do aumento de produtividade do desenvolvimento motivado economicamente. Ganhar produtividade com linguagens menos complexas permite contratar mais gente e reduzir custos
Se fosse possível estender a vida útil do hardware por mais 5 ou 10 anos em vez de descartá-lo por obsolescência planejada, haveria enorme redução de lixo eletrônico, uso de minerais raros e emissão de gases de efeito estufa. Mas o mercado de software não arca com esses custos de externalidade. Testar, corrigir e iterar depois do lançamento é muito mais barato do que projetar bem no longo prazo. Parte da indústria de jogos encontrou a fórmula de alto desempenho + receita, mas isso não se espalhou. Software corporativo e de consumo se preocupa menos com desempenho e mais com o requisito mínimo que o usuário ainda tolera. Como há adição contínua de novos recursos e mudanças, fica difícil se preocupar com desempenho, e o orçamento já reserva margem para taxa de erro. Diferente de um modelo em que se lança algo relativamente “pronto”, aqui o risco de complexidade e mudança é alto
Nos últimos mais de 10 anos, rodamos o mecanismo inteiro de matching da bolsa em uma única thread. Só no processamento serializado de transações, o poder computacional não cresceu tão rápido assim. Se não estiver falando de milhões de TPS, nem é preciso escalar com cluster; pelo contrário, dá para simplificar o design e processar em uma única máquina
Isso é realmente frustrante. Muitos arquitetos de sistema complicaram o sistema para deixar sua própria marca, e só produziram novos problemas. O design original já atendia à maioria das exigências e, com o poder computacional local de hoje, rodar em uma máquina única é perfeitamente viável
Fico curioso sobre por que não dá para paralelizar matching de ordens — talvez aplicando alguma redução de logs parecida com ordenação? Será que o processo de matching tem pouco cálculo além da simples ordenação?
Para processamento simples, uma única thread funciona, mas se cada transação exigir cálculo complexo, não funciona. Só que eu não tenho conhecimento de domínio suficiente para imaginar que tipo de processamento seria tão complexo assim na prática
Se as ferramentas de desenvolvimento tivessem continuado evoluindo, no passado era fácil criar GUI totalmente nativa com RAD, mas hoje o padrão é Electron. Vivemos num cenário em que vários navegadores Web estão instalados como variantes separadas baseadas em Chromium
No fim, isso é um problema econômico de alocação de recursos. A questão é se o desenvolvedor deve gastar tempo otimizando software ou criando recursos novos. Se a segunda opção gera mais receita, é isso que a empresa vai fazer. Se otimização for mais importante, ela age de acordo
Concordo que seja uma questão econômica, mas a essência me parece ser um caso em que empresas de software repassam externalidades negativas para a sociedade como um todo. Elas não se importam com consumo adicional de energia, desperdício e aumento de lixo eletrônico
É uma estrutura que empurra dívida técnica e financeira para os outros e só aumenta a quantidade de lixo. Em muitos casos otimizar talvez realmente não traga ganho prático, mas a prática de simplesmente adicionar mais servidores é lamentável
A ideia de que “adicionar funcionalidades é mais importante” depende do caso. Eu não uso a maioria dos novos recursos do macOS, Windows e Android atuais; para mim, ambiente eficiente e segurança importam mais. Em software de design também espero mais ganho de eficiência do que recurso novo. Às vezes até quero o Illustrator/Photoshop de 10 anos atrás. Em software de produção musical, recursos novos de fato podem melhorar o fluxo de trabalho, mas se prejudicam a eficiência, geram rejeição. Para editor de código, VSCode já basta, e eu só queria que fosse mais rápido e leve
Eficiência é muito importante na minha vida. Por exemplo, quando vou à cozinha buscar algo, sempre levo junto lixo ou louça para não fazer duas viagens. Com software é parecido. Mas entre “gastar caro tempo de engenheiro para otimizar” e “adicionar RAM/recursos”, a segunda opção é sempre mais barata. Só quando o problema fica grande o bastante a otimização compensa. O mercado decide no fim qual escolha é vantajosa. Se o ganho de adicionar hardware cair, haverá migração para otimização. Como a lei de Moore ainda não bateu no limite, ainda não chegamos lá
No fundo, é uma questão de demanda. Se o consumidor valorizasse software mais rápido, pagaria mais por isso; mas, na prática, mesmo com desempenho pior, se for mais barato ele tende a escolher esse lado
Isso é exatamente a definição de “enshitification”
Há muita reclamação sobre desempenho de apps Electron, mas eles foram uma inovação central para tornar tolerável o ambiente de trabalho em laptop Linux. Por exemplo, dá para entrar facilmente em reuniões do Teams sem instalação. Por mais que todo mundo sinta falta da otimização de código do Winamp, na prática a acessibilidade dos apps Electron é conveniente
Jogando Balatro recentemente, senti que ainda hoje se trata de um jogo que só precisa de cálculos simples e gráficos simples, mas, na prática, os requisitos mínimos continuam subindo para um jogo que provavelmente rodaria em hardware dos anos 90 (Pentium II + 3dfx). Fiquei surpreso com o nível exagerado de requisitos a ponto de parecer algo que só roda em notebook moderno