La fourmi de Langton est une simulation informatique.
Elle se base sur une fourmi virtuelle qui se déplace sur une grille de pixels noirs ou blancs. A chaque étape, elle change la couleur du pixel sur lequel elle se trouve, et bouge en suivant ces règles :
- si le pixel sur lequel elle est est noir, elle tourne à droite et avance d'une case
- si le pixel sur lequel elle est est blanc, elle tourne à gauche et avance d'une case
Avec ces règles simplistes, il ne semble pas y avoir beaucoup de choses à faire, mais on reparque que au bout d'un certain temps (quelques milliers d'étapes), la fourmi se met à construire une autoroute, c'est-à-dire qu'elle avance en ligne droite (enfin presque, faites tourner le programme et vous comprendrez) et en laissant derrière elle une trace (l'autoroute justement).
Alors voilà, j'ai un petit problème avec ce programme, et je sais pas si ça valait le coup d'ouvrir un topic juste pour ça (d'ailleurs je crois que j'ai pas assez de points) :
Quand je fait tourner le programme, la vitesse de calcul des générations diminue peu à peu (j'ai d'abord imaginé que la VRAM se remplissait), mais au bout d'un moment il revient d'un seul coup à la vitesse maximale, puis redescend lentement etc.
quelqu'un à une explication ? généralement, mon prof de maths dit que le bug est entre la calculatrice et la chaise.
C'est marrant cet effet de vitesse. La VRAM ne se «remplit» pas plus que ton écran ne se «remplit». Le blanc et le noir prennent tous les deux la même place. À vue de nez, rien dans ton code ne justifie cet effet.
Par contre il se peut que le tas de Python se remplisse au fur et à mesure et qu'il le nettoie périodiquement... auquel cas la lenteur serait celle des allocations et des libérations. Mais je mets une réserve sur cette interprétation, je ne sais pas exactement comment la durée de vie des variables MicroPython est gérée.
Protip pour gagner un peu de vitesse : créer le tuple (0,0,0) et le tuple (255,255,255) à chaque tour est vraiment lent (et consomme du tas), stocke-les dans des variables à la place !
Autre astuce : %4 peut devenir &3, je sais pas si ça change quoi que ce soit en perfs globales mais localement ça aide (en C ça serait 30 à 60 fois plus rapide x3).
ok, bah merci beaucoup !
j'ai testé tes 2 optimisations ! Pour le % en &, j'ai à peine vu la différence (après c'est pas ce qui prenait le plus de temps...), mais en stockant les tuples dans des variables, on obtient un résultat très étrange: la période des changements de vitesse augmente (dans ta proposition, le tas mettrai plus de temps avant d'être vidé). C'est encore plus bizarre ! Après j'avais déjà eu des gros bugs dans les premières versions de micro python (genre des erreurs qui sont localisées à des lignes vides....), et puis c'est un truc récent, donc c'est plutôt normal ce genre de trucs (enfin j'imagine...)
Puisque tu alloues moins dans le tas, si le tas se fait GC quand il devient trop gros, alors c'est normal que la période augmente. En fait je soupçonne que c'est le tas de Casio qui fait ça, il est connu pour avoir ce genre de détails... indésirables.
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
