Performances, la NumWorks détrône la HP Prime ! :o

[Arka_Voltchek]

D’ailleurs il serait intéressant de tenter un test n’en faisant appel qu’à des entiers, là, la prime devrait être moins désavantagée

[Lionel Debroux]

La FPU du Cortex-M4 gère seulement les flottants simple précision, et ne propose qu'un nombre réduit d'instructions FPU comme CPU. C'est un des prix à payer pour un processeur qui consomme moins qu'un Cortex-A5, par exemple.

[Arka_Voltchek]

Le M4 avec l’integralité de tumb1 et 2 et sa FPU gère déjà plus de chose que ARMv5 de la prime

[zardam]

Pour la Numworks, il y a certainement encore un peu de marge de manœuvre pour les performances. J'ai fait un test rapide avec une pyboard (la plateforme "native" de micropython). Le CPU est assez comparable il me semble (un STM32F405), sauf qu'il est cadencé à 168 MHz.

En partant du script mandelbrot livré avec le firmware 1.2 (avec prefetch et caches activés), mais avec les deux dernière lignes commentées (calcul de la couleur et affichage), je suis à 47 secondes sur la Numworks et 15 secondes sur la pyboard ! Si on ramène à fréquence égale, cela ferait tout de même 25,2 secondes.

Numworks n'a pas activé la compilation "native" sur la calculatrice. Je ne sais pas si cela change grand chose car il me semble qu'il faut le préciser explicitement d'après ce paragraphe de la doc de micropython, mais je ne connais pas assez micropython pour être certain.

[darthvader]

tout les stm32f4xx peuvent tourner a 168mhz , s'il est moin rapide dans la numworks c'est certainement pour economiser la batterie.

[zardam]

tout les stm32f4xx peuvent tourner a 168mhz , s'il est moin rapide dans la numworks c'est certainement pour economiser la batterie.

Pas celui de la Numworks d'après la datasheet : "frequency up to 100 MHz"

[Adriweb]

Numworks n'a pas activé la compilation "native" sur la calculatrice. Je ne sais pas si cela change grand chose car il me semble qu'il faut le préciser explicitement d'après ce paragraphe de la doc de micropython, mais je ne connais pas assez micropython pour être certain.

Je viens de me builder une version avec le support de native (et viper), mais manifestement je n'ai pas du tout faire correctement, le .native crashe, et le .viper me sort une erreur (sûrement normal, il est plus restrictif) ^^

(Note: il faudrait peut-être activer l'emitter Thumb, là j'ai juste fait N_ARM de base)

[Arka_Voltchek]

Effectivement car seules les instructions thumb 1 & 2 sont gérées par le M4 (comme je l’ai écrit plus haut). Les instructions arm classiques ne le sont pas.

https://developer.arm.com/products/proc ... /cortex-m4

[zardam]

Je viens de compiler epsilon avec newlib à la place de la liba de numworks. Bilan :

• Le firmware est plus gros d'environ 100 ko
• Le test que j'ai fait hier (commenter les deux dernières lignes du mandelbrot "standard" 1.2) passe de 47 secondes à 38 secondes
• La version optimisée (récupére sur la page 3 du thread) passe de 56 secondes à 43 secondes

Donc, clairement, il y a des choses optimisables dans la liba, mais cela n'explique toujours pas toute la différence avec la pyboard.

J'ai aussi remarqué que le code qui gère l'interruption du script pénalise aussi un peu les perfs. En le désactivant on gagne encore 3-4 secondes. Le scan des touches est assez gourmand (pas mal de "sleep").

[Adriweb]

Je rappelle aussi que le firmware est compilé en -Os pour gagner un peu de place, et non pas -O2 par exemple. Utiliser -O2 fait accélérer les choses un peu aussi.

Je vais tenter le @micropython.native ave le thumb, pour voir...