Comparaison - Page 3

Ca signifie que le code ne faisait rien à l'origine. Dis-nous quelle est la proportion de programmes qui comportent des boucles inutiles ? 1% ? Dans ce cas ce n'est pas une optimisation très importante.
On est en droit d'attendre ce genre d'optimisations "mineures" (dans le sens où elles sont rarement utiles) de la part d'un gros compilateur comme GCC, développé depuis des années par des dizaines de personnes et tournant sur des système rapides et comportant beaucoup de RAM. Je suis d'accord avec toi.

Mais GTC est développé courageusement par une seule personne depuis 6 ans et tourne sur un système limité. Il atteint pourtant un niveau de performances remarquable. Quand accepteras-tu de relativiser les choses ?

Sincèrement, j'ai envie de dire "vos gueules", à l'un comme à l'autre...
Donnez-vous rendez-vous dans le topic qui va bien, mais ne polluez pas TOUS les topics, s'il vous plait ...

Bref, tama : Pour ta comparaison, il vaudrait mieux que tu évites d'utiliser des tests de touche. Il vaut mieux que tu fasses une boucle qui se répète it fois, it étant fixé à l'avance.
Il ne te reste plus qu'à chronométrer le temps que met le programme à s'arrêter. Plus besoin d'un handler et de kbhit

tama, tu peux aussi adapter le code que je t'ai donné pour que le programme fasse une opération en boucle pendant un certain temps et qu'il s'arrête tout seul sans qu'on ait besoin d'appuyer sur une touche

Kevin Kofler (./56) :
Il est horrible, ce code:
1. utilisation de kbhit() et ngetchx() dans un gestionnaire d'interruption,
2. utilisation de exit() dans un gestionnaire d'interruption!!! Normalement, ça devrait planter la calculatrice...

De plus, ta boucle vide est normalement complètement supprimée par GCC, et une grande partie de ton temps est passée dans kbhit(), qui implique pas mal de matériel autre que le CPU (silent link en particulier).

j'avais prévenu
ceci dit, je suis preneur de tout code propre

EDIT : lu la suite des messages, j'avais senti le troll arriver
Thibaut>ok je vais plutôt faire comme ça, c'est vrai que ça sera plus simple
Thepro>oép vais voir ça

Pour 50000 fois une boucle vide de 1000 itérations, }=> #include <tigcclib.h> void _main() {    unsigned long it;    short i;        for(it=1;it<=50000;it++)     for(i=1;i<=1000;i++)      continue;    printf("Ok"); //lorsque je vois le message, j'arrête le chrono    ngetchx();

j'ai chronométré à la main, donc y a une légère marge d'erreur (temps de réaction...)
ça donne :
-HW3 => 2'43"40 (163.40 secondes => 3.268 ms pour 1 boucle vide de 1000 itérations)
-HW4 => 2'43"82 (163.82 secondes => 3.276 ms pour 1 boucle vide de 1000 itérations)

Toujours pas assez significatif... =/

Thibaut (./61) :
Ca signifie que le code ne faisait rien à l'origine.

Ou que tout le code a pu être sorti de la boucle.

Dis-nous quelle est la proportion de programmes qui comportent des boucles inutiles ?

L'inlining, tu connais?

static inline void increment(int *foo)
{
  (*foo)++;
}

void _main(void)
{
  int i, j=0;
  for (i=0; i<100; i++) increment(&j);
  printf("%d",j);
}

Ce code est optimisé par GCC en:

__main:
	move.w #100,-(%sp)
	pea .LC0
	jbsr printf
	addq.l #6,%sp
	rts

Rappelle-nous quand GTC sait faire ça.

L'idée est que l'utilisateur de la fonction increment n'a pas à savoir ce qu'elle fait exactement, imagine que ça s'appelle compte_machinchose, qu'il suffit d'incrémenter j actuellement, mais que tu veux garder la possibilité de logguer ce que tu comptes dans une base de données un jour. En attendant, tu ne veux pas que ton programme fasse tourner des boucles pour rien.

Mais GTC est développé courageusement par une seule personne

GTC est également basé sur un compilateur existant, c'est juste que ce compilateur est loin de la qualité de GCC.

Ben voyons. Non seulement tu sais pas te taire quand les modos le demandent, mais en plus tu t'enfonces.


tama : Il y a un truc bizarre.

Les dernières Titanium tournent à la même fréquence que les premières versions si on regarde les tests en ASM. Si on teste le Basic, il y a un écart de vitesse inexpliqué.

En tout cas, les Nspire sont clairement plus rapides, ce qui est une bonne chose

Thibaut (./68) :
tama : Il y a un truc bizarre.

Les dernières Titanium tournent à la même fréquence que les premières versions si on regarde les tests en ASM. Si on teste le Basic, il y a un écart de vitesse inexpliqué.

ptet que comme l'a dit je sais plus trop qui (squalyl ?), l'interpréteur basic a été réecrit, ce qui expliquerait cette différence ?
Sinon c'est ptet l'état des piles...

tama (./69) :
ptet que comme l'a dit je sais plus trop qui (squalyl ?), l'interpréteur basic a été réecrit, ce qui expliquerait cette différence ?

J'ai émis cette hypothèse aussi et quelqu'un a répondu que c'est pas ça la clé du mystère, puisque c'est la même version de l'OS qui fait tourner les deux modèles

tama (./69) :
Sinon c'est ptet l'état des piles...

Dans ce cas, le programme ASM serait également affecté.

Je pense a un truc :
Pour la difference sur le Basic entre HW3 & HW4, il faudrait indiquer sur quelles versions de AMS ont été faits les tests.
Car si dans les 2 cas c'est AMS 3.10, il est impossible que l'interpreteur Basic ai pu changer, j'me trompe ?

Edit > Cross qui confirme mon msg

Dude>3.10 pour les deux.

A mon avis c'est juste l'interpréteur qui est différent... qui a dit qu'il était pareil?
Sinon, vous avez fais des tests avec beaucoup de lecture/écriture?

Ben... il est forcément pareil puisque c'est la même version d'AMS

il a envoyé la même ROM sur les 2 calculettes?

cf ./71 et ./72

./76 & ./77 > Ya peut-etre une explication :
Si l'interpreteur se base sur une INT peut-etre que la frequence de cette INT est differente ?

On sais jamais avec TI

D'après le programme de Thepro, l'AI1 tourne à 256 MHz sur les 2. Donc ce n'est pas celui là qui changerait

256 MHZ? Whoaa!!
Je vois pas trop l'utilité d'une interruption qui peut se déclencher plus vite que le processeur ^^

raaah zut
256 Hz