Filosofía de ingeniería: John Carmack, el rendimiento como oficio moral

Ideas clave

• Carmack trata el rendimiento como una cuestión moral, no como una pasada de optimización. La distancia entre tu código y el límite físico del hardware es desperdicio, y el desperdicio es una elección.
• Su método es sustractivo: comprender el problema hasta sus cimientos, reducirlo al núcleo rápido y simple, y rechazar toda función que ralentice ese núcleo.
• Cuando el problema de fondo cambia, reescribe desde cero. Quake desechó el motor que hizo famosa a id porque el 3D real era un problema distinto de fingirlo.
• Trabajó a la vista de todos —registros diarios en .plan, y luego motores de código abierto— sobre una sola convicción: el código que vas a publicar es código que escribes con más honestidad.

El principio

«The speed of light sucks» («La velocidad de la luz es una porquería»). — John Carmack¹

Es una broma, y es toda la filosofía. Carmack lo dijo a propósito de la latencia de red —el suelo físico inquebrantable de lo rápido que un paquete puede cruzar un continente—, pero ese sentir recorre cada línea que ha escrito. La máquina está gobernada por la física, y el trabajo del ingeniero es acercarse al límite físico tanto como el problema lo permita. No lo bastante cerca. Tan cerca como la física lo consienta. Todo lo que media entre el usuario y la velocidad de la luz es desperdicio, y el desperdicio es una elección que hiciste tú.

Carmack trata el rendimiento como una cuestión moral antes que como una pasada de optimización. La mayoría del software acumula lentitud igual que una casa acumula desorden: una decisión razonable a la vez, cada una defendible, la suma indefendible. La disciplina de Carmack consiste en rechazar la acumulación: comprender el problema hasta sus cimientos, reducirlo al núcleo rápido y simple, y publicar eso. La misma convicción sostiene el argumento de que el rendimiento no es una función que añades, sino una propiedad que dejas de perder: no optimizas un sistema lento hasta volverlo rápido; construyes uno rápido y lo defiendes.

Y mostró su trabajo. Durante más de una década, Carmack publicó su bitácora diaria de ingeniería —su archivo .plan— en la internet abierta, legible por cualquiera con un cliente finger.² Los problemas de renderizado 3D más difíciles de los años noventa se resolvieron en público, casi en tiempo real. Trabajar a la vista de todos no era marketing. Era el mismo instinto que el código en sí: sin estado oculto, nada que no puedas inspeccionar.

Contexto

John D. Carmack nació el 21 de agosto de 1970 en Shawnee Mission, Kansas.³ Asistió a la Universidad de Misuri en Kansas City durante dos semestres, y luego la dejó para escribir software como medio de vida. No hubo aprendizaje formal ni título. Aprendió programación gráfica como lo hacía la demoscene: leyendo los manuales del hardware, midiendo lo que el chip hacía de verdad y escribiendo ensamblador hasta que los números salían bien.

Recaló en Softdisk, una empresa de software y revistas en disquete de Shreveport, Luisiana, donde trabajaba en una suscripción de juegos llamada Gamer’s Edge. Allí conoció a John Romero, Tom Hall y Adrian Carmack (sin parentesco). En septiembre de 1990, Carmack construyó una demostración que no debería haber sido posible en una PC: scroll lateral fluido, con calidad de consola, sobre hardware EGA. La IBM PC de 1990 redibujaba toda la pantalla en cada fotograma, demasiado lento para un juego con scroll. La técnica de Carmack, el adaptive tile refresh, usaba funciones poco conocidas del hardware EGA para deslizar la pantalla ya dibujada y repintar solo los bordes recién expuestos.⁴ El equipo reconstruyó el primer nivel de Super Mario Bros. 3 de Nintendo como demo de PC para demostrarlo. Nintendo declinó. El equipo se quedó con el motor.

