Discussion :

[Kaluza]

Salut !

Imaginons que je veuille travailler sur de très petits nombres entiers compris entre 0 et 255. Quel type de données utiliser pour mes variables pour garantir le truc le plus optimal ?

Des unsigned char, des unsigned short int, des int ou des unsigned int ?
Je pourrais très bien travailler avec des char, mais est-ce qu'il y aura un gain sur les calculs ? De plus je ne sais pas trop si les compilos pourront optimiser des calculs sur des char puisque en principe ce n'est pas fait pour ça...

Bref, selon vous quel est le mieux ?

Merci

[Flob90]

Si gain il y a c'est grace à la réduction de données utilisé : plus rapide d'additionner 8 bits que 16, de là à savoir si c'est significatif dans ton programme c'est à tester.

Personnelement je prendrais un uint_least8_t (dans le header cstdint), ca me garantie un entier non signé codé sur au moins 8 bits (ce qui fait bien de 0 à 255).

[3DArchi]

Salut,

Quel type de données utiliser pour mes variables pour garantir le truc le plus optimal ?

Ca dépend de ta cible et de son jeu d'instruction.
Il n'y a donc pas de réponse absolue
....
Une première approche est d'utiliser <cstdint> si tu as un compilateur C++0x ou C++ avec TR1 :

Personnelement je prendrais un uint_least8_t (dans le header cstdint), ca me garantie un entier non signé codé sur au moins 8 bits (ce qui fait bien de 0 à 255).

std::uint_fast8_t plutôt non ?
En gardant à l'esprit que fast ne veut pas dire que le compilateur aura raison dans tout les cas.

[screetch]

en règle générale je dirais utilise ce dont tu as besoin, le compilateur fera sans doute le reste...

[Flob90]

Ha oui fast, je l'avait oublié lui ...

[Joel F]

je me pose toujours la question du gain attendu a utilise de "petit entier" ( a part l'evident gain en memoire) . Les registres font 32 bits; le bus aussi, etc ... et add, idiv etc prennent le meme chemin de donnée si je ne m'abuse ?

Ne s'agit il de premqture optimisation ?

[guillaume07]

je me pose toujours la question du gain attendu a utilise de "petit entier" ( a part l'evident gain en memoire) . Les registres font 32 bits; le bus aussi, etc ... et add, idiv etc prennent le meme chemin de donnée si je ne m'abuse ?

Ne s'agit il de premqture optimisation ?

+1

[screetch]

d'ailleurs si je ne m'abuse, additioner deux "short" retourne un "int" non?

[Goten]

Ouaip :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
int main(int argc, const char *argv[])
{
    short a, b;
 
    std::cout << typeid(decltype(a + b)).name() << std::endl;
    return 0;
}

$ ./a.out
i

[screetch]

merci pour la confirmation
donc en fait ca ne rentre en compte que pour le stockage, pour le calcul le compilateur fera mieux de toutes facons.

[Kaluza]

Merci pour vos réponses j'y vois déjà un peu plus clair. Suite à la remarque de Joel F, je me demandais si cela changeais quelque chose au niveau du temps de calcul de travailler sur des int32 ou des int64 sur un processeur 64-bits ?

[Blustuff]

et add, idiv etc prennent le meme chemin de donnée si je ne m'abuse ?

Le nombre de cycles dépend de l'instruction. Pendant longtemps, le nombre de cycles d'une division sur x86 a été variable, et ainsi, une division sur des petites données était plus efficace. Je ne sais pas si encore le cas aujourd'hui.

Les optimisations liée à la taille de l'opérande étant de toute façon très dépendante de l'architecture cible il faut vraiment que ça vaille le coup de les tenter. A ma connaissance les compilateurs courants ne savent pas déterminer précisément le nombre de bits utiles dans une variable pour être capable d'optimiser les calculs en fonction de cette information.