Forum TI-Planet.org

Adriweb a écrit:Oui, comme on a aussi pu le voir sur des programmes en assembleur.
Ce n'était pas vraiment un troll quand on disait que la flash était plus rapide que la Ram désormais

La Flash externe est plus rapide que la RAM interne à l'ASIC, un comble !

Adriweb a écrit:mr womp womp signale que la TI-84 Plus CE aussi a eu un refresh de packaging (et en bonus, la nouvelle couleur, Teal) de la même manière que la TI-83 Premium CE Edition Python :

mr womp womp continue ses explorations et a trouvé les packaging 2019 des autres modèles



(même source sur son topic cemetech)

Ben il faudrait acheter une 84+CE sous ce packaging, pour voir si elle bénéficie des mêmes améliorations matérielles (hors puce Atmel possiblement manquante).

Adriweb a écrit:Oui, comme on a aussi pu le voir sur des programmes en assembleur.
Ce n'était pas vraiment un troll quand on disait que la flash était plus rapide que la Ram désormais

petit déterrage pour vous partager mon expérience avec la Ti83 Premium CE-Python Edition :
- Boucle 100 000 itérations avec incrément d'une variable

Code: Tout sélectionner

:actMintr->T
:For(X,1,100000
:X+1->X
:End
:affMintr(T)->X
: Disp X

122 secondes... okiiii...

- idem en Python

Code: Tout sélectionner

from time import *
t=monotonic()
for i in range(1,100000):
__i=i+1
t=monotonic()-t
print(t)

11,43 secondes!

C'est la puce Python qui est vraiment plus rapide que cet eZ80 ou le langage TiBAsic qui est vraiment lent?

Quelqu'un peut faire un test en assembleur? (je serai d'ailleurs curieux de voir comment on fait car je débute)

La rançon est peut-être la taille du fichier en mémoire:
Le programme TiBasic fait 52 octets, je ne sais pas combien fait le programme en Python car le fichier n'apparait pas dans le menu mém...

emilechombier a écrit:C'est la puce Python qui est vraiment plus rapide que cet eZ80 ou le langage TiBAsic qui est vraiment lent?

Les deux, meme si en theorie la frequence du CPU est la meme pour les deux (mais pour le chip Python, c'est un ARM relativement moderne, par rapport a l'eZ80...).
Mais bon, sur une TI-83 Premium CE (non Python) ou autre, ca serait environ 2 à 3 fois plus lent en TI-Basic, a cause du materiel encore plus lent avant l'edition python

emilechombier a écrit:Quelqu'un peut faire un test en assembleur? (je serai d'ailleurs curieux de voir comment on fait car je débute)

On peut faire le test en C ou en Assembleur, mais ca sera encore plus rapide

emilechombier a écrit:e ne sais pas combien fait le programme en Python car le fichier n'apparait pas dans le menu mém...

Les codes python sont stockés sous forme de variable d'application (appvar), et sont présents dans cette catégorie dans le menu mémoire.

Adriweb a écrit:Mais bon, sur une TI-83 Premium CE (non Python) ou autre, ca serait environ 2 à 3 fois plus lent en TI-Basic, a cause du materiel encore plus lent avant l'edition python

Oui je viens d'essayer sous CEmu : 241 secondes (émulation TI-83 Premium CE (non Python)) soit presqu'exactement le double !

Adriweb a écrit:On peut faire le test en C ou en Assembleur, mais ca sera encore plus rapide

