Doom Sfida l’Impossibile: Funziona nel Sistema di Tipi di TypeScript!

Miliardi di righe, molteplici linguaggi di programmazione e un anno di duro lavoro per far girare Doom a un frame rate non giocabile

In contesto: Doom è stato adattato su dispositivi di ogni tipo, dai calcolatori alle casse dei McDonald’s. Recentemente, si è spinto oltre, tentando di farlo funzionare su piattaforme prive di vera potenza di elaborazione – gli ultimi esempi sono i documenti PDF e Word. Naturalmente, queste modalità sono estremamente lente, ma è sorprendente che il gioco possa essere eseguito su piattaforme non informatiche.

L’ingegnere software Dmitri Mitropoulos ha elevato il porting di Doom su piattaforme non computazionali a un nuovo livello. Il programmatore è riuscito a far funzionare Doom all’interno del sistema di tipi di TypeScript, un’impresa così incredibilmente complessa che gli è ci voluto un intero anno per realizzarla.

TypeScript è un linguaggio sviluppato da Microsoft che si basa su JavaScript aggiungendo un controllo dei tipi statico per individuare gli errori di codifica prima dell’esecuzione. È come un correttore ortografico o grammaticale per il codice, che assicura che funzioni e variabili siano inserite correttamente. È comunemente utilizzato nello sviluppo di grandi applicazioni JavaScript.

Eseguire un gioco all’interno del sistema di tipi di TypeScript è considerato “impossibile”. Anche Mitropoulos ha notato che ha iniziato il progetto per “dimostrare rapidamente” perché non potesse essere fatto. Tuttavia, man mano che procedeva, diventava sempre più ossessivamente motivato a farlo funzionare. Alla fine, anche gli sviluppatori TS più esperti sono rimasti impressionati e senza parole.

La versione di Doom di Mitropoulos funziona all’interno di 3,5 trilioni di righe di tipi, consumando un incredibile quantitativo di 177 terabyte. Compilare un singolo frame richiede 12 giorni, risultando in un frame rate dolorosamente lento di 0,0000009645 al secondo. Il tracker di tipo di TypeScript deve elaborare 20 milioni di istanze di tipo al secondo per generare l’output, risultando in un frame rate estremamente basso.

LEGGI  EFF lancia strumento open-source per rilevare spionaggio cellulare non autorizzato

Nonostante l’enorme sovraccarico, Mitropoulos ritiene che siano possibili miglioramenti delle prestazioni. Nel server Discord di TypeScript del Michigan, ha suggerito che la compilazione potrebbe essere ridotta da “1 a 12 ore” con ulteriori ottimizzazioni. Ha già identificato aree in cui può migliorare la velocità.

Per rendere tutto ciò possibile, ha costruito una macchina virtuale interamente da tipi TypeScript, includendo implementazioni logiche di tutte le 116 istruzioni WebAssembly necessarie per eseguire Doom. Ogni elemento di un computer funzionante – RAM, spazio su disco, persino una cache della CPU L1 – doveva essere ricreato scrupolosamente all’interno del sistema di tipi. Poiché TypeScript consente solo iterazioni di stringhe da sinistra, ha dovuto inserire algoritmi binari al contrario.

L’esecuzione del programma richiedeva un runtime WebAssembly personalizzato, elaborando tutto all’interno di un editor TypeScript. Anche il compilatore TypeScript doveva essere modificato per gestire la scala estrema del progetto, poiché il solo tracker di tipo consumava oltre 90GB di RAM durante l’esecuzione.

Mitropoulos ha descritto lo sforzo come una sfida estenuante. Ha scritto 12.364 test manuali, appreso molteplici linguaggi di programmazione e inizialmente stimato che il progetto avrebbe richiesto fino a 1,25 petabyte prima dell’ottimizzazione. A un certo punto, compilare un singolo frame richiedeva tre mesi di continua istanziazione di tipo. Ha osservato che l’IA non è stata d’aiuto.

“Ah, e l’IA non può aiutare con nulla di tutto ciò,” ha detto Mitropoulos nel suo breve video esplicativo di sette minuti (masthead). “È così a basso livello che non ci sono array, oggetti, stringhe o booleani all’interno del motore – solo numeri binari e Doom utilizza solo interi a 64 e 32 bit. E questi interi non sono né con segno né senza segno. Ho impiegato un’intera giornata per capire questo.”

LEGGI  YouTube: Problemi di Qualità Video, Utenti in Rivolta per la Bassa Risoluzione!

L’arduo compito ha richiesto un intero anno di giornate di 18 ore per essere completato. Altri sviluppatori TS avevano così tante domande sul progetto che Mitropoulos prevede di rilasciare altri due video per spiegare i dettagli altamente tecnici e le sue motivazioni. Per ora, abbiamo un’altra prova che Doom può girare su qualsiasi cosa, incluso ciò che non è mai stato pensato per eseguire giochi.

Messaggi simili: