char, short ou int ? - Page 1

Pour faire des calculs, qu'est ce qui est le plus rapide ?
Utiliser des chars, des short ou des long ?

surement les short, mais tt depend de la taille de ta valeur

OK.
disons, des valeurs toujours inférieures à 64000 (enfin, le max d'un unsigned short)
Et, dans certains cas, des valeurs inférieures à 256 (=> là, je pourrai utiliser des char)

c pas pareil short ou int sous tigcc ?

Tout depend de ce que tu veux calculer : grand nombre, flottant, ....
A priori tu veux travailler sur des entiers donc le + petit type sera le + rapide je pense
donc : char => 1octet => 255 max mais rapide
short => 2 octets => 65535 max
long => 4octets => 2^32 -1 max
voila !

petite precision : les nombres max obtenu sont pour des unsigned
neurone => sur la plupart des compilateur les int sont equivalent a des long
mais pour eviter tou pb utilise des short int ou des long int

sur les compilateurs destinés à des processeurs 32 bits, les int son codés sur 4 octets, comme des longs (c'est le cas de MSVisualC++6.0)
sous TIGCC, vu que c _une machine 16 bits (en externe je crois), les ints équivalent à des shorts, codés sur 2 octets. (sauf si on utilise l'option -mlong, je crois)

En fait, la seule chose fixée par la norme, c'est :
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)
(enfin, il me semble que c ce que dit l'ANSI-C)

sinon, je me posait la question parce que les chars correspondent pas à la machine 16bits...
mais les shorts correspondent po aux registres 32 bits
=> c tordu

squale92 : sorry javais oublie que le Motorola 68k etai un proc 16bits
Le compilateur GCC etai pour petite machine?
dans ce cas les int sont des short
squale92 : ce ke tu di a propos de la norme des tailles, c bien ce ke dit la norme ANSI-C
la tzaille du int est defini par le compilateur 16 ou 32 comme la pluparrt des compilateur
MSVC++, CVI, borland C++ 5.,...
donc c pour ca kil faut eviter dutiliser des int mai uniquement des short ou des long
pour etre sur

char est le plus rapide sur 68k, mais en général, char et short tournent à la même vitesse. Mais il y a des instructions comme s?? ou btst qui ne tournent qu'avec des octets (btst tourne aussi avec des longs, mais pas avec des shorts). En revanche, il y en a d'autres comme dbra qui veulent des shorts.
[edit]Edité par Kevin Kofler le 16-12-2001 à 20:43:22[/edit]

merci Kevin.

>Kevin : comment un char pourrait etre plus rapide qu'un short ?

parce que c'est comme ça

En général non, puisque le bus est fixe à 16 bits et que les instructions permettent octet et mot.

Bon, alors, le plus rapide, c'est quoi ?

moi je dis les short ou les bermudas a la limite

lol

Généralement les unsigned short (et unsigned int) sont plus rapides que les long et char :

* Presque toutes les instructions arithmétiques sont plus rapides sur les short ou les char que sur les long => au revoir les longs
* Certaines instructions arithmétiques ne peuvent traiter que des short (mulu / muls mais aussi divu / divs en opérande source) => au revoir les char qui demandent une extension avant l'appel de ces instructions
* mulu et divu sont plus rapides que muls et divs => au revoir les non-unsigned

Les gagnants sont les unsigned short, dans tous les cas (sauf en opérande source de la division où ils nécessitent une extension)

C'est vrai que je n'avais pas pensé aux multiplications et aux divisions.

oué, les longs je me doutais que ct plus long (moins rapide)
Donc, je v pouvoir modifier quelques trucs de plus dans Krypton : supprimer quelques chars pour passer à des shots... voire même des unsigned short qd je peux...

sinon, pr les calculs les shorts sont plus rapide, OK, mais pour les comparaisons ?
(est-ce que les comparaisons demandent aussi une extension de char vers short ?)

La difference entre un char et un short est vraiment minime.
Voire negligeable. Dans les profondeurs de l'optimisation.

oué, je m'en doute... mais ça peut avoir une influence sur mes formats de niveau aussi...
parce que, pr le moment, mes niveaux sont codés sur des chars....
mais ces chars me permettront bientôt plus de stocker assez d'information
=> j'hésite entre mettre 2 chars, ou 1 short à la place de chaque char...
Dans les deux cas, ça me fait la même occupation mémoire.... (les shorts me permpettent de coder plus de données)...
Les shorts demanderont plus de calcul de ma part (pas du programme : c tt des trucs précalculé, pr les formats de niveaux), mais si c un peu plus rapide, c po génant.

sinon, sachant que je dois utiliser des cast pour passer de char à short dans mes calculs, parfois, qu'est-ce qui vaut mieux ?
=> j'utilises PARFOIS quelque chose du style : (short)mon_char
(ou qqc comme ça)

>oué, je m'en doute... mais ça peut avoir une influence sur mes formats de niveau aussi...
>parce que, pr le moment, mes niveaux sont codés sur des chars....
>mais ces chars me permettront bientôt plus de stocker assez d'information
>=> j'hésite entre mettre 2 chars, ou 1 short à la place de chaque char...
ca depend ce que tu veux faire ensuite.

>Les shorts demanderont plus de calcul de ma part (pas du programme : c tt des trucs précalculé, pr les formats de niveaux), mais si c un peu plus rapide,
Pkoi ?

>sinon, sachant que je dois utiliser des cast pour passer de char à short dans mes calculs, parfois, qu'est-ce qui vaut mieux ?
>=> j'utilises PARFOIS quelque chose du style : (short)mon_char
bah ce cast ne bouffe pas vraiment de ressources.
Tu n'en as pas assez dit pour que je te conseilles.

les short demanderont plus de calculs de ma part :
si j'utilises deux chars, j'aurai un tableau de chars pr ce que j'ai en ce moment, et un autre pr l'arrière plan.
si j'utilises un short, j'aurai tt dans le même => plus chiant pr savoir comment gérer ça (fodra que je réfléchisse un peu )

heu... Je ne suis pas devin. Ca sert a quoi deja ton truc.

c'est mon niveau.
Pour lke moment, j'utilises un tableau de chars, qui contient les arrivées d'ennemis, les entrées dans le magasin (plus quelques autres trucs)
Mais si je met un arrière plan avec des murs, mes char ne suffiront plus pour tout coder : j'aurai plus de 256 éléments possibles
=> soit je prend un deuxième tableau de chars, qui ne code que pour les murs...
et je lis els deux en même temps...

=> soit je supprime le premier tableau de chars, et j'utilises un seul et unique tableau de short qui gére tout : à la fois les murs et les ennemis...

Essayes les 2 tableaux separes. Mais je sais pas si c'est vraiment ce qu'il faudrait.

oué...
en fait, je sais po trop non plus...
Utiliser des shorts me permettrait de gérer plus d'ennemis...
ça ne ferait pas faire de calculs supplémentaires au prog...
fo que je voie, aussi au niveau des avantages et inconvénients de gestion...

Pour les transtypages (casts): si tu transtypes un type en un plus petit (par exemple: (char)monshort), ça ne fait rien du tout. Mais si tu transtypes un type en un plus grand (par exemple (short)monchar), il y a du code supplémentaire généré. Pour les nombres signés, ça sera des ext, pour les non signés, ça sera en général du style clr.w %dn;move.b truc,%dn.

A moins d'utiliser un max de transtypage, ca reste anecdotique.

je dois en utiliser dans les 6, 8 ou 10 par cycle du programme...
et c'est de char vers short.