Je viens d'essayer aussi en C avec ton (incroyable!) PB en ligne... moins de 1 seconde !
... mais presque 600 octets en mémoire (j'ai peut-être inclu trop de librairies inutiles...)

Adriweb a écrit:Les codes python sont stockés sous forme de variable d'application (appvar), et sont présents dans cette catégorie dans le menu mémoire.

Merci de l'info... j'aurais du m'en douter...
Il fait donc 110 octets au lieu de 52 en Basic.
RECTIFICATIF : ce n'est pas 11 secondes pour 100 000 itérations mais 1,13 secondes !!!

Conclusion : Python est un très bon compromis taille/vitesse/facilité. Ce programme est 2x plus gros qu'un TiBasic mais 10 fois plus rapide.
Le programme en C est 5 fois plus gros que Python et pas beaucoup plus rapide que Python sur ce petit test (mais avec des possibilités infiniment plus grandes d'après ce que j'ai pu voir). Bref pour des algorithmes de maths, Python me semble finalement pas mal du tout, surtout qu'il est impossible de compiler un programme en C en classe avec la calculette!!

EDIT: je complète ce résultat après avoir fait un test sur 1 000 000 d'itérations : moins de 3 secondes en C contre 113 secondes en Python... et 1496 soit 25 minutes en TiBasic . A bon entendeur...

A mon avis, le code en C peut etre a la fois plus petit et beaucoup plus rapide, ça dépend comment il est écrit
Si tu peux me partager ton lien du projet PB, je peux jeter un coup d'oeil
Ne pas oublier que pour exécuter de l'ASM issuu de C compilé, il ne faut généralement rien d'autre que l'OS de la machine (voire juste le CPU....). Sauf évidemment si on utilise des libs, auquel cas on peut rajouter le poids de la lib en question. Mais pour le Python... il faut rajouter CircuitPython, aller hop, ca fait x dizaines/centaines de KB Bien sur, quand c'est déjà intégré, "on s'en fout", car c'est transparent pour l'utilisateur. Mais en absolu..

A vrai dire, c'est souvent les optimisations faites par le compilateur (pour les langages compilés), qui comptent. Pour une simple boucle qui ne fait rien, le compilateur peut tres bien voir qu'elle est inutile, et donc la supprimer... comme ça aucun temps n'est perdu à "calculer" dans le vide Ou bien pour des calculs avec des valeurs connues, ca sera précalculé, et donc instantané lors de l'exécution...
Et puis sinon, quand on se met à écrire de l'assembleur à la main (pour des bonnes raisons, mais ça devient rare), généralement c'est imbattable.

oui c'est là: https://tiplanet.org/pb/?id=229901_1567 ... 86bf32715a
La gestion du timer est bizarre. Il n'y a pas de librairie "timer" comme sur PC.
(mon premier programme en C pour la Ti!)

C'est pas mal du tout je trouve
Si ça n'utilise pas de type de données > 24 bits, la compilation avec LLVM, au lieu de ZDS, génèrera un ASM bien meilleur

Par contre, je viens de voir que quelque chose semble cassé au niveau de la génération du programme sur LLVM quand j'ai fait la migration sur le nouveau serveur.... Il va falloir que j'investigue
L'asm généré est bon, par contre c'est la suite qui semble cassé.

Adriweb a écrit:C'est pas mal du tout je trouve

merci! tu parles de la qualité de mon code (c'est pas le programme le plus compliqué du siècle), de la taille du programme? ou de la performance de la calculette? (c'est pas la vitesse d'un 9900K) ou de la performance de ton compilateur?

Adriweb a écrit:Si ça n'utilise pas de type de données > 24 bits, la compilation avec LLVM, au lieu de ZDS, génèrera un ASM bien meilleur
Par contre, je viens de voir que quelque chose semble cassé au niveau de la génération du programme sur LLVM quand j'ai fait la migration sur le nouveau serveur.... Il va falloir que j'investigue
L'asm généré est bon, par contre c'est la suite qui semble cassé.

Je n'ai rien compris mais si tu le dis

L'inconvénient est que je maitrise pas tout ce qu'il y a dans les includes: il y en a qui sont peut-être inutiles. On ne peut pas importer juste les fonctions qu'on utilise, séparément, comme en python? Par exemple j'importe toute la librairie "math" juste pour la fonction "floor" c'est un peu bête...