Des milliards de lignes, plusieurs langages de programmation et une année de sueur pour exécuter Doom à une fréquence d'images injouable
Dans le contexte: Les gens ont porté un malheur à tout, des calculatrices aux registres en espèces de McDonald's. Il y a récemment eu une poussée pour faire fonctionner le logiciel sur des plates-formes sans alimentation de traitement réelle – PDF et les documents Word sont les derniers exemples. Bien sûr, ces méthodes sont douloureusement lentes, mais il est incroyable que le jeu puisse même s'exécuter sur des plateformes non ordinaires.
L'ingénieur logiciel Dmitri Mitropoulos a porté le portage des plates-formes non computées à un tout nouveau niveau. Le programmeur a réussi à faire fonctionner Doom à l'intérieur du système de type TypeScript – un exploit si complexe de l'esprit qu'il lui a fallu une année entière pour réussir.
TypeScript est un langage développé par Microsoft qui s'appuie sur JavaScript en ajoutant une vérification de type statique pour attraper des erreurs de codage avant l'exécution. Considérez-le comme un vérificateur d'orthographe ou de grammaire pour le code, en garantissant que les fonctions et variables sont saisies correctement. Les développeurs l'utilisent généralement pour créer de grandes applications JavaScript.
L'exécution d'un jeu dans le système de type TypeScript est considérée comme « impossible ». Même Mitropoulos a noté qu'il avait commencé le projet pour «rapidement» prouver pourquoi cela ne pouvait pas être fait. Cependant, alors qu'il y est entré, il est devenu de manière obsessionnelle motivée pour le faire fonctionner. En fin de compte, même les développeurs TS assaisonnés ont été impressionnés et sans voix.
La version de Doom de Mitropoulos se déroule à l'intérieur de 3,5 billions de lignes de types, consommant 177 téraoctets stupéfiants. La compilation d'un seul cadre prend 12 jours, ce qui entraîne un ralentissement atroce de 0,000000009645 par seconde. Le tracker de type TypeScript doit traiter 20 millions d'instanciations de type par seconde pour générer la sortie, ce qui entraîne la fréquence d'images extrêmement lente.
Malgré les frais généraux massifs, Mitropoulos estime que des améliorations des performances sont possibles. Dans le Michigan TypeScript Discord Server, il a suggéré que la compilation pourrait être réduite à « 1 à 12 heures » avec d'autres optimisations. Il a déjà identifié des zones où il peut améliorer la vitesse.
Pour que tout fonctionne, il a construit une machine virtuelle entièrement à partir de types de typeScript, y compris des implémentations logiques des 116 instructions WebAssembly requises pour exécuter Doom. Chaque élément d'un ordinateur fonctionnel – RAM, espace disque, même un cache CPU L1 – devait être minutieusement recréé dans le système de type. Étant donné que TypeScript permet uniquement des itérations de chaîne à partir de la gauche, il a dû saisir les algorithmes binaires à l'envers.
L'exécution du programme a nécessité un exécution de WebAssembly personnalisé, en traitant tout dans un éditeur de typeScript. Le compilateur TypeScript a également dû être modifié pour gérer l'échelle extrême du projet, car son tracker de type a consommé à lui seul plus de 90 Go de RAM pendant l'exécution.
Mitropoulos a décrit l'effort comme un défi exténuant. Il a écrit 12 364 tests manuscrits, appris plusieurs langages de programmation et estimé initialement que le projet nécessiterait jusqu'à 1,25 pétaoctets avant l'optimisation. À un moment donné, la compilation d'un seul cadre a pris trois mois d'instanciation de type continu. Il a fait remarquer que l'IA n'était pas d'aide.
« Oh, et Ai ne peut pas aider avec tout ça », a déclaré Mitropoulos dans sa brève explication vidéo de sept minutes (Masthead). « Il est si de bas niveau qu'il n'y a pas de tableaux, d'objets ou de cordes ou de booléens à l'intérieur du moteur – seuls les nombres binaires et le destin n'utilisent que des entiers 64 bits et 32 bits, c'est tout.
La tâche gargantuesque a pris une année entière de 18 heures à terminer. D'autres développeurs TS avaient tellement de questions sur le projet que Mitropoulos prévoit de publier deux autres vidéos expliquant les détails hautement techniques et ses motivations. Pour l'instant, nous avons un autre élément de preuve prouvant que Doom peut fonctionner sur n'importe quoi – y compris des choses qui n'étaient jamais destinées à exécuter des jeux.
