Carmack cumple años: optimizar es saber qué no hay que calcular
John Carmack nació el 20 de agosto de 1970. Su carrera es una nota al pie del mismo principio: el scroll del PC, el orden de dibujado de Doom y la publicación de los motores no salieron de calcular más rápido, sino de mover el cálculo a otro momento o de no hacerlo.
Hoy, 20 de agosto, cumple años John Carmack. Nació en 1970 en Roeland Park, Kansas, y es responsable de que una generación entera descubriera que su ordenador podía hacer cosas que el fabricante daba por imposibles.
Es un buen día para hablar de optimización, porque su carrera entera es una nota al pie del mismo principio: la forma de que algo vaya rápido casi nunca es calcularlo más rápido, sino no calcularlo.
John Carmack en la QuakeCon de 2023. Foto: QuakeCon, CC BY 2.0, vía Wikimedia Commons.
El scroll que el PC no podía hacer
- Las consolas de Nintendo tenían hardware dedicado para desplazar el fondo de la pantalla, así que los juegos de plataformas iban suaves. El PC no lo tenía. Para mover el escenario un píxel había que redibujar la pantalla entera, y la pantalla entera no cabía en el presupuesto de tiempo.
La conclusión sensata del sector era que el PC no servía para eso.
La conclusión de Carmack fue otra: si mover el fondo un píxel obliga a redibujar todo, que no obligue. Aprovechó registros de la tarjeta EGA para desplazar la memoria de vídeo y redibujó únicamente la franja nueva que entraba por el borde. Adaptive tile refresh. El resultado fue Commander Keen, y de ahí salió id Software en 1991.
Fíjate en la estructura del razonamiento, porque se repite: nadie hizo el redibujado más rápido. Alguien se preguntó por qué había que redibujar.
Wolfenstein, Doom y la trampa honesta
Wolfenstein 3D y Doom fueron para mucha gente el primer mundo tridimensional que pisaron. Técnicamente no lo eran, y además no funcionaban igual, cosa que conviene no mezclar.
Wolfenstein 3D dibujaba el escenario lanzando rayos sobre una cuadrícula: los mapas eran una rejilla de celdas con paredes en ángulo recto y altura fija, y para cada columna de la pantalla se avanzaba por esa rejilla hasta chocar con una pared. Barato y rapidísimo, a cambio de un mundo muy rígido.
Doom permitía geometría bastante más libre —paredes en cualquier ángulo, suelos y techos a distintas alturas—, aunque seguía sin admitir una habitación exactamente encima de otra. Y ahí el problema gordo era en qué orden dibujar las superficies para que las cercanas tapen a las lejanas. Resolverlo por fuerza bruta en cada fotograma no cabía en el presupuesto, así que Carmack recurrió a los árboles BSP, una técnica descrita en literatura académica de los años setenta que nadie estaba usando en juegos: el nivel se divide y se ordena una vez, al construirlo, y en tiempo de ejecución solo hay que recorrer ese árbol.
En los dos casos, la limitación no era una carencia: era el presupuesto. Al renunciar a la generalidad se podía dibujar el resultado con la aritmética disponible en un 386.
De nuevo lo mismo: el trabajo no se aceleró, se movió a un momento en el que sobraba tiempo.
Y de paso, la lección menos glamurosa de todas: leer. La solución llevaba veinte años publicada. Estaba en una biblioteca, no en un momento de inspiración.
El presupuesto de tiempo como criterio de diseño
Si tienes 16 milisegundos por fotograma, no tienes una aspiración: tienes un presupuesto. Y un presupuesto convierte las discusiones de arquitectura en aritmética.
Es la parte de aquella forma de trabajar que mejor se traslada a lo que hacemos hoy, donde casi nadie tiene un número:
- «La página va lenta» no es un objetivo. «El HTML tiene que salir del servidor en menos de 200 ms en el percentil 95» sí lo es.
- «El informe tarda» no es un objetivo. «El informe mensual tiene que estar antes de las 8:00» sí, y además decide sola la discusión de si se precalcula por la noche.
- «Hay que optimizar la consulta» no es un objetivo. «Esta consulta no puede pasar de 50 ms porque va en el camino crítico del carrito» sí.
Sin número no hay optimización: hay opiniones sobre elegancia. Con número aparecen solas las tres preguntas útiles: qué se puede precalcular, qué se puede cachear y qué se puede directamente no hacer.
Esa tercera es la que casi nadie se plantea, y es la que más veces gana. La consulta más rápida es la que no se lanza. El mismo principio de dosificar el esfuerzo que hace que los anillos de Sonic funcionen como un botón de deshacer: decidir qué se procesa y qué se descarta.
Publicar el motor
En 1997 se publicó el código fuente de Doom, al principio con una licencia restrictiva que solo permitía usos no comerciales; en 1999 se relicenció bajo GPL, y ese mismo año se publicó también el de Quake directamente bajo GPL. El motor entero, encima de la mesa.
La consecuencia la conoces aunque no sepas que viene de ahí: Doom funciona en cualquier cosa. Calculadoras, cajeros, termostatos, test de embarazo modificados, un lector de PDF. Es un chiste de internet que existe porque hace treinta años alguien publicó el código en lugar de guardarlo.
Y no fue caridad. Fue una decisión perfectamente racional sobre dónde estaba el valor: en la marca, en los juegos nuevos y en el motor de la generación siguiente, no en un código de 1993 que ya no vendía licencias. Exactamente la misma pregunta que se hizo mal en el IBM PC: qué capa abres y qué capa te quedas.
Los ficheros .plan
Detalle poco recordado y muy adelantado: durante años Carmack mantuvo un fichero .plan, accesible con el comando finger, donde apuntaba en qué estaba trabajando. Casi a diario. Problemas abiertos, callejones sin salida, decisiones cambiadas.
Era un registro público de trabajo en curso, quince años antes de que a eso se le llamara devlog o building in public. Y tenía dos efectos que siguen valiendo: obligaba a formular por escrito lo que aún no estaba resuelto —que es la mitad de resolverlo— y dejaba un rastro de por qué las cosas se hicieron así.
Tu equivalente moderno no necesita audiencia. Un archivo de decisiones en el repositorio, con fecha y con el motivo, hace el mismo trabajo. La versión de dentro de un año de ti mismo lo agradecerá bastante.
Feliz cumpleaños
Cuatro cosas para hoy:
- Ponle un número al problema de rendimiento más citado de tu proyecto. Milisegundos, no adjetivos.
- Busca el cálculo que se repite y que podría hacerse una sola vez. Suele estar dentro de un bucle y suele llevar años ahí.
- Busca el paper. Antes de inventar un algoritmo, media hora de búsqueda. Es muy probable que alguien lo publicara cuando tú no habías nacido.
- Escribe hoy tu
.plan. Tres líneas: en qué estás, qué te ha bloqueado, qué has descartado y por qué.
(Y si algún día alguien consigue ejecutar Doom en tu producto, enhorabuena: significa que tienes pantalla, memoria y bucle de eventos, que es más de lo que muchos pueden decir.)
Preguntas frecuentes
¿Quién es John Carmack y por qué es relevante?
Es un programador estadounidense nacido el 20 de agosto de 1970, cofundador de id Software y autor de los motores gráficos de Commander Keen, Wolfenstein 3D, Doom y Quake. Su relevancia procede de haber demostrado repetidamente que hardware considerado insuficiente para determinadas tareas podía ejecutarlas mediante un replanteamiento del algoritmo, y de haber contribuido a difundir prácticas como la publicación del código de motores gráficos ya amortizados.
¿Qué es el adaptive tile refresh?
Es la técnica que permitió el desplazamiento lateral fluido en ordenadores PC con tarjeta EGA, que carecían del hardware específico presente en las consolas de la época. En lugar de redibujar la pantalla completa en cada fotograma, aprovecha los registros de la tarjeta para desplazar el contenido ya presente en la memoria de vídeo y dibuja solo la franja de escenario que entra por el borde, reduciendo drásticamente el trabajo por fotograma.
¿Qué es un árbol BSP y qué problema resuelve en Doom?
El particionamiento binario del espacio es una estructura de datos que divide recursivamente un espacio mediante planos y permite determinar el orden correcto de dibujado de las superficies desde cualquier punto de vista. En Doom resuelve el problema de qué paredes ocultan a cuáles sin recalcularlo en cada fotograma: el árbol se construye una sola vez al compilar el nivel y durante la ejecución basta con recorrerlo. La técnica procedía de literatura académica previa al juego.
¿Por qué se publicó el código fuente de Doom y Quake?
El código de Doom se publicó en 1997 con una licencia inicialmente restrictiva, que solo permitía usos no comerciales, y se relicenció bajo GPL en 1999; el de Quake se publicó ese mismo año directamente bajo GPL. La decisión llegó cuando esos motores ya no constituían la fuente principal de ingresos de la compañía, cuyo valor residía en los títulos nuevos y en las tecnologías posteriores. La publicación permitió que la comunidad los adaptara a plataformas muy diversas, que es el origen de que Doom acabara ejecutándose en prácticamente cualquier dispositivo con pantalla.
¿Qué era un fichero .plan?
Era un archivo de texto accesible mediante el comando finger de Unix en el que algunos desarrolladores publicaban su estado de trabajo. Carmack lo actualizaba con frecuencia casi diaria describiendo problemas abiertos, decisiones adoptadas y vías descartadas. Constituye un precedente del registro público de desarrollo y cumple la misma función que hoy desempeñan los registros de decisiones de arquitectura dentro de un repositorio: conservar el motivo de cada elección, no solo su resultado.
¿Usaban Wolfenstein 3D y Doom la misma técnica de dibujado?
No. Wolfenstein 3D empleaba lanzamiento de rayos sobre una cuadrícula: el mapa era una rejilla de celdas con paredes en ángulo recto y altura uniforme, y para cada columna de pantalla se recorría esa rejilla hasta encontrar una pared. Doom admitía una geometría bastante más flexible, con paredes en cualquier ángulo y sectores a distintas alturas, aunque tampoco permitía situar una estancia exactamente sobre otra, y utilizaba árboles BSP para resolver el orden de dibujado. Son dos aproximaciones distintas a un mismo objetivo.
Otras noticias
El tío Juanma: Madrid, la puerta que me abrió y el hockey de Pablo y Jon
Hace unos días murió mi tío Juanma, el hermano de mi madre. Estos últimos años nos habíamos distanciado, y eso también lo cuento aquí. Pero antes hubo un Madrid, una casa que me acogió y una puerta que él me abrió cuando yo estaba empezando.
Leer más →
Cuatro noches, cuatro sitios y dieciséis años haciendo la web de la Semana Grande
Este año Pablo y Jon ya hicieron sus propios planes, así que la Semana Grande fue para Elena y para mí: cuatro noches de fuegos desde cuatro sitios distintos. Y, tras dieciséis años construyendo semanagrande.com, por primera vez la puse a prueba como usuario y descubrí que no me bastaba.
Leer más →
Adiós a Tamariz: el mago que te dejaba creer que lo habías pillado
Juan Tamariz murió ayer a los 83 años. Fui a verlo al Kursaal con mi padre y no me acuerdo de ningún juego: me acuerdo de cómo sonaba la sala, silencio y carcajadas a partes iguales. Sobre las pistas falsas, la baraja Mnemónica, los cinco puntos mágicos y por qué comprarse los libros no convierte a nadie en mago.
Leer más →El blog, día a día
¿Te ha resultado útil o quieres comentar algo?
Hablemos →