Forum TI-Planet.org

Ca y est j'ai réparé le LLVM sur le PB

Tu peux retenter en faisant clean puis ceci (puis download, puis teste) :



En vrai je sais pas si ca va changer grand chose vu que le code est simple, mais sait-on jamais

Edit: mais en fait dans ton code, non, LLVM ne supporte pas quelque chose qui s'y passe (c'est un gros projet en WIP depuis plusieurs années, peu de temps y est passé dernièrement, un jour ca sera amélioré/fini )
Edit2: en enlevant le floor(), ça passe.
Edit3: ouai avec LLVM c'est instantané... il y a de l'optimisation dans l'air.

tu es sûr qui a pas un bug dans le compilateur LLVM?
Ca me fait 10 millions d'itérations en 0 secondes alors qu'en passant par le ZDS ça prend 25 secondes, ce qui est plus plausible...
à moins que tu aies trouvé un moyen de faire des calculs en supraconductivité sur Ti83 par voie logicielle ...

Probablement parce que LLVM détecte que la boucle est inutile pour le reste du programme, donc il optimise ca en l'enlevant, tout simplement. On peut le forcer à ne pas optimiser ce bout la si on veut vraiment.

ZDS n'est pas très doué pour les optimisations, malheureusement, mais est plus "fini" en terme de support.

Le fork de LLVM en question : https://github.com/jacobly0/llvm-z80

... et il pousse même le luxe à incrémeter le compteur d'un coup!: ce qui expliquerait que quand je fais afficher le nombre de tours à la fin il m'indique bien 10 millions d'itérations en zéro secondes ! (c'est un ptit tricheur celui-là ! )
En revanche quand c'est optimisé avec LZD il m'indique un nombre farfelu (3 millions .. etc.) un problème d'adressage mémoire? bref peu importe

"On peut le forcer à ne pas optimiser ce bout la si on veut vraiment."

La doc indique plein de transformations possibles :http://llvm.org/docs/Passes.html
La mienne devrait être celle-là :
-loop-deletion: Delete dead loops
This file implements the Dead Loop Deletion Pass. This pass is responsible for eliminating loops with non-infinite computable trip counts that have no side effects or volatile instructions, and do not contribute to the computation of the function’s return value.

Sais-tu comment peut-on personnaliser la commande avec PB ?

Oui et non, pas directement. Mais bon, on peut jouer avec l'attribut "volatile" sur l'index de la boucle, par exemple.

je ne suis pas assez expert pour gérer ce qu'est cet attribut "volatile" .
J'ai recommencé en "remplissant la boucle" en affichant le compteur et j'ai mis 2 boucles imbriquées de 100 tours (donc 10000 tours).
Cette fois ça fonctionne, LLVM ne saccage plus mes boucles! et c'est plus près d'une "expérience utilisateur" normale.
https://tiplanet.org/pb/?id=229901_1567 ... 86bf32715a
LZD me donne 43 secondes et une taille de 476 o. et IDEM pour LLVM 43 secondes aussi... mais le prog est (un peu) plus grand avec 505 o.
Donc apparemment LLVM n'est pas si miraculeux que ça dans le cas de petits programmes simples....
Je vais refaire mon test sur TiBasic et Python avec ce protocole et je vais essayer de m'y coller en assembleur ça me fera un bon exercice de départ pour apprendre.
Allez je vous laisse tranquille, ça commence à faire troll

ZDS (et non pas LZD) tu veux dire ?

Oui, pour des trucs triviaux, a partir d'un moment ca va être difficile de mesurer des différences.
Tu peux voir toi même la comparaison de l'assembleur généré (avec le choix du bouton "Diff ASM..."

Par contre dans les options du projet, tu peux choisir d'optimiser pour la taille, ou pour la performance. Et pareil pour LLVM mais ca se fait à la main dans le champ des options (-O0, -O3, -Os, -Oz... cf. la doc).
En tentant d'optimiser pour la taille, j'ai moins de 30 octets de différences entre les 2 compilateurs. (Mais sur des plus gros programmes, la différrence est nette, et qand on reste dans les limites de ce que LLVM est pour le moment capable de gérer, il est infiniment mieux).
En optimisant pour privilégier la vitesse, LLVM inline (il en est capable, en tout cas, et le fait des que c'est mieux) beaucoup de choses, c'est à dire que certains contenus de fonctions peuvent se retrouvés directement à l'intérieur d'autres bouts de code, quand la performance en sera affectée positivement pour une raison ou pour une autre, meme si c'est plus gros.

Toujours est-il que ZDS est limité à du C ANSI (C89) et produit de temps en temps du code invalide et crashe aussi parfois. LLVM, parmi le subset supporté (oui, c'est contraignant aussi, ce n'est pas un projet terminé....), produit du code largement mieux.
Et puis tu peux faire du C99, C11, C++17 meme si tu veux Exemple ici avec une classe C++ de Point 2D et dans le main je vais un calcul simple avec 2 instances : https://tiplanet.org/pb/?id=1381_149565 ... =Point.cpp

Par "volatile" sinon, c'était juste une question de mettre "volatile int toto = 1;" au lieu de "int toto = 1;".

Je dois avoir des programmes du type fractales etc où l'on voit mieux la différence de performance entre le code généré par LLVM et celui de ZDS...

grosged wrote:Salut,
Je viens d'acheter une TI-83 Premium CE EDITION PYTHON, apparemment en version 5.3.6 (car le BOOT Code est en version 5.3.6.0017 , et le BASE Code en 5.3.6.0018)

Et quand j'essaye de passer en mode python...

j'ai ceci...
L'application Python App v5.3.6 n'a pas l'air encore disponible, on dirait ..?
Il ne me reste plus qu'à attendre que celle-ci soit disponible , ou y aurait-il un autre moyen ?

Bonjour tout le monde, mais dites-donc ! Ce modèle m’intéresse beaucoup, je voudrai en savoir plus s’il vous plaît, est-ce possible ? Merci de votre retour  Cependant j’ai une petite question à vous confier si c’est possible. Amicalement

Bonsoir.

Quelle est la question ?