Comme rappelé récemment dans l'épisode 19 de notre classement QCC de rentrée 2017, la HP Prime était depuis la rentrée 2013 la calculatrice graphique la plus rapide. Mais lors de la mise à jour de cet épisode suite à la sortie de la calculatrice NumWorks, nous remarquions que la NumWorks semblait la dépasser en performances (testées sur l'évaluation de programmes de calcul numérique).
Avec un processeur cadencé quatre fois moins vite, ARM Cortex-M4 à 100MHz pour la NumWorks contre ARM9 (ARMv5) à 400MHz pour la HP Prime (à moins que cette dernière information répandue sur Internet ne soit que la fréquence nominale et non la fréquence réelle ?) c'était assez surprenant. Nous ne pouvions exclure une erreur de mesure, les écarts ne faisant que quelques centièmes de seconde. En effet notre protocole de test utilisait le même programme pour tous les modèles, programme que l'on ne pouvait pas corser davantage à cause de limitations sur les modèles les plus faibles, et qui donc sur les meilleurs modèles terminait en moins d'une seconde, faisant ainsi perdre aux mesures en précision.
Aujourd'hui que le langage de programmation Python de la NumWorks n'est plus en version beta, et que la HP Prime gère aussi une forme de Python, tentons d'éclaircir un petit peu le mystère entourant les différences de performances entre ces deux modèles, et de les départager équitablement.
Nous allons cette fois-ci tester les performances avec un programme graphique. Reprenons le programme Mandelbrot inclus en exemple sur la NumWorks, et adaptons-le à l'identique pour la HP Prime. Nous ne dessinerons donc dans les deux cas que 320x222 pixels au lieu 320x240, puisque les écritures sur la barre de titre sont bloquées sur la NumWorks ce qui pourrait fausser la comparaison.
programme NumWorks en Python (versions 1.2.0+) | programme HP Prime en simili-Python (versions 12951+) |
|
|
La NumWorks met seulement 1min26s à effectuer le tracer pendant que la HP Prime se traîne péniblement pendant 4min22s. On confirme donc, hélas, des performances très décevantes pour la HP Prime, le même programme mettant 3 fois plus de temps à allumer le même nombre de pixels.
Notons que dans les deux cas, on peut voir à l’œil nu les pixels s'allumer progressivement de haut en bas sur chaque colonne, ce qui suggère bien un fonctionnement similaire des instructions graphiques, légitimant ainsi la comparaison.
Bien que les TI-Nspire disposent d'un Python non officiel, nous ne pouvons y exécuter exactement le même programme et c'est pour cela qu'elles sont absentes de ce test. En effet, les fonctions graphiques de l'évaluateur Python en question fonctionnent différemment et ne permettent pas d'écrire directement sur l'écran, obligeant à définir et écrire des zones hors écran (offscreen) qui seront remplies puis affichées d'un seul coup. Un très mauvais choix d'ailleurs dans le contexte scolaire de lycéens débutants d'imposer ce fonctionnement, alors qu'au contraire il faudrait leur laisser expérimenter l'écriture directe et en saisir les limites pour qu'il puissent alors comprendre l'intérêt de passer par une zone 'offscreen'. Pas possible non plus de choisir un autre langage interprété comme le TI-Basic, puisqu'il ne dispose pas de fonctions de sorties graphiques sur ces modèles. Le Lua n'est pas non plus une solution puisqu'il ne gère pas les nombres complexes d'une part, obligeant donc à passer par divers astuces risquant de fausser la comparaison, et d'autre part 'bufferise' les sorties écran, les temporisant donc pour les rendre effectives de façon groupée en fin d'exécution de la fonction de rafraîchissement on.paint(gc).
Pourquoi la HP Prime est-elle si lente ? Deux hypothèses :
- soit on incrimine le CAS, le langage simili-Python de la HP Prime n'étant disponible que dans le contexte CAS, et nous avions vu dans l'épisode en question que les calculs étaient nettement plus lents dans ce cadre
- soit on incrimine son évaluateur/traducteur Python
Pour valider ou infirmer cette dernière hypothèse, traduisons le même programme dans le langage interprété HPPPL CAS originel de la HP Prime :
- Code: Select all
#cas
fractal_cas(w,h,n)
BEGIN
local x,y,z,c,j,t,col
FOR x FROM 0 TO w-1 DO
FOR y FROM 0 TO h-1 DO
z:=0
c:=2.7*x/(w-1)-2.1-i*(1.87*y/(h-1)-.935)
j:=0
WHILE j<N AND abs(z)<2 DO
j:=j+1
z:=z*z+c
END;
t:=255*j/N
col=RGB(IP(t),IP(.75*t),IP(.25*t))
PIXON_P(x,y,col)
END;
END;
FREEZE
WAIT(0)
#end
[
Et bien c'est pire, la HP Prime passant de 4min22s à 4mins35s. Ce qui implique que l'écriture à la Python ne complexifie pas la chose, et le temps additionnel étant probablement dû à l'évaluation des lignes supplémentaires de fin de bloc qui sont omises en Python.
Ce serait donc la faute du CAS ? Voyons si nous pouvons valider cette hypothèse en réécrivant le même programme en langage interprété HPPPL non-CAS :
- Code: Select all
EXPORT fractal(w,h,n)
BEGIN
local x,y,z,c,j,t,col
FOR x FROM 0 TO w-1 DO
FOR y FROM 0 TO h-1 DO
z:=0
c:=2.7*x/(w-1)-2.1-i*(1.87*y/(h-1)-.935)
j:=0
WHILE j<N AND abs(z)<2 DO
j:=j+1
z:=z*z+c
END;
t:=255*j/N
col=RGB(IP(t),IP(.75*t),IP(.25*t))
PIXON_P(x,y,col)
END;
END;
FREEZE
WAIT(0)
#end
Bien, la HP Prime tombe cette fois-ci à seulement 2min24s, doublant presque ses performances. Le contexte CAS limite bien les performances même quand on ne fait pas appel à ses spécificités, et il est ainsi dommage que le langage simili-Python ne soit donc disponible que dans ce cadre, surtout quand il n'y a aucune intention de faire du calcul exact ou littéral.
Toutefois, 2min24s c'est quand même nettement plus lent que les 1min26s de la NumWorks. D'autres facteurs interviennent donc visiblement, et l'on peut valider la constatation de l'épisode 19.
Cela ne veut pas forcément dire que son processeur est plus puissant, mais en tous cas en terme de performances effectives et ce depuis la rentrée 2017, la meilleure calculatrice graphique est donc la NumWorks. 
