Por qué fastDOOM es tan rápido

Por qué FastDOOM es rápido

• En el invierno de 2024, mientras restauraba una IBM PS/1 486-DX2 de 66Mhz, terminé probando FastDOOM. El DOOM original corría a 21.5 fps, pero FastDOOM lo hacía a 30 fps, un 30% más rápido.

Contexto histórico

• DOOM fue desarrollado en una NeXT Workstation, y el I/O para DOS fue escrito por id Software. En 1997, el código fuente no se publicó por culpa de una biblioteca de sonido llamada DMX, y en su lugar se liberó la versión para Linux. Después, la comunidad restauró la versión para DOS a través de PCDOOM v2.

Panorama general de la mejora de rendimiento

• Victor "Viti95" Nieto dedicó mucho esfuerzo a mejorar el rendimiento de FastDOOM. Se descargaron 52 lanzamientos de FastDOOM y se comparó su desempeño para analizar qué mejoras se habían introducido.

Arqueología de Git

• Viti95 mostró una capacidad de organización sobresaliente en git: cada commit realizaba una sola tarea y cada lanzamiento estaba etiquetado. El historial de git de FastDOOM está compuesto por 3,042 commits, lo que permitió hacer benchmarks de cada funcionalidad.

FastDOOM v0.1

• Esta versión incluye 220 commits, y la optimización principal consistió en reducir el renderizado de la barra de estado, lo que aportó una mejora de 2 fps.

FastDOOM v0.6

• En esta versión, que incluye 33 commits, se aplicaron optimizaciones como omitir renderizado innecesario y eliminar la indirección del puntero del jugador.

FastDOOM v0.8

• Esta versión, con 282 commits, se enfocó en el renderer en modo texto e incluyó varias optimizaciones.

FastDOOM v0.9.2

• Esta versión, con 110 commits, introdujo optimizaciones en la comparación de skyflatnum y en R_DrawColumn.

FastDOOM v0.9.7

• Esta versión, con 293 commits, incluyó pruebas de cambios en ASM x86 y optimizaciones de selección de CPU.

Modo 13h vs modo Y

• FastDOOM intentó optimizarse para distintos CPU y buses de video. El modo 13h copia datos de RAM a VRAM, mientras que el modo Y escribe los datos directamente en VRAM. El rendimiento de cada modo varía según la velocidad del CPU y del bus.

Optimizaciones adicionales

• Se intentó optimizar usando flags específicos de procesador de OpenWatcom, pero la versión para 386 siempre corría más rápido. FastDOOM busca cambiar el compilador de OpenWatcom v2 a DJGPP (GCC) para generar código más rápido.

Impresión general

• Gracias al extraordinario trabajo de Victor Nieto, FastDOOM mostró un rendimiento sorprendente a través de 3,000 optimizaciones. Aprovechó mejoras ya existentes e introdujo nuevas optimizaciones, lo que le ganó mucha atención.

[GN⁺]

Comentarios en Hacker News

• El build 36 del parche MPV v0.1 contribuyó enormemente a mejorar el rendimiento. La "optimización Cripy" convirtió el renderizado del porcentaje de la barra de estado en un noop cuando no había cambios, lo que aportó una mejora de 2 fps. Al principio parecía difícil de creer, pero al aplicar el parche a PCDOOMv2 se confirmó una mejora de velocidad enorme

  • Los cuellos de botella pueden estar en lugares inesperados, y hace falta perfilar y medir para encontrarlos
  • La estructura de Doom puede ser relativamente clara para los expertos, pero en general no es una parte que uno esperaría identificar como cuello de botella

• Para entender la evolución del rendimiento, se descargaron 52 lanzamientos de fastDOOM, PCDOOMv2 y el DOOM.EXE original, y se creó un RUN.BAT que ejecuta -timedemo demo1 en todas las versiones

  • Al usar NETDRIVE de mTCP, se descubrió que la opción de guardar por red ya existía en el pasado
  • NetDrive es un controlador de dispositivo para DOS que permite acceder a una imagen de disco remota alojada en otra computadora como si fuera un dispositivo local

• El hilo con Ken Silverman en GitHub es muy informativo. Resulta impresionante ver al autor de FastDOOM y a Ken discutir la eficiencia de los registros del 486 y los ciclos de reloj

  • Da gusto que se sigan logrando mejoras de rendimiento en Doom

• La "IBM PS/1 486-DX2 66Mhz, "Mini-Tower", modelo 2168" era una computadora que quise en mi adolescencia pero nunca pude tener

  • En 1992 estaba usando la cuarta PC que armé yo mismo
  • El KCS Computer Show era un recurso excelente para comprar piezas, armar una PC, usarla, venderla y volver a comprar piezas para repetir el proceso
  • A fines de 1992 estaba usando una 486-DX3 100 y un coprocesador matemático ULSI 487
  • Podía presumir que tenía la PC más rápida del campus en ese momento
  • Estudié ciencias ambientales, pero mi carrera terminó relacionada con las computadoras

• No se mencionaron los modos de video únicos de FastDOOM

  • modo texto IBM MDA
  • EGA y Plantronics ColorPlus
  • el clásico CGA azul y rosa
  • CGA, hack 320x200x16 "ANSI from Hell"
  • Hercules
  • la mayoría rinden peor que VGA

• En el pasado habría preferido un 486DX50 antes que un DX2-66. La interfaz de bus de 50 MHz era mejor que la de 33 MHz

• En el documento, el apellido de John Carmack aparece mal escrito como "Carnmack"

• No se entiende la frase "Tenía que tomar ibuprofeno para poder jugar, pero descubrí fastDOOM"

• Para mejorar la legibilidad, podría considerarse agregar una fuente de system UI al HTML. Los bloques de código seguirían mostrándose con una fuente monoespaciada. Las fuentes monoespaciadas no son adecuadas para la prosa

• No entiendo el significado de la frase "Tenía que tomar ibuprofeno para poder jugar, pero descubrí fastDOOM"