(pseudo) Speed Test - Page 1

Je viens de faire quelque test vitesses entre une nSpire (non cas) une TI-89 et un TI-83 (et l'émulation 84+ de la nSpire)

et devinez qui est gagnant ? ^^

La nSpire


Dans l'ordre j'ai:

- nSpire
- nSpire 84+
- TI-89
- TI-83

Pas tres étonant en fait non ?

Le protocol de test est le programme suivant :

(en version 89, mais ile st 99% identique chez les autres, surtout sur nSpire, ou a pars des fonctions manquantes, le langage est identiques a ceux des 68k)

speed(a)
Prgm
©Le 0. sert a forcer la 89 a afficher en approx
0.->c
For b,1,a
c+sin(cos(a))->c
EndFor
Disp C
EnfPrgm

Tout con, mais avec a = 200 il faut bien 18 secondes a la TI-89 pour afficher le "93.6285" qui est le resultat de l'opération

la nSpire a un affichage quasi instantané (1 a 2s), la 83 dépasse les 30s et la nSpire 84+ dans les max 10s

Godzil (./1) :
Pas tres étonant en fait non ?

Ouais, ils ont déjà foiré pas mal de choses avec la nSpire, si en plus elle était pas plus rapide que la génération précédente, il lui resterait rien

Ça serait intéressant de normaliser ça par rapport au nombre de MIPS du processeur utilisé, histoire de voir grossièrement s'ils ont optimisé le code ou pas ^^

quelqu'un connait le rapport MIPS/MHz de l'ARM926 ? ^^

(il tourne à 90 MHz le cpu de la nspire)

~1.1 MIPS/MHz d'après Wikipédia.

Zerosquare (./2) :
Ça serait intéressant de normaliser ça par rapport au nombre de MIPS du processeur utilisé, histoire de voir grossièrement s'ils ont optimisé le code ou pas ^^

nSpire: 2s * 90 Mhz * 1.1 MIPS/MHz = 198 MIP (entre 99 et 198 compte tenu de la précision).
TI-89: 18s * 12Mhz * 0.25 MIPS/MHZ = 54 MIP

Ca à pas l'air optimisé du tout. Voire franchement plus mauvais.

Faudrais faire des tests plus long et faire plusieurs mesure pour que ça puisse avoir un sens

ué 2 secondes c'est light.

PpHd (./5) :
Ca à pas l'air optimisé du tout. Voire franchement plus mauvais.

C'est même encore plus drôle si on considère la TI-83 :
6 MHz (à moins que Godzil ait utilisé une 83SE ?) * 0.25 (d'après cette page c'est le max, ça peut descendre jusque 0.04 !) * 30 = 45 MI

Et encore, ça ne tient pas compte que le Z80 n'est qu'un 8/16 bits, comparé au 16/32 bits de la 89 ^^

(finalement, c'est bien vrai : TI fait du code de plus en plus mauvais )

Le programme de Godzil prend 12,5 secondes pour finir le calcul sur ma TI 89 Titanium. Elle est sensée être plus rapide que la TI 89 simple ?

J'ai une 89HW1 donc a ~10Mhz, les autres (HW2 & Sup sont a ~12Mhz) mais fondamentalement ça ne change pas gd chose. et pour faire un test valide, il faudrait mettre A bcp plus grand et le code dépend de la facon dont fonctionnet cos & sin (qui sont heureusement réputé pour être lent car non basé sur une table de valeur)

Zerosquare (./8) :
(finalement, c'est bien vrai : TI fait du code de plus en plus mauvais )

Ils sont dans la norme. C'est pareil partout. On code en se prenant de moins en moins la tête sur l'optimisation. Heureusement, la fréquence des processeurs compense. Je pense que ça diminue les coûts de développement.

désolé de te choquer en te contredisant mais *heureusement* que ce que tu dis n'est pas vrai...

Je dirais plutôt que c'est pas vrai partout... C'est pas trop vrai dans l'embarqué (quoique...), enfin dans les boîtes qui en font sérieusement (c'est à dire celles qui ne mettent pas un PC avec XP pro dans une boîte et qui collent un autocollant "embarqué" dessus)

Mais pour ce qui est de l'info "généraliste", je suis assez d'accord avec Thibaut.

Mais il y a bien d'autres problématiques que les perfs (qualité, maintenabilité, modularité, sécurité, intéroperabilité...)

#squalyl#

non #squalyl# c'est uniquement pour les news postées en doubeul

Faudrait l'appeler #slashdot#.

PpHd (./5) :

Zerosquare (./2) :
Ça serait intéressant de normaliser ça par rapport au nombre de MIPS du processeur utilisé, histoire de voir grossièrement s'ils ont optimisé le code ou pas ^^

nSpire: 2s * 90 Mhz * 1.1 MIPS/MHz = 198 MIP (entre 99 et 198 compte tenu de la précision).
TI-89: 18s * 12Mhz * 0.25 MIPS/MHZ = 54 MIP

Ca à pas l'air optimisé du tout. Voire franchement plus mauvais.

Attention quand même, l'ARM9 est vraiment plus performant, mais il faut compter aussi les pbs de cache qui font que le rapport de performance n'est pas forcément exactement 1.1
Cela dit bcp d'opérations qui prennent facilement entre 10 et 20 cycles sur 68k sont faits en un seul sur ARM donc le rapport reste énorme.

Godzil (./10) :
J'ai une 89HW1 donc a ~10Mhz, les autres (HW2 & Sup sont a ~12Mhz) mais fondamentalement ça ne change pas gd chose. et pour faire un test valide, il faudrait mettre A bcp plus grand et le code dépend de la facon dont fonctionnet cos & sin (qui sont heureusement réputé pour être lent car non basé sur une table de valeur)

Peut être que faire un test avec juste des opérations (pas de ROM_CALLs super lents) ça pourrait être pas mal aussi histoire de voir à peu près combien on peut atteindre pour un jeu (en effet, on ne fera pas de calcul de sin/cos dans un jeu mais on utilisera plutôt une table)
Et puis je sais pas pour la nspire, mais certains proços de cette classe sont équipés d'une (v)fpu il me semble, et ça accélère peut être pas mal le calcul de du sinus

Thibaut (./11) :

Zerosquare (./8) :
(finalement, c'est bien vrai : TI fait du code de plus en plus mauvais )

Ils sont dans la norme. C'est pareil partout. On code en se prenant de moins en moins la tête sur l'optimisation. Heureusement, la fréquence des processeurs compense. Je pense que ça diminue les coûts de développement.

C'est l'impression qu'on a en tant que geek, mais ça dépend du domaine. Au boulot par exemple je code sur un proço 8 bits, et l'optimisation est vraiment de mise. C'est important aussi pour la consommation électrique, et un gros CPU genre ARM n'arrivera jamais au niveau des petits microcontrolleurs.

Brunni (./18) :
Peut être que faire un test avec juste des opérations (pas de ROM_CALLs super lents) ça pourrait être pas mal aussi histoire de voir à peu près combien on peut atteindre pour un jeu   (en effet, on ne fera pas de calcul de sin/cos dans un jeu mais on utilisera plutôt une table)
Et puis je sais pas pour la nspire, mais certains proços de cette classe sont équipés d'une (v)fpu il me semble, et ça accélère peut être pas mal le calcul de du sinus   

Vu les limitations du basic des nSpires, et pour le faire avec les operation simples il faudrait a mon avis bcp trop de boucle pour que ça puisse etre realiste...

Et je doute que la nSpire integre un FPU...