- Muchos más sistemas de los que la gente imagina pueden funcionar suficientemente bien en hardware antiguo
- Si se logra una verdadera optimización de software, es muy probable alcanzar este tipo de eficiencia
- Las señales de precio del mercado para los recursos de cómputo escasos generan incentivos para la eficiencia del software
- Existe la necesidad de convertir los productos actuales de microservicios basados en intérpretes en una arquitectura monolítica construida con código nativo
- Por otro lado, sin recursos de cómputo muy baratos y escalables, es posible que el desarrollo de nuevos productos innovadores ocurra con mucha menos frecuencia
1 comentarios
Opinión de Hacker News
Se puede argumentar que en el mercado el software con muchos bugs e ineficiente se vende igual de bien que el software perfecto; uno de los dos es el software más barato de producir. Se parece a la historia del “mercado de limones”: el mercado comercia como si todos los productos fueran de alta calidad, pero en realidad sacrifica calidad para reducir costos. Como los compradores no pueden distinguir entre alta y baja calidad antes de comprar, la demanda de ambos se vuelve artificialmente similar; esto se debe a la asimetría de información. Este fenómeno ya es real y cada vez lo es más en la IA: los usuarios no pueden distinguir entre una aplicación sofisticada de machine learning y una lavadora con la etiqueta “AI”. La etiqueta AI por sí sola da una prima de precio, así que los usuarios pagan de más por la lavadora. Cobrar por software pésimo porque el comprador cree que fue “diseñado y escrito por expertos” es, en el fondo, lo mismo. Casi todo el software se escribe en niveles IC1-3, y en la mayoría de las empresas QA termina siendo el único indicador de mejora de calidad; a veces se espera mejora porque unos interns recitan el conjuro de “LGTM”, pero en la práctica ni eso es común
Intenté crear una startup de software diferenciada por calidad. Estaba convencido de que, si el producto era mejor, la gente lo notaría y tendría éxito, pero en realidad no fue así. Crecimos, pero demasiado lento, y el dinero se acabó antes de llegar a rentabilidad. Lo que entendí es que el bajo costo, y por tanto la baja calidad, se convierten en una ventaja competitiva en mercados competidos. Lo había escuchado desde la universidad, pero esta experiencia me lo hizo sentir hasta los huesos. Esa es la razón por la que todo en el mercado tiende a volverse mediocre, y por la que incluso la alta calidad se deteriora cuando algo se vuelve popular. Cuanto más escala un producto, mayor es la presión por recortar costos. La gente quiere comprar barato, así que alguien reduce costos —es decir, calidad— para ofrecerlo más barato. Las empresas pagan solo lo mínimo para sobrevivir y obtener ganancias. Claro, a veces hay excepciones, pero al final todo deriva hacia recortes graduales de costos. Seguro este fenómeno tiene un nombre; se parece un poco al mercado de limones, pero no es igual. El mercado no colapsa, pero se instala una mediocridad estable en todas partes
Hay una objeción a la idea de que el “mercado” vende todos los productos como si fueran de alta calidad. Aquí importa qué significa “alta calidad”. Suena como si bajo rendimiento equivaliera a baja calidad, pero en la práctica apps consideradas lentas como Teams, Slack o Jira tienen competidores con muchísimo mejor rendimiento. Sin embargo, si le dices a un usuario que elija Weechat en vez de Slack —UI de terminal, sin videollamadas, sin emojis— la mayoría verá a Weechat como de menor calidad. El rendimiento también es solo una característica más. Por ejemplo, el éxito inicial de Chrome se debió a que era rápido, y los desarrolladores de Python también se están moviendo a uv/ruff por mejoras de rendimiento. Pero aunque Slack iniciara en 10 ms en vez de 5 segundos, a la mayoría de los usuarios no les importaría
No estoy de acuerdo con que el software ineficiente sea consecuencia de una estructura de mercado de limones. Eso solo aplica cuando hay asimetría de información. En la mayoría de los casos, a la gente no le importan unos cuantos bugs y prefiere un precio más bajo. Si pasas por QA muy riguroso y procesos de revisión de código por múltiples ingenieros, al comparar tarifas queda claro. Incluso hice software para una librería pequeña: lo desarrollé rápido y no cobré mucho. Aunque no fuera perfecto, arreglaba los problemas en cuanto aparecían, y el cliente entendió que había sido un buen trato, así que quedó satisfecho
He usado portales horribles de HR, gastos, seguimiento de horas y seguros en grandes empresas. Eran tan malos que uno se preguntaba si quien pagó por ese producto realmente lo había usado. Si un equipo entregara a clientes un producto lleno de bugs y con una UI de pesadilla, eso merecería regaño inmediato, degradación o incluso despido
La esencia de que el mercado compre bien “software lleno de bugs e ineficiente” es que el mercado compra <i>soporte</i>. Eso también aplica a Google o a empresas con poco soporte humano. “Soporte” aparece de muchas formas —documentación, videos, información en blogs, gente que ayuda, soporte para mi entorno (sistema operativo, navegador, etc.), soporte para la tarea que quiero hacer, etc. Lo número uno que mantiene vivo hasta al peor ERP sigue siendo la presencia de personas reales. La existencia o ausencia de soporte define la línea entre vida y muerte de un producto. Si un equipo pequeño quiere ganar una pelea, es inteligente reducir la “necesidad de soporte” y agregar soporte en otra dimensión. La forma más fácil es sumar humanos. Y hay que comunicar bien las fortalezas. Cada tipo de soporte se valora distinto; por ejemplo, código open source vs. código propietario. Mucha gente prefiere el lado propietario si tiene más soporte, más que por el código en sí
Una de las grandes razones por las que me gusta comprar en Costco es que, en general, no venden pura basura. El filtro no siempre coincide con mis criterios, pero sí es un filtro de calidad con cierto valor
Incluso si los usuarios pudieran decidir basándose en calidad y rendimiento del software, viendo mi lista de apps abiertas ninguna podría sustituirse simplemente porque otra rinde mejor. Por ejemplo, uso Docker, iterm2 o WhatsApp por razones específicas. Aunque hubiera una solución más rápida, no podría cambiar tan fácil. El simple hecho de que exista software que satisface mis necesidades desde el principio es un factor más importante que el rendimiento por sí solo
El 99% del software se escribe sin considerar el rendimiento. Incluso en HN suele haber una tendencia a tratar las mejoras de rendimiento como un tabú. Hasta ingenieros de nivel L4/5 o superior muchas veces carecen de intuición de rendimiento. Desde la perspectiva del negocio tampoco se presta atención a la eficiencia hasta que el hardware ya no puede ejecutar ese software; y aun entonces, la prioridad es resolverlo con más hardware
La estructura actual del mercado hace que dominen el software lleno de bugs e ineficiente porque siempre puedes comprar hardware para ejecutarlo. El software se expande hasta llenar la capacidad de procesamiento del hardware: es la ley de “lo que Andy da, Bill se lo queda”. Así que no hay incentivos para hacer software lean y de alta calidad. Pero si llegara un mundo donde ya no se pudieran conseguir chips de punta —por ejemplo, por una crisis geopolítica o la destrucción masiva de fábricas— entonces el software que ahorra recursos tendría un enorme valor económico; el software inflado simplemente dejaría de poder ejecutarse. Carmack dice que en esa situación el margen de optimización sería suficientemente grande como para que, al final, de una u otra forma se pudiera hacer correr software incluso en chips de otra época
El software bien diseñado es fácil de reemplazar. En cambio, un montón de spaghetti code lleno de bugs nadie quiere tocarlo, así que se queda para siempre. Si uno mira la evolución en estado puro, termina dominando el software malo
El mercado de autos usados es un mercado de limones porque es difícil distinguir entre un auto bien cuidado y uno a punto de fallar. Pero el mercado de autos nuevos está estrictamente controlado, así que eso no aplica. El software siempre es nuevo. Así como la calidad de los autos ha aumentado durante décadas, la del software también podría aumentar. Podrías exigir un estándar mínimo para poder venderlo, hacer recalls si hay bugs graves y castigar a quien venda deliberadamente productos defectuosos. Así funcionan todas las demás industrias
Con la introducción del modelo Web 2.0 “beta permanente” y SaaS, la paciencia de los usuarios también cambió. Microsoft sembró durante generaciones la idea de que “el software naturalmente está roto”. Como todos se acostumbraron al software malo, ya no entienden bien el valor del software bueno
De hecho sí compré esa lavadora con marca de AI. El marketing me dio risa, pero el precio era razonable, así que la compré
Probablemente solo se esté hablando de fallas de seguridad. Si Excel o Photoshop estuvieran llenos de problemas de rendimiento u otros bugs, la gente dejaría de usarlos rápido. Pero la seguridad es algo que el usuario no percibe hasta que ocurre un problema, y aunque lo hackeen no sabe cuál fue la causa. No hay incentivos para el desarrollador. Con el rendimiento, una vez que se alcanza cierto nivel, ya no se quiere invertir más recursos en optimizar: es la ley de rendimientos decrecientes
Aunque el usuario no pueda distinguir entre una IA sofisticada y una “lavadora AI” de pura fachada, una buena IA podría ayudar a los usuarios a superar por sí mismos la asimetría de información. En el fondo, si hubiera una forma de elegir buena IA, el problema podría resolverse
No creo que hacer “el software más barato posible” sea necesariamente barato. A nivel startup, hacer algo a medias puede salir barato, pero a gran escala termina costando más. Las aerolíneas recortan costos quitando hasta una aceituna, así que me pregunto por qué no sería eficiente poner a los desarrolladores a optimizar. Seguimos agregando funciones nuevas, pero el usuario al final siente que cada actualización hace todo más lento. En cambio, cuando algo se vuelve más rápido, lo celebra. Los ingenieros actúan como MBA y repiten que “no aporta valor”, pero el “valor” de corregir bugs en software es bastante subjetivo. La misión del ingeniero es corregir bugs. La marca también importa, pero las grandes marcas actuales ignoran su valor de marca. Tal vez porque los consumidores no cambian fácilmente, pero cuando cambian terminan con más UIs nuevas y más cosas que aprender (ni siquiera Apple ya se siente intuitivo)
El mundo actual probablemente podría funcionar con hardware viejo, pero como CPU y hardware de todos modos siguen haciéndose más rápidos, no hay mucha razón para escribir código más eficiente
El problema de la asimetría de información puede superarse en productos FOSS o propietarios de “shared source”. Si ves el código directamente, puedes comprobar si en general tiene buena calidad. Aunque no encuentres bugs concretos, sí puedes percibir una cultura de desarrollo honesta por la longitud de las funciones, los comentarios, los nombres, etc. En serio, cuando ves un producto propietario caro con un esquema de db desastroso, no te inspira confianza
El mal software, a largo plazo, cuesta más producirlo y mantenerlo
Por eso se dice que la marca funciona como guardiana de la calidad
Así como la ley prohíbe vender comida tóxica, vencida o con aditivos adictivos, también debería haber regulación para el software. Pero antes de GDPR casi toda regulación era irrelevante, y aun hoy las violaciones son cosa de todos los días
Desde 1980 el poder de cómputo ha aumentado unas 1000 veces. Si asumimos una pérdida de rendimiento del 5% por chequeo dinámico de límites de arreglos —en realidad sería bastante menos— entonces incluso con esa verificación activada podríamos haber usado computadoras 950 veces más rápidas. Si volvieras a 1980 y tuvieras que elegir entre “computadoras 950 veces más rápidas, con menos bugs y más fáciles de depurar” y “computadoras 1000 veces más rápidas, pero todavía llenas de bugs y más difíciles de depurar”, la mayoría elegiría las de 950 veces. Pero al final elegimos las de 1000 veces. Personalmente creo que los partidarios de las 1000 veces arruinaron la situación
Pero ese rendimiento 1000x no se gasta en chequeo de límites, sino en abstracciones interminables e ineficiencia
Yo sí obligué a un proveedor a hacer correr su software lento y lleno de bugs en una Sparc 20. Como resultado optimizaron el software, y eso se volvió la base para que la empresa pudiera triunfar en el mercado. La optimización es una ventaja competitiva
Eso solo puede decirse desde 1980. Resumiendo un video reciente: “las computadoras de hoy no son tan rápidas como las de hace 20 años, salvo que realmente optimices para notarlo”. El autor ignoró cosas como la optimización del compilador, pero aun así la mejora real de performance fue menor de lo que uno imagina; dice que en 15 años apenas se duplicó
Se dijo que el chequeo de límites de arreglos cuesta solo 5%, pero no todos los algoritmos son tan simples. Dependiendo de cuántas veces se procese algo, introducir ese chequeo podría elevar el costo 3 o 4 veces. En ciertos usos, si obligas ese chequeo, el lenguaje mismo pierde competitividad. En la mayoría de los casos da igual, pero me parece razonable separar entre modo seguro y modo general
Si solo piensas en chequeo de límites, el costo es relativamente bajo, pero la sobrecarga de los lenguajes seguros es mucho mayor. Los lenguajes con GC pueden multiplicar el uso de memoria varias veces
No hay que olvidar la ley de los grandes números. Una caída de rendimiento del 5% en un sistema no parece mucho, pero si se acumula un 5% de pérdida en todo el entorno computacional del mundo, el impacto es enorme
Estoy de acuerdo en que la naturaleza humana favorece la ganancia a corto plazo, pero el chequeo dinámico de límites no resuelve por sí solo los problemas de seguridad. Aún no existe una solución definitiva
La razón fundamental por la que terminamos así es que estamos atados al navegador
La primera respuesta es básicamente la correcta; el solo hecho de que C siga usándose tanto muestra que la esencia del problema es que abajo en el stack no hay eficiencia estructural
Ese “5%” se siente poco fundamentado. No me queda claro con qué criterio se calculó ese costo; incluso me pregunto si, al verificar cada inserción en un arreglo, el costo real no podría duplicarse o más
Hoy la mayoría de los lenguajes de programación ya soportan chequeo de límites de arreglos por defecto
Me recuerda a cuando apareció Node.js. Su gran ventaja era unir el código del cliente y del servidor, pero hoy es una pesadilla de seguridad. Los lenguajes minimalistas con codebase pequeña también tienen ventajas
Si hubiéramos entendido antes que una sola cadena podía contener datos de tamaño gigabytes, las cadenas terminadas en nulo habrían desaparecido y todos habríamos sufrido menos
Los 1000Xers que realmente disfrutan productos 1000 veces más rápidos son, de hecho, una minoría ínfima. El software de escritorio que usa la gente común sigue siendo lento
En realidad se volvió unas 100 mil veces más rápido: solo el clock aumentó 1000 veces, los cores 10 veces, y las instrucciones mismas otras 10 con cosas como AVX; estructuralmente sería entre 1 y 2 millones de veces más rápido. Y aun así eso no impacta la velocidad percibida
Citan a Robert Barton llamando a esta gente “sumos sacerdotes de un culto vulgar”
Desde 1980 sí, pero si miras desde 2005 es más bien una mejora de unas 5 veces
El clock es 2000 veces, con SIMD e IPC unas 80 veces, y multiplicando por cores termina siendo 1 a 2 millones de veces más rápido. Pero la mayoría de los programas se escriben con la idea de su autor de que “si funciona, esa es su velocidad”. Pensar en optimización es algo extremadamente minoritario, incluso entre usuarios de HN
En 2001 debimos haber tomado como referencia un CPU de 1GHz para correr software básico, y mi experiencia con AI también ha sido bastante decepcionante. Esperaba que un LLM pudiera manejar bien cosas como conversión de lenguaje y optimización de código, pero la realidad no es así. Incluso hice que una AI portara código Unix
seda un lenguaje de la jvm, y más allá de lo básico fracasó por completo en nivel intermedio o superior. Al final, toda esta corriente no busca mejorar la calidad del software, sino “reducir empleos”. La AI va a producir todavía más software maloEso es exactamente JavaScript, y el futuro del usuario
Habiendo trabajado en Google (y Facebook), uno se da cuenta de lo barato que es el hardware y de que optimizar código casi nunca vale la pena. Hace más de 10 años en Google ya era obligatorio gestionar los recursos del datacenter, y cada proyecto tenía presupuesto. Se calculaban costos relativos intercambiando recursos como CPU, HDD y flash. Aunque el flash costara 20 veces más que el disco, a veces era más barato si se consideraba el cuello de botella real. Esos recursos se traducían en tiempo de ingenieros de software (1 SWE = 1 persona-año). Si una optimización no ahorraba más de 5000 CPU cores, salía peor. La optimización solo tenía sentido en proyectos grandes; en lo demás, como el código se iba a reemplazar pronto, optimizar no tenía sentido. Además, desde la perspectiva de usabilidad web, la interfaz de mouse es muy ineficiente, y las terminales basadas en texto de hace 30 o 40 años eran mucho más eficientes. Esperábamos que “la web se estandarizara y pasáramos a la siguiente etapa”, pero no ocurrió. Todavía cada semana sale un framework nuevo, y hasta la misma barra de scroll se reimplementa de forma incompatible con el hardware. No sé cuál sea la solución a este problema
Creo que ese razonamiento solo vale para empresas con alto costo de ingeniería, altos márgenes y múltiples proyectos. Si de verdad te sobra aunque sea un poco de dinero, lo mejor es poner ingenieros a optimizar. En la práctica, cada empresa solo imita a Google, así que toma decisiones sin relación con la lógica económica, y eso explica muchos problemas
Yo también soy ex-Google. Google habla mucho de optimización por uso de CPU, pero en realidad enfatizaba muchísimo dos cosas: latencia y utilización total de servidores. Ambas eran KPI importantes para organizaciones superiores, así que se invertían enormes recursos de ingeniería. Cuantas más máquinas tienes, menos quieres tenerlas ociosas, y en negocios sensibles a la latencia se intenta recortar aunque sea unos pocos ms
Ese criterio funciona para Google porque ahí el costo por core realmente es grande. Para la mayoría de las empresas comunes no aplica en absoluto. Es algo que solo funciona a la escala de Facebook/Google/Netflix, etc.
Google también ideó mejor compresión y formatos de serialización binaria para mejorar su propia rentabilidad
Cuando vi el título del artículo pensé que Carmack iba a criticar la optimización de software para hardware de bajo rendimiento. En realidad no es así: habla de un experimento mental donde el avance del hardware se detiene, y en la conclusión señala que “sin cómputo barato y escalable, hay menos productos innovadores”
Está relacionado con un hilo que salió ayer
Sobre esa conclusión de que “sin cómputo barato y escalable disminuye la innovación”, en realidad desde los smartphones casi no hemos visto innovación, y como el capital depende solo del avance de hardware, los productos nuevos dejaron de diferenciarse esencialmente de los anteriores
Personalmente no estoy de acuerdo con esa afirmación. Aunque se detuviera el desarrollo de funciones por un tiempo, tras suficiente preparación la innovación volvería. Habría una caída, pero no sería permanente
El punto clave es que el “bloat” no es solo desperdicio, sino un aumento de productividad del desarrollo impulsado por incentivos económicos. Aumentar productividad con lenguajes menos complejos permite contratar más gente y reducir costos
Si pudiéramos alargar la vida útil del hardware 5 o 10 años más en lugar de llevarlo a una obsolescencia planificada, reduciríamos una enorme cantidad de residuos electrónicos, uso de minerales raros y emisiones de gases de efecto invernadero. Pero el mercado de software no asume esos costos de externalidades. Probar, corregir e iterar después del lanzamiento es mucho más barato que diseñar a largo plazo. Parte de la industria de videojuegos encontró una fórmula de alto rendimiento + ingresos, pero no es algo ampliamente extendido. El software empresarial y de consumo se preocupa menos por el rendimiento que por cumplir el umbral de tolerancia del usuario. Como hay que seguir agregando funciones nuevas y cambios continuos, es difícil prestar atención al rendimiento, y en el presupuesto ya se deja margen para una cierta tasa de errores. A diferencia de lanzar en un estado relativamente “listo”, aquí el riesgo de complejidad y cambio es mucho mayor
Durante más de la última década hemos ejecutado todo el matching engine de una bolsa en un solo hilo. Al menos para el procesamiento serializado de transacciones, el poder de cómputo no ha crecido tan rápido. Si no hablas de millones de TPS, ni siquiera hace falta escalar a clúster; al contrario, puedes simplificar el diseño y manejarlo en una sola máquina
Eso es justamente lo frustrante. Muchos arquitectos de sistemas complicaron los sistemas solo para dejar su huella personal, y con eso solo generaron problemas nuevos. El diseño original ya bastaba para la mayoría de las necesidades, y con el poder de cómputo local actual, procesarlo en una sola máquina sigue siendo perfectamente viable
Me pregunto por qué no se puede paralelizar el matching de órdenes. ¿No podría hacerse con algún tipo de reducción de logs similar al sorting paralelo? Quizá en el proceso de matching no hay realmente mucho cálculo aparte del simple ordenamiento
Si el procesamiento es simple, se puede hacer en un solo hilo; pero si cada transacción requiere cálculos complejos, entonces no. Como no tengo tanto conocimiento del dominio, no alcanzo a imaginar qué tipo de procesamiento sería tan complejo en la práctica
Si las herramientas de desarrollo hubieran seguido avanzando, antes con RAD era fácil hacer GUIs totalmente nativas, pero ahora Electron domina. Terminamos con varios navegadores web, cada uno instalado como una variante basada en Chromium
Al final, esto es una cuestión económica de asignación de recursos: decidir si hacer que los desarrolladores gasten tiempo optimizando software o creando funciones nuevas. Si lo segundo genera más ingresos, eso es lo que se hará. Si optimizar fuera más importante, se actuaría en consecuencia
Estoy de acuerdo en que es un tema económico, pero en esencia lo veo como un caso en que las empresas de software trasladan externalidades negativas al conjunto de la sociedad. No se preocupan por el consumo extra de energía, el desperdicio o el aumento de residuos electrónicos
Es una estructura que le pasa la deuda técnica y financiera a otros y solo aumenta la basura. Muchas veces optimizar quizá no tenga beneficio real, pero da pena que la práctica sea simplemente agregar más servidores
Que “agregar funciones es más importante” depende mucho del caso. Yo no uso la mayoría de las funciones nuevas de macOS, Windows o Android actuales; me importan más un entorno eficiente y la seguridad. En software de diseño también esperaría más mejoras de eficiencia que funciones nuevas. A veces incluso quisiera el Illustrator/Photoshop de hace 10 años. En programas de producción musical sí puede haber funciones nuevas que mejoren lo que uno quiere hacer, pero si perjudican la eficiencia causan rechazo. En editores de código, con VSCode me basta, y ojalá fuera más rápido y más ligero
En mi vida la eficiencia es muy importante. Por ejemplo, cuando voy a la cocina por algo, siempre aprovecho para llevar también basura o platos y no hacer el viaje dos veces. Con el software pasa algo parecido. Pero entre “gastar tiempo caro de ingenieros en optimizar” y “agregar RAM/recursos”, lo segundo siempre es más barato. Solo cuando el problema crece lo suficiente optimizar sale a cuenta. El mercado termina decidiendo qué elección conviene. Si el beneficio de agregar hardware disminuyera, entonces se cambiaría a optimizar. Como la ley de Moore aún no ha llegado a su límite, por eso seguimos así
En última instancia es un problema de demanda. Si los consumidores valoraran más el software rápido, pagarían gustosos más por él, pero en la práctica, aunque el rendimiento sea peor, si cuesta menos eligen esa opción
Esa es precisamente la definición de “enshitification”
Las apps hechas con Electron reciben muchas quejas por rendimiento, pero han sido la innovación clave que hizo tolerable un entorno laboral en una laptop Linux. Por ejemplo, permiten entrar fácilmente a reuniones de Teams sin instalar nada. Todo el mundo puede extrañar la optimización de código de Winamp, pero en la práctica la accesibilidad de una app Electron es cómoda
Jugando recientemente Balatro pensé en esto: incluso hoy es un juego que solo necesita operaciones simples y gráficos sencillos, pero el requisito mínimo que pide sigue subiendo como si ya no pudiera correr en hardware de los 90 (Pentium II + 3dfx), cuando en realidad parecería que sí podría. Me sorprende lo exagerados que son los requisitos, al punto de parecer un juego que solo corre en una laptop moderna