Découverte capacité travail Python NumWorks : 13 kilooctets

[Admin]

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: Select all

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.

Lien : https://workshop.numworks.com/python/andreanx/mem

[jean-baptiste boric]

Nul besoin de tester expérimentalement quand on a la réponse dans le code : https://github.com/numworks/epsilon/blo ... ller.h#L84

Il y a 16 KiB de RAM disponible pour le tas de l'interpréteur MicroPython. En pratique, la pile d'appel Python, toutes les variables/fonctions/classes définies dans les scripts importés et à l'exécution ainsi que leurs overhead associés vont puiser dedans, d'où les ~13 KiB trouvés expérimentalement.

Pour l'outil de visualisation en ligne, ce sont les mêmes 16 KiB de RAM qui sont utilisés, une piste possible pour expliquer une mémoire de travail moins spacieuse serait l'usage d'entiers et de pointeurs 64 bits dans les programmes/OS modernes. Il faudrait tester avec un navigateur web 32 bits si on observe le même comportement que sur la calculette.

Le vrai problème n'est pas les 16 KiB, mais l'absence de gestion de mémoire intelligente dans le firmware de NumWorks. Il y a bien un mécanisme pour allouer dynamiquement de la mémoire, mais un malloc qui rate et c'est le RESET direct. Il n'est pas possible à l'heure actuelle de gérer précisément le stockage mémoire et les variables comme sur une TI ni de savoir où on en est. On peut supprimer des données par applications pour faire de la place, mais ça ne va pas aider pour le Python.

[parisse]

Ce n'est pas avec les 4K de stockage des scripts que ca va changer grand chose... Il faut changer la taille de la memoire flash et RAM, comme je le dis depuis le debut, j'espere que Numworks prevoit aussi ca dans son modele avec nouveau clavier pour la rentree!
Sur la Numworks actuelle avec une capacite memoire digne d'une calculatrice d'il y a plus de 20 ans, il ne vous reste plus qu'a stocker a la main les donnees temporaires plus grosses que 4K dans la memoire ecran

[jean-baptiste boric]

Ce n'est pas avec les 4K de stockage des scripts que ca va changer grand chose... Il faut changer la taille de la memoire flash et RAM, comme je le dis depuis le debut, j'espere que Numworks prevoit aussi ca dans son modele avec nouveau clavier pour la rentree!

Comme je l'ai noté, dans ce cas présent le problème n'est pas réellement un manque de RAM mais plutôt l'impossibilité de finement contrôler les données en RAM avec l'architecture logicielle actuelle du firmware qui pousse à des choix (très) conservateurs. Sur une TI, une erreur d'allocation mémoire pour une variable entraîne une erreur qui est remontée à l'utilisateur, qui peut agir en conséquence. Sur NumWorks, c'est le RESET pur et simple, donc ils sont assez frileux pour le moment.

Si NumWorks gérait la Flash comme mémoire d'archive y'en aurait pour 350 KiB et pourtant on est limité à 4 KiB en RAM pour les scripts. Au bout d'un moment faut reconnaître que y'a pas que des problèmes d'ordre matériel

Sur la Numworks actuelle avec une capacite memoire digne d'une calculatrice d'il y a plus de 20 ans, il ne vous reste plus qu'a stocker a la main les donnees temporaires plus grosses que 4K dans la memoire ecran

Pas possible, y'a pas de fonction pour lire un pixel à l'écran

[parisse]

Comme je l'ai noté, dans ce cas présent le problème n'est pas réellement un manque de RAM mais plutôt l'impossibilité de finement contrôler les données en RAM avec l'architecture logicielle actuelle du firmware qui pousse à des choix (très) conservateurs. Sur une TI, une erreur d'allocation mémoire pour une variable entraîne une erreur qui est remontée à l'utilisateur, qui peut agir en conséquence. Sur NumWorks, c'est le RESET pur et simple, donc ils sont assez frileux pour le moment.

Si NumWorks gérait la Flash comme mémoire d'archive y'en aurait pour 350 KiB et pourtant on est limité à 4 KiB en RAM pour les scripts. Au bout d'un moment faut reconnaître que y'a pas que des problèmes d'ordre matériel

Justement si, le probleme a la base de tout, c'est bien la memoire insuffisante. Ca leur coute certainement bien plus cher de passer des heures et des heures de developpement/bugfixes/choix conservateurs pour eviter le memory full/reset que d'avoir des le depart choisi des capacites de memoire plus conformes a notre epoque. En prime je pense que tous ces efforts n'auront pas servi a grand chose (si ce n'est enerver les early adopters), parce que je suis a peu pres persuade qu'ils finiront par faire une Numworks avec plus de memoire. En tout cas, c'est la lecon que j'ai retiree du developpement de la hp39gii.

Pas possible, y'a pas de fonction pour lire un pixel à l'écran

il me semblait pourtant que get_pixel sert a ca.

[critor]

Nul besoin de tester expérimentalement quand on a la réponse dans le code : https://github.com/numworks/epsilon/blo ... ller.h#L84

Certes mais l'autre but de ce script est de tourner aussi sur Graph 90+E, calculatrice pour laquelle nous n'aurons pas le code source.
A date, son exécution sur le logiciel de démo disponible qui a été analysé et n'est pas un émulateur mais un simulateur ne prouve rien. Mais au moins, je sais que ça marche.

Ce critère sera donc évaluable de façon aussi équitable que possible pour un des points du QCC 2018.

[critor]

Il y a 16 KiB de RAM disponible pour le tas de l'interpréteur MicroPython. En pratique, la pile d'appel Python, toutes les variables/fonctions/classes définies dans les scripts importés et à l'exécution ainsi que leurs overhead associés vont puiser dedans, d'où les ~13 KiB trouvés expérimentalement.

J'ai omis de le préciser, mais j'ai désactivé les importations automatiques de tous les scripts préchargés avant de tester.

[critor]

D'ailleurs en passant puisqu'il m'avait été demandé de donner des exemples, c'est justement un des nombreux scripts Python n'allant pas chercher de modules et qui pourtant ne passent pas sans artifice sur HP Prime.
La machine ne comprend pas True ni len().
Et même après remplacement, je pense que la machine ne comprend pas du tout ce que la ligne l = l + l[l[0]:] lui demande de faire.

[parisse]

Dans la configuration actuelle de la Prime, le parser CAS ne reconnait pas True, et les indices commencent a 1 (il faudrait que la configuration contienne une case Python a cocher pour faire demarrer les indices a 0). Mais meme si les modifs etaient apportees, je ne pense pas que ce script particulier marchera car il suppose qu'une exception soit levee par les routines d'acces a la memoire. Les capacites de travail de la HP sont limitees par la RAM, il y a donc 3 ordres de grandeur de plus que sur la Numworks et l'evaluateur passe en mode non recursif donc on n'est pas limite par la taille de la stack pour les programmes recursifs, par exemple

Code: Select all

#cas
def facto(n):
  if n<=1:
    return 1
  return n*facto(n-1)
#end


puis facto(100)
Au passage, si vous voulez tester ce que pourrait donner la compatibilite Python, essayez dans Xcas pour Firefox, pas sur la Prime qui a 6 mois de retard sur Xcas. Je continue a y travailler avec les scripts publics Numworks (non orientes objets) pour faire en sorte qu'on puisse les faire tourner avec tres peu de modifications, voire pas du tout, dans Xcas pour Firefox.

[isquelcrax]

c'est vieux comme le monde mais
+ de mémoire = bénéfice en moins