Casio a sorti la semaine dernière des mises à jour 3.30 et 3.40 pour ses Graph 35+E II et Graph 90+E, avec un nouveau module Python casioplot te permettant de contrôler les pixels de l'écran. Pour te donner une référence, c'est donc l'équivalent du module kandinsky chez NumWorks.
Des possibilités déjà fort bien exploitées sur Graph 90+E par LightMare avec un script Python de rendu 3D en raytracing !
Des possibilités déjà fort bien exploitées sur Graph 90+E par LightMare avec un script Python de rendu 3D en raytracing !
Malheureusement, une fois les appels graphiques corrigés ce même script ne marchait pas sur la NumWorks, déclenchant une erreur de mémoire.
Pourquoi ?
Pourquoi ?
Il faut savoir que dans le cadre du MicroPython ou similaire des calculatrices il y a 3 types de mémoire avec les rôles suivants :
En gros le stack / pile limite donc le nombre d'objets différents pouvant exister simultanément en mémoire, alors que le heap / tas limite la taille globale occupée par ces objets.
L'appel
La différence devrait te sauter aux yeux, la Graph 90+E a plus de 1 Mo de heap / tas et la NumWorks autour de 32 Ko.
- la mémoire de stockage qui accueille et conserve tes scripts Python
- le stack (pile) qui, à l'exécution, accueille les références vers les objets Python créés
- le heap (tas) qui, à l'exécution, accueille les valeurs de ces objets Python
En gros le stack / pile limite donc le nombre d'objets différents pouvant exister simultanément en mémoire, alors que le heap / tas limite la taille globale occupée par ces objets.
L'appel
mem()
avec le script mem.py suivant permet justement d'estimer la capacité du heap / tas :- Code: Select all
def sizeenv():
s=0
import __main__
for o in dir(__main__):
try:s+=size(eval(o))
except:pass
return s
def size(o):
s,t=0,type(o)
if t==str:s=49+len(o)
if str(t)=="<class 'function'>":s=136
if t==int:
s=24
while o:
s+=4
o>>=30
if t==list:
s+=64
for so in o:s+=8+size(so)
return s
def mem(v=1,r=1):
try:
l=[]
try:
l+=[r and 793+sizeenv()]
if v*r:print(" ",l[0])
l+=[0]
l+=[""]
l[2]+="x"
while 1:
try:l[2]+=l[2][l[1]:]
except:
if l[1]<len(l[2])-1:l[1]=len(l[2])-1
else:raise(Exception)
except:
if v:print("+",size(l))
try:l[0]+=size(l)
except:pass
try:l[0]+=mem(v,0)
except:pass
return l[0]
except:return 0
Aux examens français :
En classe :
- 2,049276 Mo :
TI-Nspire (appli MicroPython) - 1,032942 Mo :
Casio Graph 90+E
Casio fx-CG50 - 1,022145 Mo :
HP Prime (version alpha) - 257,636 Ko :
Casio Graph 35/75+E
Casio Graph 35+USB SH4
Casio Graph 75/95 SH4
Casio fx-9750/9860GII SH4
(appli CasioPython) - 100,560 Ko :
Casio Graph 35+E II
Casio fx-9750/9860GIII - 31,899 Ko :
Casio Graph 35+E II
Casio Graph 35+USB SH3
Casio Graph 75/95 SH3
Casio fx-9750/9860GIII
Casio fx-9750/9860GII SH3
Casio fx-9860G
(appli CasioPython) - 32,339 Ko
NumWorks (firmware Omega) - 31,624 Ko
NumWorks - 22,605 Ko
TI-83 Premium CE + TI-Python (firmware tiers) - 20,200 Ko
TI-83 Premium CE Edition Python (version 5.4) - 19,924 Ko
TI-83 Premium CE + TI-Python - 17,954 Ko
TI-83 Premium CE Edition Python (version 5.5)
La différence devrait te sauter aux yeux, la Graph 90+E a plus de 1 Mo de heap / tas et la NumWorks autour de 32 Ko.
Ce n'est pas la taille du script qui compte, mais elle donne un point de repère. Le script de raytracing original faisait 14 Ko.
Nous avons optimisé l'écriture de ce script et réussi à en réduire la taille à seulement 4,5 Ko soit à peine le tiers de la taille initale, et maintenant ça passe parfaitement sur NumWorks !
Nous avons de plus commencé à développer et rajouté une classe de compatibilité graphique polyscr qui permet au même script Python de contrôler les pixels de l'écran aussi bien sur Casio Graph 90/35+E II que NumWorks ou TI-Nspire CX Ndless !
Pas besoin de réécriture, la classe intercepte et traite les appels graphiques prévus respectivement pour casioplot, kandinsky et nsp, et ça marche !
Cela devrait permettre à chacun de pouvoir développer des scripts Python graphiques compatibles avec l'ensemble des modèles, à commencer par nous pour un éventuel concours de rentrée 2020.
Le script aura juste à tenir compte quelque part du nombre de pixels de l'écran, information que la classe permet justement de récupérer.
Nous avons optimisé l'écriture de ce script et réussi à en réduire la taille à seulement 4,5 Ko soit à peine le tiers de la taille initale, et maintenant ça passe parfaitement sur NumWorks !
Nous avons de plus commencé à développer et rajouté une classe de compatibilité graphique polyscr qui permet au même script Python de contrôler les pixels de l'écran aussi bien sur Casio Graph 90/35+E II que NumWorks ou TI-Nspire CX Ndless !
Pas besoin de réécriture, la classe intercepte et traite les appels graphiques prévus respectivement pour casioplot, kandinsky et nsp, et ça marche !
Cela devrait permettre à chacun de pouvoir développer des scripts Python graphiques compatibles avec l'ensemble des modèles, à commencer par nous pour un éventuel concours de rentrée 2020.
Le script aura juste à tenir compte quelque part du nombre de pixels de l'écran, information que la classe permet justement de récupérer.
Le script tourne sur Graph 35+E II, mais son écran ne gère pas les niveaux de gris. Chaque pixel donne donc du noir ou du blanc selon la couleur qui est jugée être la plus proche, et malheureusement c'est apparemment ici toujours le noir qui l'emporte.
Ce qui est par contre extrêmement surprenant, c'est que nous n'obtenons pas mieux sur TI-Nspire. Pourtant ici il s'agit bien d'un écran en niveaux de gris 4-bits (24=16 niveaux de gris différents), et jusqu'à présent les programmes Ndless prévus pour les TI-Nspire CX couleur n'avaient aucun problème à afficher en niveaux de gris lorsque lancés sur TI-Nspire monochrome...
Hélas, nous n'avons rien pu faire pour la TI-83 Premium CE Edition Python.
Son heap / tas dans sa version actuelle ne fait que 20 Ko, et il devient difficilement envisageable de réduire encore de moitié la consommation du script.
Et ce n'est hélas pas près de s'arranger, dans la prochaine version 5.5 le heap / tas tombe pour le moment à moins de 18 Ko, sans doute une conséquence involontaire de toutes les superbes nouveautés Python dont nous avons commencé à te parler et allons bien évidemment continuer.
C'est certes génial d'avoir toutes ces nouveautés Python, mais avec moins de 18 Ko de heap / tas désormais, nous craignons a priori d'être fortement limités dans la possibilité de les exploiter, avec des scripts plutôt académiques de quelques lignes au lieu de choses sortant des sentiers battus.
Ce qui est par contre extrêmement surprenant, c'est que nous n'obtenons pas mieux sur TI-Nspire. Pourtant ici il s'agit bien d'un écran en niveaux de gris 4-bits (24=16 niveaux de gris différents), et jusqu'à présent les programmes Ndless prévus pour les TI-Nspire CX couleur n'avaient aucun problème à afficher en niveaux de gris lorsque lancés sur TI-Nspire monochrome...
Hélas, nous n'avons rien pu faire pour la TI-83 Premium CE Edition Python.
Son heap / tas dans sa version actuelle ne fait que 20 Ko, et il devient difficilement envisageable de réduire encore de moitié la consommation du script.
Et ce n'est hélas pas près de s'arranger, dans la prochaine version 5.5 le heap / tas tombe pour le moment à moins de 18 Ko, sans doute une conséquence involontaire de toutes les superbes nouveautés Python dont nous avons commencé à te parler et allons bien évidemment continuer.
C'est certes génial d'avoir toutes ces nouveautés Python, mais avec moins de 18 Ko de heap / tas désormais, nous craignons a priori d'être fortement limités dans la possibilité de les exploiter, avec des scripts plutôt académiques de quelques lignes au lieu de choses sortant des sentiers battus.
Bon ben puisqu'il n'est plus envisageable de compresser le script davantage, étoffons-le un petit peu. Avec une interface bilingue français-anglais permettant de choisir :
Terminons enfin avec les performances, vu que vous avez été nombreux à nous les demander.
Nous ferons des rendus plein écran avec la bille transparente (ce qui génère un peu plus de calculs puisque déviant les rayons lancés plutôt que de les stopper).
Par équité la rafraîchissement sera effectué à chaque pixel, vu que la NumWorks ne supporte pas cette optimisation.
Aucun overclocking, ce sont donc les performances d'usines atteignables par n'imorte quel utilisateur.
Précisions bien qu'il ne s'agit pas ici d'une mesure de la puissance de calcul, mais des performances dans le cas bien particulier de ce script, avec donc mélange de calculs et de sorties sur écran.
Avec le script d'aujourd'hui qui est, rappelons-le, optimisé pour le tas / heap et la compatibilité mais absolument pas pour les performances, nous avons :
Mais ces écrans ont des définitions différentes, et nécessitent donc plus ou moins de calculs. Ramenons tout ceci par proportionnalité à ce que donnerait un rendu 128×64 pixels équivalent au plus petit écran, celui de la Graph 35+E II :
Quelques surprises pas toujours agréables.
- la langue
- les dimensions du rendu en pixels avec même l'indication des bornes
- le type de la sphère, bille opaque bleue ou transparente
- et même, lorsque supporté par la machine, la possibilité d'accélérer un petit peu le rendu en ne rafraichissant l'affichage qu'une fois par ligne ou encore à la fin plutôt qu'à chaque nouveau pixel calculé
Terminons enfin avec les performances, vu que vous avez été nombreux à nous les demander.
Nous ferons des rendus plein écran avec la bille transparente (ce qui génère un peu plus de calculs puisque déviant les rayons lancés plutôt que de les stopper).
Par équité la rafraîchissement sera effectué à chaque pixel, vu que la NumWorks ne supporte pas cette optimisation.
Aucun overclocking, ce sont donc les performances d'usines atteignables par n'imorte quel utilisateur.
Précisions bien qu'il ne s'agit pas ici d'une mesure de la puissance de calcul, mais des performances dans le cas bien particulier de ce script, avec donc mélange de calculs et de sorties sur écran.
Avec le script d'aujourd'hui qui est, rappelons-le, optimisé pour le tas / heap et la compatibilité mais absolument pas pour les performances, nous avons :
- NumWorks N0110 : 2min35
- NumWorks N0100 : 2min36
- NumWorks N0100 : 2min43 (firmware Omega)
- NumWorks N0110 : 3min22 (firmware Omega)
- Casio Graph 35+E II : 2min40
- Casio Graph 90+E : 10min28
- TI-Nspire CX CR4+ : 14min48
- TI-Nspire CX CR3- : 24min
- TI-Nspire : 7min09
Mais ces écrans ont des définitions différentes, et nécessitent donc plus ou moins de calculs. Ramenons tout ceci par proportionnalité à ce que donnerait un rendu 128×64 pixels équivalent au plus petit écran, celui de la Graph 35+E II :
- 17,9s : NumWorks N0110 (32 bits : Cortex-M7/ARMv7 @216MHz)
- 18,0s : NumWorks N0100 (32 bits : Cortex-M4/ARMv7 @100MHz)
- 18,8s : NumWorks N0100 + firmware Omega (32 bits : Cortex-M4/ARMv7 @100MHz)
- 23,3s : NumWorks N0110 + firmware Omega (32 bits : Cortex-M7/ARMv7 @216MHz)
- 45,8s : TI-Nspire (32 bits : ARM9/ARMv5 @120MHz)
- 1min09,8s : Casio Graph 90+E (32 bits : SH4 @117,96MHz)
- 1min34,7s : TI-Nspire CX CR4+ (révisions W+) (32 bits : ARM9/ARMv5 @156MHz)
- 2min33,5s : TI-Nspire CX CR3- (32 bits : ARM9/ARMv5 @132MHz)
- 2min40,0s : Casio Graph 35+E II (32 bits : SH4 @58,98MHz)
Quelques surprises pas toujours agréables.
Pour une raison que nous ignorons l'installation du firmware tiers Omega diminue apparemment les performances de ta NumWorks. C'est particulièrement marqué pour la NumWorks N0110 qui avec une perte d'environ 25% devient alors même moins performante que l'ancien modèle NumWorks N0100 pourtant moins puissant. Mais que se passe-t-il ?...
Téléchargement : démo raytracing + classe de compatibilité graphique polyscr (pour NumWorks, Casio Graph 90/35+E II et TI-Nspire Ndless)