Forum TI-Planet.org

est-ce que l'on ne pourrait pas remplacer le 255*20*j+256 par 5100*j+256?
Pour la hp prime, le calcul de H-1 et N-1 est fait dans la boucle for à chaque fois alors qu'on pourrait le faire en amont dans le programme, avant les FOR. Le calcul n'est pas fait sur Numworks (ou alors dans l'instruction range(H).
peut-on gagner du temps en définissant z:=0.0 au lieu de z:=0 ce qui ne constitue pas le même type?
Ne peut-on pas également exprimer les nombres complexes pour la hp prime sous la forme c:=(w*x-2.1,-(h*y-.935)) ce qui éviterait de multiplier par i à chaque itération de la boucle.
après je ne sais pas si on pourrait gagner du temps avec z^2 au lieu de z*z car il faudrait savoir quelle est la plus rapide des deux instructions.

Merci pour tes remarques.

Je ne suis pas sûr que les H-1 et N-1 soient réévalués à chaque itération sur HP Prime.

Mais côté NumWorks il y a quand même évaluation similaire de range(H) et range(W), donc personne n'est avantagé à priori.

si parce que les boucles for sont imbriquées entre elles, donc à chaque itération de la première boucle for H-1 est calculé pour la deuxième boucle et N-1 est calculé à chaque itération de la deuxième boucle for pour la troisième boucle for

Et les range(W) et range(H) seront également évalués de façon similaire sur NumWorks, donc personne ne me semble avantagé là-dessus à priori.

Sans compter qu'il faut se méfier avec les langages interprétés, le rajout d'une ligne (ici pour affecter une variable avant la boucle afin de l'utiliser comme borne) pouvant coûter plus cher que l'optimisation que l'on pense coder.

N'importe quel interpréteur un poil intelligent (sans parler d'un JIT, tout de même) aura vu qu'il peut au moins précalculer ces constantes, de toute façon
Après si c'est idiot ou pas sur la Prime (pareil sur les autres calculatrices, d'ailleurs, faudrait vérifier pour ce genre d'optis), je ne sais pas...

Possible donc que le range(...) soit moins rapide purement à ce niveau là. Il faudrait pouvoir utiliser une boucle for numérique, mais je suppose que c'est suffisamment optimisé pour ces cas triviaux...

Mais bref, les vraies améliorations de vitesse, sur NumWorks, vont arriver en 1.2.1

La definition de n comme variable locale est aussi devenue inutile, je ne sais pas si ca a une influence, mais ce n'est pas impossible que ca joue a la marge car l'espace de recherche diminue lors de la resolution de noms.
Il me semble avoir vu sur github qu'avec l'activation du prefetch ils arrivent a descendre la Numworks juste en-dessous de la minute pour Mandelbrot, mais je ne sais pas quels sont les parametres.

Surtout que l'on n'utilise pas les mêmes paramètres que dans leur exemple built-in.

Je vais vérifier avec une build de leur dernière version publique du code, et si c'est vraiment significatif j'en reparlerai dans la semaine.

Effectivement, c'est extraordinaire.
55.61s, la NumWorks creuse l'écart.

Ce n’est pas si étonnant quand on compare leurs processeurs. Celui de la numworks, sans être de toute dernière génération est quand même beaucoup plus récent que celui de la prime. Il y a en l’occurrence deux générations d’ecarts et un jeu d’instruction plus propre (tout ce qui est legacy a été dégagé sur les cortex M, contrairement aux cortex-A)

En fait on a d’un côté un arm9 avec une fréquence monstrueuse (pour une calculatrice) mais un jeu d’instruction limité et de l’autre côté un m4 avec une fréquence plus faible, une meilleure efficacité (ce qui n’explique pas tout, le gain est de 15%) mais surtout un jeu d’instruction moderne et une fpu dont est visiblement dépourvu le processeur de la prime, et c’est là que doit se faire la différence.

Merci beaucoup pour les précisions sur les générations de processeurs.