- Si la optimización de software fuera realmente la prioridad, más sistemas de los que se espera podrían funcionar incluso sobre hardware antiguo
- Si las señales de precios de mercado actuaran sobre recursos de cómputo escasos, aumentaría la presión para crear software más eficiente
- Un ejemplo sería rehacer productos basados en lenguajes interpretados y microservicios como una base de código monolítica en código nativo
- Pero sin cómputo ultrabarato y de alta escalabilidad, experimentar y lanzar nuevos productos innovadores podría volverse mucho menos frecuente
- La optimización de rendimiento por sí sola no basta; el cómputo barato y escalable determina la frecuencia de experimentación y lanzamiento de productos
Experimento mental con la optimización como prioridad
- Si la optimización de software fuera realmente la prioridad, más sistemas de los que se espera podrían operar incluso sobre hardware antiguo
- Si las señales de precios actuaran con fuerza sobre recursos de cómputo escasos, el mercado terminaría exigiendo software más eficiente
Formas posibles de implementación y limitaciones
- Un ejemplo sería rehacer productos basados en lenguajes interpretados y microservicios como una base de código monolítica en código nativo
- Aun así, sin cómputo ultrabarato y de alta escalabilidad, los nuevos productos innovadores podrían volverse mucho menos frecuentes
1 comentarios
Opiniones de Hacker News
Se podría argumentar que el mercado compra software lleno de bugs e ineficiente tan bien como software bien terminado, y que uno de los dos es el software más barato que se puede crear.
Esto se parece a la historia del “mercado de limones”. El mercado vende todos los productos como si fueran de alta calidad, pero reduce la calidad de forma discreta para bajar el costo marginal. Como los compradores no pueden distinguir entre alta y baja calidad antes de comprar, la demanda se vuelve artificialmente similar; la causa es la asimetría de información.
En IA ya pasa, y va a empeorar. Los usuarios no pueden distinguir entre una app sofisticada de aprendizaje automático y llamar IA al ciclo de centrifugado de una lavadora. La etiqueta de IA en sí crea un sobreprecio, y los usuarios terminan pagando muchísimo de más por una lavadora.
En esencia, es lo mismo que pagar de más creyendo que un software desastroso fue diseñado y escrito por técnicos y expertos. El 99% del software lo escriben IC1~3, y en la mayoría de las empresas tecnológicas una sola persona de QA es el único mecanismo para elevar la calidad más allá de “cumple con los criterios de aceptación”. De vez en cuando un grupo de pasantes recita el conjuro “LGTM”, pero hasta eso es raro.
https://www.lg.com/uk/lg-experience/inspiration/lg-ai-wash-e...
Estaba convencido de que, si el producto era mejor, convencería a la gente y crecería de forma viral, pero no fue así. Creció, pero tan lento que nos quedamos sin fondos después de unos años, antes de llegar al punto de equilibrio.
Lo que entendí es que, en un mercado competitivo, el bajo costo, y por lo tanto la baja calidad, es una ventaja competitiva. Cuanto más grande se vuelve el producto, mayor es la presión por reducir costos, y como la gente quiere cosas baratas, alguien recorta el “costo”, es decir, la calidad, para hacerlo más barato. Las empresas pagan solo lo mínimo necesario para sobrevivir y generar ganancias.
A veces una empresa joven intenta crear alta calidad o aumenta el gasto por un tiempo, pero al final se genera una corriente que la desliza hacia una mediocridad estable. Esto es un poco distinto del mercado de limones y parece terminar más en mediocridad por todas partes que en un colapso del mercado.
Pero si a una persona promedio le pides elegir entre Slack y Weechat, un cliente de IRC rápido, probablemente considere de baja calidad al lado con UI de terminal, sin videollamadas, sin integración con webhooks y sin avatares ni emojis personalizados.
El rendimiento también es una función. Una de las grandes razones por las que Internet Explorer perdió frente a Chrome fue que Chrome era mucho más rápido cuando se lanzó, y los desarrolladores de Python se están moviendo rápidamente a uv/ruff también por mejoras de rendimiento. Pero cuando ejecutar Slack tarda 5 segundos en lugar de 10 ms, a muy poca gente le importa.
Eso a veces ocurre con software lleno de bugs, pero en general la gente quiere pagar menos y en el proceso acepta algunos bugs. Basta pensar cuánto habría que cobrar para seguir un proceso en el que varias personas de ingeniería revisen cada línea de código y se dedique mucho tiempo a QA estricto.
Cuando vivía en Padova, una vez hice software para una pequeña librería. Como era para un amigo, lo hice rápido y no cobré mucho. No era perfecto, pero si surgía un problema lo arreglaba, no hubo muchos problemas y mi amigo quedó satisfecho con el trato. Como sabía que le estaba cobrando barato, también tuvo paciencia.
Varias veces dije que, si nuestro equipo le dijera a un cliente “el proyecto está terminado, pero tiene tantos bugs y pesadillas de UI como esta plataforma de back office”, nos llamarían la atención, nos bajarían de puesto o nos despedirían.
Esto incluye incluso a empresas como Google, que tienen poco soporte humano. El soporte aparece de muchas formas: hay información como documentación, videos y blogs; hay personas que ayudan, como “mamá, Google se usa así”; hay soporte para aquello sobre lo que se usa, como sistemas operativos, navegadores y formatos; y también está lo que sostiene mi propia forma de trabajar, como Excel.
Por último, están las personas reales. Este es el factor número uno que hace que hasta el peor ERP del planeta sobreviva. El marketing y las ventas también son señales de que hay soporte. Si un cliente corporativo solo ve ingenieros, puede ser una mala señal. Los desarrolladores muchas veces no saben hacer otras cosas, y esas otras cosas son soporte importante.
Un buen producto muere si no tiene soporte. Para competir contra un producto peor, conviene reducir la necesidad de soporte —bugs, problemas de rendimiento, plataformas— para bajar el costo de mi equipo, pero necesariamente hay que sumar soporte en otras dimensiones. Para un equipo pequeño, lo más fácil es asignar el recurso de soporte más escaso: personas; después de eso hace falta creatividad.
Además, hay que comunicar bien las fortalezas. Algunas personas valoran más cierto tipo de soporte, como “poder tener el código vs. producto propietario”. Mucha gente prefiere un producto propietario con soporte antes que el código.
Desde 1980, suele considerarse que el rendimiento de cómputo aumentó aproximadamente 1000 veces.
Aunque la verificación de límites en arreglos dinámicos costara un 5%, en la práctica es mucho menos que eso, y si se activara en todas partes, las computadoras serían apenas unas 950 veces más rápidas.
Si volviéramos a 1980 y se nos pidiera elegir entre “una computadora 950 veces más rápida, sin una gran clase de vulnerabilidades de seguridad de memoria y con una depuración varios órdenes de magnitud más fácil” y “una computadora 1000 veces más rápida, pero con software que sigue lleno de bugs o peor, y cuya depuración es una pesadilla”, la gente se habría quedado impactada incluso con solo 950 veces.
Pero lo que elegimos fue lo segundo y, personalmente, creo que el bando de las 1000 veces arruinó las cosas para los demás.
Al final, cuando lo optimizaron para que corriera eficientemente en la Sparc 20, la empresa quedó con una base para triunfar en un mercado más amplio. La optimización debe tratarse como una ventaja competitiva y, en algunos casos, puede ser la ventaja competitiva más importante.
Por eso, si se fuerza la verificación de límites, ese lenguaje pierde competitividad en ciertas tareas.
En la enorme mayoría de los casos no importa en absoluto y es mucho menos que el 5%. Creo que una buena solución es separar entre seguro/no seguro o entre rangos generales/de rendimiento.
Una CPU convencional está más cerca de ser entre 1 y 2 millones de veces más rápida que las máquinas de los 80. Por unos cientos de dólares todavía se puede comprar una computadora de oficina reacondicionada dentro de la categoría de 1 millón de veces más rápida.
El fenómeno de que las computadoras actuales sean lentas o se sientan lentas no se debe simplemente a que las computadoras sean lentas, y aun así sucede. Parte de la causa es que los lenguajes de scripting asignan memoria constantemente para operaciones pequeñas y, por el tipado dinámico, siguen punteros por cada variable; también hay gente que usa programas extremadamente ineficientes en entornos que ya de por sí son malos.
Hoy, la mayoría de los programas se escriben no de la manera que el usuario querría, sino de la manera en que el autor quiere trabajar. Mucha gente no tiene noción de optimización ni de qué se ejecuta más rápido; hacen que funcione y luego piensan: “este programa tiene esta velocidad”.
La idea misma de que el mismo software podría volverse más rápido es una forma de pensar de nicho, y ni siquiera en Hacker News todos piensan así.
Los lenguajes con recolección de basura a menudo usan varias veces más memoria. No liberan de inmediato la memoria que ya no se usa y, para empezar, suelen requerir más asignaciones.
Trabajar en Google y Facebook me hizo sentir lo barato que es el hardware y lo poco valiosa que es la optimización de código en la mayoría de los casos.
Hace más de 10 años, Google empezó a administrar el uso de recursos de sus centros de datos, y cada proyecto tenía presupuestos de núcleos de CPU, espacio en discos duros, almacenamiento flash, spindles de disco, memoria, etc. En general, estos recursos podían convertirse entre sí, de modo que era posible ver sus costos relativos.
En ese entonces, el almacenamiento flash era unas 20 veces más caro que los discos duros, pero debido al cuello de botella de los spindles, muchas veces terminaba siendo más barato en costo total.
Todo eso podía convertirse a “mili-SWE”, es decir, una milésima parte del esfuerzo de un SWE trabajando durante un año. Los proyectos podían ahorrar hardware y contratar más gente, o contratar menos gente y recibir más hardware dentro del presupuesto actual.
No recuerdo exactamente cuántos núcleos de CPU equivalían a 1 SWE, pero creo que eran miles. Si se gasta un año de SWE en optimizar todo un proyecto y ni siquiera se ahorran 5000 núcleos de CPU, es una pérdida neta.
En proyectos muy grandes se usaba mucho más que eso, así que la optimización tenía sentido, pero muchas veces no era lo correcto, sobre todo si era probable que el código escrito fuera reemplazado algún día.
Por otro lado, en la web hay un problema general de usabilidad. La web no debería consumir tantos recursos como consume hoy. Si conoces a alguien que haya hecho trabajo de ingreso de datos, sabrás que el mouse es bastante ineficiente. Hace 30 o 40 años, las terminales basadas en texto ofrecían interfaces muy eficientes usando poquísimos recursos.
Pensé que algún día la web se “resolvería” en el sentido de que se establecería un stack tecnológico generalmente esperado y pasaríamos a otros problemas, pero no fue así. Todavía existe “el framework de la semana”, y se hacen tonterías como reimplementar en código de usuario barras de desplazamiento que no encajan bien con la rueda del mouse. No sé cómo podría resolverse este problema, ni siquiera si en primer lugar puede “resolverse”.
Google dedicó una cantidad enorme de esfuerzo a otros dos aspectos del rendimiento: la latencia y la utilización total del hardware. Ambos fueron órdenes bajadas desde arriba, absorbieron el tiempo y la atención de miles de ingenieros, y también tuvieron un gran costo salarial.
Pero si el hardware es la restricción, aunque cada núcleo individual sea barato, no quieres dejarlo ocioso sin motivo. El costo de oportunidad de esperar a construir un nuevo centro de datos es grande. Si el uso es muy sensible a la latencia, tiene sentido recortar milisegundos por métricas de negocio, no para ahorrar costos de hardware.
La evaluación debe hacerse sobre el costo marginal. Aunque solo se ahorren unos centavos al año por cada dólar, es mejor hacer ese trabajo que tener a los ingenieros sin hacer nada.
El problema es que casi nadie actúa así. La forma de tomar decisiones no tiene relación con cálculos económicos, y la mayoría simplemente copia “lo que hace Google”. Eso explica muchas disfunciones.
Pero una empresa común, incluso una grande, no está en ese nivel. Parece un ejemplo típico de que “Facebook/Google/Netflix y similares son una clase aparte, y la mayoría de sus prácticas no te sirven a ti”.
Se puede imaginar un universo alternativo donde se destinan recursos humanos a la optimización, pero ese universo sería totalmente distinto al actual. Si asignas un ingeniero más a optimización, tienes un ingeniero menos desarrollando funcionalidades. ¿Para qué? ¿Para ahorrar unos ciclos de CPU? Suena a broma.
Solo por el título, pensé que Carmack estaba criticando software mal optimizado y proponiendo mejorar el rendimiento en hardware viejo.
El tuit real no era ninguna de esas dos cosas; planteaba un experimento mental en el que el avance del hardware se detenía y concluía que “sin cómputo escalable y ultrabarato, los nuevos productos innovadores naturalmente serían mucho más raros”.
https://news.ycombinator.com/item?id=43967208
https://threadreaderapp.com/thread/1922015999118680495.html
Más bien creo que en los 18 años desde el smartphone hemos visto poca gran innovación, y que se debe a que el capital depende del avance del hardware para venderles a los consumidores productos que, en esencia, son iguales a los que ya tienen.
Claro, no pude leer más allá del primer tuit.
Habrá estancamiento, pero no será un estancamiento sostenido.
Si puedes contratar gente para usar lenguajes menos complejos y volverla productiva, el mercado laboral se amplía y los costos bajan.
En el texto original, Carmack básicamente está argumentando que “los desarrolladores buenos e inteligentes son caros y tienen cosas más grandes que hacer, así que no se les paga para optimizar el código y los sistemas hasta el final; por eso el software es lento”.
Por lo tanto, la implicación es que si los buenos desarrolladores de pronto se volvieran muy baratos, todos los comprarían para usarlos en optimización y mucho software podría volverse más rápido de golpe. Entonces, ¿por qué podrían volverse baratos de pronto los buenos desarrolladores?
Sería bueno poder extender la vida útil del hardware 5 o 10 años más después de la “obsolescencia programada”.
Eso reduciría mucho los residuos electrónicos, dejaría las tierras raras bajo tierra y también bajaría considerablemente las emisiones de gases de efecto invernadero.
Pero las fuerzas de mercado de la producción de software no pagan esos efectos externos. Es mucho más barato lanzar rápido, probar e iterar que planificar y diseñar para el rendimiento. Algunas organizaciones de la industria de los videojuegos encontraron una fórmula para obtener buen rendimiento y ventas al mismo tiempo, pero no se difundió de manera uniforme.
En el software empresarial y de consumo no hay mucho incentivo para incluir criterios de rendimiento en los requisitos. Se diseña para un nivel que el usuario tolere y, como hay que seguir lanzando cambios y funciones, se deja el mayor margen posible. Cada cambio es deuda que puede afectar el rendimiento y la satisfacción del usuario, así que se reserva margen de presupuesto para tolerar la tasa de errores.
Es muy distinto del enfoque de antes, de diseñar y desarrollar a puertas cerradas “hasta que esté listo”.
Deberíamos tener una economía centrada en el cuidado y el mantenimiento, y alinear nuestros esfuerzos macro alrededor del bien de toda la humanidad, no de la riqueza percibida de unos pocos.
Si nos hubiéramos enfocado en mantener vehículos viejos, reutilizar computadoras viejas, etc., los rellenos sanitarios habrían sido más pequeños en relación con el crecimiento.
Claro que probablemente también haya una construcción de teoría de juegos que muestre que el conservacionismo es una estrategia objetivamente inferior.
Hace más de 10 años que es posible correr el motor de emparejamiento de órdenes de una bolsa completa en un solo hilo.
Creo que cierta clase de capacidad de cómputo, el procesamiento de transacciones estrictamente serializado, no ha crecido tan rápido como sugieren otros indicadores. Agregar 31 núcleos no hará que un motor de emparejamiento de órdenes sea más rápido; incluso puede hacerlo más lento.
Si tu producto procesa menos de unos cuantos millones de transacciones por segundo y aun así está buscando un clúster de máquinas, deberías retroceder unos 15 pasos y empezar de nuevo desde cero.
El diseño original por sí solo todavía habría satisfecho el 99% de los casos de uso, y considerando la capacidad de cómputo local actual, hasta se podría correr todo el mercado en una sola máquina.
¿Será que no hay suficiente cálculo adicional aparte de ordenar por tiempo y precio?
Si cada transacción requiriera un procesamiento más complejo, no se podrían manejar tantos casos. Aunque, si uno no es del dominio, es difícil imaginar qué procesamiento más complejo sería necesario.
Es cierto. Este es un problema económico, es decir, un problema de asignación de recursos
Es la elección entre hacer que alguien dedique más tiempo a optimizar software o que cree más funciones. Si lo segundo genera más efectivo, le van a encargar eso; si lo primero se vuelve importante para el flujo de caja, le van a encargar eso
Este es un caso claro de externalidad negativa que las empresas de software imponen al público. La mayoría de las empresas de software no pagan el costo real de la energía, el tiempo perdido y los residuos electrónicos adicionales, así que no se preocupan por optimizar
Muchas veces una optimización exhaustiva no tiene demasiado sentido, pero la idea de simplemente agregar más servidores en lugar de reescribir es un estado triste
No uso la mayoría de las funciones nuevas de macOS, Windows o Android. Lo que quiero es un entorno eficiente para ejecutar apps y mejoras de seguridad. Varias mejoras, como la app de Configuración de macOS, tampoco me dejan muy satisfecho
Con el software de diseño pasa lo mismo. No uso la mayoría de las funciones nuevas que agregó Adobe, y podría estar perfectamente feliz con Illustrator o Photoshop de hace 10 años. Lo que quiero es software menos inflado
En audio y producción musical, el flujo de trabajo todavía está mejorando, así que sí quiero funciones nuevas, pero no a costa de la eficiencia
Para un editor de código, las funciones de VSCode me alcanzan. No necesito más; quisiera un LSP mejor, pero eso no es el núcleo del editor. Eso sí, me gustaría que VSCode fuera más rápido y consumiera menos memoria
La optimización de software resulta atractiva de una forma parecida. Pero si el problema es “dedicar varias horas de ingeniería cara a optimizar” frente a “poner más RAM barata”, gana la opción más barata. A veces el problema es lo bastante grande como para que valga la pena optimizar
El mercado decidirá qué opción vale la pena perseguir. Cuando se llegue a los rendimientos decrecientes de seguir tirando más hardware al problema, se optimizará el software. La ley de Moore se está desacelerando, pero parece que todavía no llegamos a ese punto
Pero la realidad se parece más a lo contrario. Si viene con una etiqueta de precio más baja, preferirán incluso una versión con peor rendimiento
Más que una refutación a Carmack, hay un caso concreto en el que pienso a veces
Las apps Electron están en algún punto entre algo que los consumidores toleran por sus problemas de rendimiento y algo que detestan, pero posiblemente sean la innovación individual que hizo práctico usar una laptop Linux en el trabajo. Por ejemplo, poder entrar a una reunión de MS Teams sin instalar nada es realmente útil
Así que todos se lamentan de que hoy ya no haya nada codificado de forma tan compacta como Winamp, pero se olvidan de las tres letras del principio
Hay bastantes posibilidades de que también corra en Linux, pero el software Electron es pésimo en cualquier plataforma
En 2010 trabajaba como personal de limpieza y, como algo secundario, hacía de responsable de IT
En ese entonces le dije a la empresa que cualquier laptop de los últimos 5 años, más o menos de Nehalem en adelante, tenía rendimiento suficiente para trabajar con hojas de cálculo. Eso era básicamente todo lo que hacían, y con 2 núcleos, 16 GB de RAM y un SSD SATA de 500 GB alcanzaba. Solo algunas personas de marketing necesitaban equipos un poco más potentes, pero la diferencia no era grande, y ahorraron mucho dinero al no comprar laptops tope de gama de última generación
Ya no trabajo ahí, pero estoy seguro de que esas computadoras todavía hoy deberían ser perfectamente adecuadas para hojas de cálculo. El flujo de trabajo no cambió mucho; lo que cambió fue el software. Si las hubieran seguido actualizando, no sé si ahora podrían “correr” MS Windows 10 u 11, pero es muy probable que el bloat y, sobre todo, las hojas de cálculo solo en línea hayan reducido mucho la productividad
El internet de ese lugar también era pésimo. Las opciones eran un DSL asimétrico de unos 16 Mbit que costaba 300 dólares al mes por ser “empresarial”, o cable Comcast de 120 Mbit por 500 dólares al mes. Incluso 120 Mbit apenas alcanza para hojas de cálculo solo en línea, y 16 Mbit definitivamente no alcanza. Lo peor es que, si se cae internet, el negocio se detiene
Esto es exactamente el robo del que hablaba otro comentario, y estoy totalmente de acuerdo. No hay ninguna razón para que una laptop que edita y actualiza hojas de cálculo en una oficina requiera internet, recursos de cómputo o almacenamiento absurdos, ni un gran ancho de banda
No hay excusa para el rendimiento terrible de las computadoras actuales, salvo trasladar el costo a los clientes, tanto personas como empresas
https://news.ycombinator.com/item?id=43971960
El mundo funciona sobre funcionalidad, no sobre software elegante, rápido y sin bugs
Para el usuario final, no hay diferencia entre una función que no existe y un bug. Tampoco hay una diferencia significativa entre que una tarea tarde 5 minutos en completarse por mal rendimiento y que el usuario tenga que hacer manualmente lo mismo durante 5 minutos porque falta una función. En ambos casos es “lento”
Si sigues maximizando el valor para el usuario final, inevitablemente terminas creando software lento y lleno de bugs. Además, si les preguntas a los usuarios si prefieren menos funciones a cambio de algo más rápido y con menos bugs, sorprendentemente dicen que no. Más importante aún: en el mundo empresarial, muchas veces quien compra el software no es el usuario final, y esas personas quieren más funciones y les importan menos el rendimiento y la elegancia
Si el conjunto de funciones es el mismo, usuarios y compradores elegirán el software más rápido, con menos bugs y más elegante. Pero si falta aunque sea una función, pierdes. La razón para mantener el software rápido y elegante es que así tienes la mayor probabilidad de poder seguir agregando funciones sin terminar con un producto con menos capacidades
Una solución rápida y elegante puede recibir buenas reseñas y elogios por lo bien que se siente usarla. Por eso puede parecer un factor importante. Pero, al final, si no hace lo que uno quiere, ni siquiera la compran. Si tiene una función clave necesaria, elegirán ese desastre lento, molesto y lleno de bugs
También hay que recordar que Microsoft ahora tiene que arrastrar a los usuarios, pataleando y gritando, hacia la siguiente versión de Windows. Si hubiera dejado que los usuarios decidieran por sí mismos, muchos no habrían actualizado después de Windows XP. Y eso pese a que las versiones posteriores tenían muchas funciones nuevas y bonitas
Estoy de acuerdo en que las empresas y los inversionistas quieren funciones en sí mismas, pero los usuarios definitivamente no
Si fuera posible, nadie volvería a actualizar nada. Basta ver cuánto se esfuerza Microsoft para que la gente actualice. Nunca he oído a nadie decir que quería una nueva versión de Windows, Office, Slack, Zoom, etc.
Esta también es la razón por la que todo, como Photoshop, se fuerza hacia la nube. La gran mayoría no quiere las nuevas funciones que se ofrecen, incluidos los compradores empresariales. La forma de mantener los ingresos es hacer que la gente compre, independientemente de si se entregan funciones o no
Dicho eso, los usuarios existentes ya están haciendo lo que necesitan con el software, así que una nueva función puede permitirles eliminar otro software o hacer algo nuevo. Pero si esa nueva tarea fuera realmente importantísima, ya habrían buscado otro software para hacerla, lo que significa que hasta ahora pudieron vivir sin ella. Por eso creo que, si los usuarios existentes fueran realmente reflexivos, primero pedirían mejoras de rendimiento y quizá unas cuantas mejoras pequeñas
En cambio, los usuarios potenciales todavía no conocen el software, o necesitan alguna otra función antes de considerarlo útil. Ellos son quienes buscan razonablemente nuevas funciones
Por lo tanto, la decisión de “funciones vs. rendimiento” también es una señal de si la prioridad del desarrollador es sumar usuarios nuevos o satisfacer a los usuarios existentes. Es natural que los técnicos prefieran lo segundo. Porque ya jugaron este juego y saben que quieren ser prioridad durante el largo período de uso real, no solo durante la adquisición
El software con muchos bugs y lento, pero rico en funciones, domina el mercado porque las empresas priorizan primero el crecimiento. La historia está llena de software hermoso y elegante que los usuarios extrañan, pero que no logró difundirse lo suficiente como para que la empresa perdurara
El compromiso existe en ambos sentidos. La mayoría de las personas pasan más tiempo como usuarios que como usuarios potenciales. Es muy probable que esta sea una causa importante de la percepción general de que el software y las computadoras actuales son increíblemente malos
El dinero que se gasta en más RAM y mejores CPU para computadoras domésticas y de oficina permite que todo el software que corre sobre ellas se lance más barato y con más funciones