Dans un
article précédent nous découvrions la capacité de stockage de scripts
Python de ta
NumWorks,
4Kio.
Ces dernières semaines nous t'avons testé et présenté nombre de scripts publiés dans la
bibliothèque NumWorks, dont pas mal de fonctions récursives dessinant des fractales.
En les testant nous avons pu nous rendre compte qu'il était très facile de générer des erreurs avec l'outil de visualisation en ligne, et que même si la vraie calculatrice s'en sortait nettement mieux ce n'était pas la panacée non plus.
Par exemple, une fonction factorielle(n) définie récursivement peut échouer à partir de n=9 pour la visualisation en ligne, et n=42 sur la calculatrice. Le premier cas est ridicule, et le deuxième reste problématique.
Devant ces limitations évidentes, une question se pose : mais quelle est donc la capacité de la mémoire de travail offerte par la NumWorks aux scripts Python ?
Mais nous n'avons pas ici de module permettant de récupérer des informations sur le matériel, alors comment faire ?
En arrivant à déclencher volontairement ces mêmes erreurs avec des scripts beaucoup plus simples, on peut noter que chaque entier
Python utilise 4 octets mémoire
(32 bits). Se basant sur cela, on peut alors développer un script remplissant la mémoire avec des tableaux d'entiers jusqu'à déclenchement d'une erreur à intercepter via une exception, et affichant ce à quoi on est arrivé.
- Code: Tout sélectionner
def mem():
try:
l = [0]
while True:
try:
l = l + l[l[0]:]
except:
if l[0] < len(l)-1:
l[0] = len(l)-1
else:
print("+", 4*len(l))
l[0] = 4*len(l) + mem()
break
except:
return 0
return l[0]
Ci-contre, on note en effet que l'outil de visualisation en ligne ne dispose que de 6,5Kio de mémoire de travail, avec par ordre décroissant :
- un bloc contigu de 4Kio
- un bloc contigu de 2Kio
- ...
Aucune surprise donc aux problèmes rencontrés, il n'y a vraiment pas de quoi aller bien loin avec ça.
Mais passons à la vraie machine. Cela peut varier légèrement, mais en transférant et appelant notre script juste après un
reset nous obtenons effectivement nettement mieux, dans les 13Kio, avec par ordre décroissant :
- deux blocs contigus dans les 4Kio chacun
- un bloc contigu dans les 2Kio
- ...
C'est effectivement mieux que le visualisateur en ligne, mais cela reste peu.
Aucune liste ne pourra donc à ce jour faire bien plus de 4Kio, et le volume total des données d'un script ne pourra excéder les 13Kio et quelques.
Notons qu'une image plein écran 16-bits
(320x240x2) nécessite 150Kio. Même si cela pourrait être stocké de façon compressée, il faudra bien décompresser en mémoire à un moment ou à un autre.
Aussi la capacité offerte à ce jour nous semble assez insuffisante pour permettre le développement de projets de jeux et/ou retouche d'images, conformément à ce que promeuvent les derniers programmes scolaires sortis.
Nous avons donc 17Kio au total dédiés au
Python, répartis en :
- 4Kio de mémoire de stockage des scripts
- 13Kio de mémoire de travail pour l'évaluation des scripts
C'est peu par rapport par exemple aux 28Kio de la
TI-82 sortie en 1993, même si ils étaient certes partagés entre stockage et évaluation à la différence.
Mais rappelons que la puce
STM32F412 de ta
NumWorks offre :
- 1 Mio de mémoire Flash
- 256 Kio de mémoire RAM
Espérons que dans une prochaine version du système
NumWorks le stockage des scripts
Python pourra passer en mémoire
Flash et donc survivre au reset ainsi qu'à l'activation puis désactivation du mode examen, et que l'espace de travail offert pour l'exécution des scripts pourra être augmenté en conséquence et de préférence encore davantage.