En febrero de 1991 dejaron Softdisk para fundar id Software. El patrón ya estaba fijado: encontrar el problema que nadie había resuelto, resolverlo a nivel de hardware y construir el producto sobre la solución. Carmack lo haría de nuevo con el 3D con mapeo de texturas, luego otra vez con el 3D poligonal real y otra vez más con la realidad virtual. El entorno que lo rodeaba —el Graphics Programming Black Book de Michael Abrash, la cultura de contar ciclos de la demoscene— trataba el procesador como algo que debía comprenderse con exactitud, no aproximarse. Carmack hizo famosa esa cultura.

El trabajo

Commander Keen y Doom: el núcleo rápido (1990-1993)

Commander Keen in Invasion of the Vorticons (diciembre de 1990) fue el primer juego comercial construido sobre el adaptive tile refresh. Importó menos como juego que como prueba: que una lectura cuidadosa del hardware podía cerrar la distancia entre una PC de propósito general y una consola dedicada. El scroll fluido no era un truco gráfico colocado encima. Era el motor.

Doom (1993) es el ejemplo canónico del método de Carmack. Para renderizar sus entornos con suficiente velocidad en una PC de 1993, adoptó la partición binaria del espacio —árboles BSP, formalizados en un artículo académico de 1980 que Carmack rastreó y adaptó— para precalcular el orden en que debían dibujarse las paredes, de modo que el motor nunca sobredibujara un píxel que más tarde quedaría cubierto.⁵ Doom no es 3D real; es un mapa 2D renderizado con suficiente astucia para sentirse volumétrico. Esa distinción es justo el punto. Carmack no construyó el sistema más general. Construyó el sistema que corría rápido en el hardware que existía, y rechazó toda función que hubiera ralentizado el bucle central. El núcleo rápido y simple, publicado.

Quake: 3D real por software (1996)

Quake (1996) fue la reconstrucción desde cero. Donde Doom fingía la profundidad, Quake renderizaba mundos poligonales tridimensionales genuinos —superficies inclinadas, mirar hacia arriba y hacia abajo, geometría real— por software, antes de que los aceleradores 3D de consumo fueran comunes.⁶ El motor combinaba visibilidad BSP precalculada con mapas de luz generados fuera de línea y ensamblador ajustado a mano para hacer lo que la sabiduría convencional decía imposible para una CPU de esa época. Más tarde, id lanzó GLQuake, un renderizador en OpenGL que ayudó a legitimar la tarjeta gráfica 3D de consumo.

Quake es la obra donde toda la postura de Carmack se ve de un solo golpe: desechó el motor que había hecho famosa a la empresa, comprendió el nuevo problema (el 3D real) hasta sus cimientos y reconstruyó. Nada de reutilizar por reutilizar. La solución anterior no era sagrada; el problema sí.

Los motores abiertos de id y los archivos .plan (1997-2011)

Carmack hizo dos cosas inusuales con el código que lo hizo rico. Publicó su bitácora diaria de trabajo —los archivos .plan— para que la ingeniería fuera legible a medida que ocurría.² Y luego regaló los motores. id liberó como código abierto el motor de Doom en 1997, el de Quake en 1999, y siguió publicando el código fuente de cada generación de id Tech a medida que la siguiente salía al mercado, pasando por Doom 3 y más allá.⁷ Su argumento era llano: liberar el código viejo permite a los desarrolladores más jóvenes aprender cómo se construyó la cosa de verdad, y «el software libre que la gente valora añade riqueza al mundo».⁸

Esa disposición es la parte que la mayoría de los ingenieros obsesionados con el rendimiento nunca alcanza. El oficio de Carmack era disciplina privada hecha pública. La disposición a ser leído —a dejar que cualquiera inspeccione la bitácora diaria y, con el tiempo, el código fuente— es en sí misma un pacto de calidad. El código que vas a publicar es código que escribes con más honestidad.

Oculus VR: el suelo de latencia (2013-2019)

