Advent of Code 2022: L’arbre qui cache la forêt

L’algorithme de cet exercice était très chouette car il m’a poussé aux limites.

J’ai eu du mal à faire rentrer le jeu de données dans la RAM.

J’ai essayé de le rentrer sur disquette, avec succès, mais y accéder ensuite était extrêmement trop lent.

J’ai fini par trouver comment faire un tableau d’entiers : DIM TREE%(100,100), qui prennent 2 octets par entrée, au lieu de flottants : DIM TREE(100,100) qui prennent 5 octets par entrée. (AppleSoft II Greenbook, page 137 du pdf). 100 chaînes de 100 caractères c’était trop aussi.

J’ai trouvé la réponse après un run de deux heures échoué, puis un run d’une heure trente réussi.

Plus tard, j’ai voulu ajouter une Visualisation, comme d’autres joueur·euse·s font sur Reddit. Tout d’abord j’ai échoué : les pages vidéo font partie de la mémoire libre accessible, et elles finissent par se remplir de données lorsqu’on a beaucoup de variables. Ma première visualisation ressemblait donc à ça :

On voit que c’est le bazar dans les octets.

Mais après plus de recherches, j’ai trouvé comment se divise la mémoire libre et j’ai pu protéger la page HGR (High resolution Graphics) avec LOMEM: 16384.

Je vous livre donc fièrement le résultat de cette visualisation (accéléré 16 fois parce que sinon, c’est long : 15 minutes – oui, au fil de l’eau, j’ai bien optimisé l’algorithme. Cependant ces 15 minutes ne comptent pas l’envoi du jeu de données, fait juste avant, et qui prend aussi 15 minutes). Le voici :

C’est beau un peu je trouve