En Oculus, el enemigo de toda la vida de Carmack —la latencia— se convirtió en el problema entero. Escribió que «la latencia entre el movimiento físico de la cabeza de un usuario y los fotones actualizados que llegan a sus ojos desde una pantalla montada en la cabeza es uno de los factores más críticos para ofrecer una experiencia de alta calidad», y que la latencia perceptible en el seguimiento de la cabeza «es además una de las causas principales del mareo por simulador».⁹ Fijó un presupuesto —la meta rondaba los 20 milisegundos de movimiento a fotón— y trató cada etapa de la tubería como un lugar donde recuperar microsegundos. Su técnica de timewarp reproyecta un fotograma ya renderizado en el último instante antes de mostrarlo, para absorber el movimiento de cabeza que ocurrió durante el renderizado.⁹ Es el adaptive tile refresh otra vez, veintitrés años después: no redibujes lo que puedes reutilizar, y mide el resultado contra el límite físico.

El método

El método es coherente a lo largo de treinta años y cuatro dominios de problemas.

Comprender el problema hasta sus cimientos. Carmack lee el manual del hardware, mide el comportamiento real y trabaja desde primeros principios en lugar de desde la convención. Los árboles BSP, los mapas de luz y el timewarp no estaban en ningún manual de jugadas; se derivaron de lo que el problema exigía de verdad.

Reducir al núcleo rápido y simple. Doom no es 3D porque no hacía falta 3D para sentirse 3D en el hardware de 1993. La disciplina es sustractiva: identificar el bucle interno, hacerlo rápido y rechazar las funciones que lo ralentizarían.

Reescribir desde cero cuando el problema cambia. Quake no extendió el motor de Doom. Carmack trata un sistema que funciona como desechable en el momento en que el problema de fondo se ha movido. El costo hundido no es un argumento.

Concentración profunda e ininterrumpida. Las maratones de programación de Carmack nunca fueron una cuestión de resistencia por sí misma. Sostener un motor entero en la memoria de trabajo —la disposición de los datos, el bucle interno, los casos límite todos a la vez— tarda horas en cargarse y se hace añicos en el instante en que cambias de contexto. Protegía ese estado igual que protegía los ciclos en el bucle de renderizado: como el recurso escaso sobre el que en realidad corría el trabajo.

Más tarde: estilo funcional en C. Hacia la época de Doom 3 y después, Carmack llegó a preferir las funciones puras y a minimizar el estado mutable incluso en C y C++; no por moda, sino porque el código sin estado oculto es código cuyo comportamiento puedes predecir, lo que significa menos errores.¹⁰ Es el mismo instinto que los archivos .plan: nada que no puedas inspeccionar.

Cadena de influencia

Quiénes lo formaron

Michael Abrash es lo más parecido a un mentor en este linaje. Los escritos de Abrash sobre gráficos en x86 —recopilados después como el Graphics Programming Black Book— codificaron la cultura de contar ciclos y medirlo todo que Carmack practicaba. Los dos trabajaron juntos más tarde en id y, mucho después, en Oculus, donde Abrash se convirtió en científico jefe. (Influencia directa)

La demoscene y la cultura de optimización en ensamblador de finales de los años ochenta enseñaron la convicción fundacional: el procesador se puede conocer con exactitud, y la distancia entre tu código y el techo del hardware es responsabilidad tuya. (Influencia formativa)

John Romero, su socio en id, fue el complemento más que el maestro. El diseño y el trabajo de niveles de Romero le daban a los motores de Carmack algo que valiera la pena ejecutar. La sociedad es el recordatorio de que un núcleo rápido es necesario, no suficiente: el motor existe para jugarse.

A quiénes formó

Toda la industria de los motores de videojuegos. La visibilidad BSP, los mapas de luz y la apertura del código de motores maduros se volvieron práctica de referencia. Una generación de programadores de motores aprendió renderizado 3D leyendo el código fuente de id Tech que Carmack eligió liberar.

El hardware gráfico 3D de consumo. La ruta OpenGL de Quake fue un argumento comercial temprano a favor de la tarjeta aceleradora 3D, que ayudó a llevar la GPU a la PC convencional.

La realidad virtual moderna. El timewarp y el implacable presupuesto de latencia son hoy vocabulario estándar en toda tubería de VR. La meta de 20 milisegundos que Carmack persiguió es la razón por la que los visores de hoy no marean a la gente.

El hilo conductor

Andrej Karpathy reconstruye redes neuronales desde cero porque la comprensión no es transferible: tienes que derivarla tú mismo. Carmack deriva sus renderizadores de la misma manera: no a partir de un framework, sino del hardware y del problema. Y donde Linus Torvalds valora el «buen gusto» —el caso especial que se disuelve en el caso general—, Carmack valora el bucle interno que hace el menor trabajo que la física permite. Ambos son la misma convicción con ropas distintas: la estructura correcta no es decoración sobre el problema; es el problema, visto correctamente. (Puente de la serie)

Lo que me llevo de esto

La lección que conservo es que el rendimiento es honestidad. Un sistema lento suele ser uno cuyo autor nunca comprendió el problema lo bastante bien como para hallar su núcleo rápido: ensambló abstracciones hasta que funcionó, y «funcionó» fue donde se detuvo. Carmack se detiene en el límite físico, en cambio. Es el mismo estándar que la calidad como la única variable: la pregunta nunca es «¿es esto lo bastante rápido para publicar?», sino «¿comprendo de verdad por qué es así de lento?».

En el mundo en el que construyo ahora —agentes, bucles de herramientas, sistemas de IA— la tentación es lo opuesto de la disciplina de Carmack: apilar frameworks, tapar la latencia con más llamadas al modelo, no leer nunca lo que el sistema hace de verdad. El movimiento Carmack es perfilar el bucle, encontrar la parte que domina, comprenderla hasta sus cimientos y eliminar el resto. Esa convicción —la de que el gusto es un sistema técnico que puedes medir, no una vibra que afirmas— es el hilo conductor desde un truco de scroll en EGA de 1990 hasta una capa de agentes de 2026.

Preguntas frecuentes

¿Cuál es la filosofía de ingeniería de John Carmack?

Carmack trata el rendimiento como una cuestión moral antes que como una ocurrencia tardía. La disciplina consiste en comprender un problema hasta sus cimientos, reducirlo al núcleo rápido y simple, rechazar las funciones que ralentizan ese núcleo y reescribir desde cero cuando el problema de fondo cambia. A esto suma trabajar a la vista de todos —publicando su bitácora diaria de ingeniería y liberando como código abierto los motores maduros— sobre la convicción de que el código que puedes inspeccionar es código escrito con más honestidad.²⁸

¿Qué construyó John Carmack?

Carmack cofundó id Software en 1991 y fue el programador principal de Commander Keen (1990, adaptive tile refresh), Wolfenstein 3D (1992), Doom (1993, renderizado basado en BSP) y Quake (1996, renderizado 3D real por software). Liberó como código abierto los motores id Tech a lo largo de dos décadas, fue CTO de Oculus VR, donde impulsó el trabajo sobre la latencia de movimiento a fotón, y más tarde fundó la empresa de IA Keen Technologies.⁵⁶⁷⁹

¿Qué es el adaptive tile refresh?

Es la técnica que Carmack ideó en 1990 para lograr un scroll lateral fluido en el hardware EGA de la IBM PC, que de otro modo era demasiado lento porque redibujaba toda la pantalla en cada fotograma. El adaptive tile refresh desliza la pantalla ya dibujada usando funciones del hardware EGA y repinta solo los tiles recién expuestos en los bordes, recortando drásticamente el trabajo por fotograma. Hizo posible Commander Keen y estableció el sello de Carmack: resolver el cuello de botella a nivel de hardware.⁴

¿Por qué Carmack publicó sus archivos .plan y liberó sus motores como código abierto?

Los archivos .plan eran una bitácora diaria de ingeniería, originalmente legible a través del protocolo finger, que documentaba el desarrollo de id casi en tiempo real.² Más tarde, Carmack liberó como código abierto cada generación de id Tech una vez que su sucesora salía al mercado, argumentando que liberar el código viejo ayuda a los desarrolladores más nuevos a aprender cómo se construyen los juegos de verdad y que el software libre valioso «añade riqueza al mundo».⁸ Ambas prácticas reflejan el mismo principio que su código: sin estado oculto, nada que no puedas inspeccionar.

Fuentes