[Bases]Manipulation d'int et d'unsigned int

Bonjour

Je voudrais vous soumettre une question vis a vis de la différence entre la manipulation d'int et d'unsigned int: En effet, on trouve de la documentation à profusion dur le net mais justement un peu trop: certains affirment, que la manipulation d'un int est toujours la plus rapide, d'autre qu'elle est équivalente à celle d'un unsigned int ...

Aussi, indépendamment de considérations utilitaires (je ne manipule pas de nombre pouvant dépasser 2 147 483 647), la manipulation d'un de ces types est elle équivalente à l'autre ?

accessoirement, est-ce que manipuler des nombres plus petit (short par exemple) peut être plus rapide ?


Bref, beaucoup de philosophie en perspective. :aie:

Cordialement

Ca dépend je pense du compilateur, du processeur et de la taille d'un mot de celui-ci. Par exemple, avec un processeur 32 bits les types sur 32 bits seront plus rapides que ceux sur 16 ou 64. Il ne faut pas oublier que la taille des variables n'est pas définie en C++ et varie d'un compilateur à un autre, il y a juste une relation du genre bool <= char <= short <= int <= long (on pourrait donc avoir un long de la même taille qu'un short).

Concernant le int contre le unsigned int, j'imagine qu'il n'y a pas de différence à ce niveau, quel que soit le compilateur (ils seront tous les deux en 32 bits par exemple). Donc la même taille en mémoire, et sûrement des performances équivalentes.

Le short s'utilise très peu, justement peut-être parce que souvent il est codé sur la moitié d'un mot (16 bits sur sur processeur 32 bits, 32 bits sur processeur 64 bits), et le gain possible en mémoire ne vaut pas la perte en performances.

Si tu dois manipuler de très grands nombres entiers, il peut être préférable d'utiliser une bibliothèque adaptée (il y a quelque chose dans boost je crois), plutôt que des long (qui, suivant le compilateur, ne seront pas forcément plus long qu'un int).

En fait il y a plus souvent le débat float contre double, où en plus des considérations de taille et de performances il y a celles liées à la précisions des nombres.

Je donne des pistes sans vraiment répondre, les membres plus pointus du forum C++ pourront t'en dire plus ;)

Bonjour,

Je pense qu'il faudrai utilisé un unsigned int, dès que tu sais que ton nombre ne descendra jamais en dessous de zero... ( Comme ça, au moins si quelqu'un te relis, il saura que ton nombre jamais < 0 ).
Cela permet aussi d'éviter les test if ( < 0 ) .
Par contre il se peut que tu es un bug en faisant une mauvaise utilisation du unsigned int ( genre valeur qui devient très grande car tu as fait 0 - 1 ... )

J'ai tendance à préférer les signés en règle générale (les calculs sont plus simple, et on a moins de chances de se trouver dans les cas limites, à savoir 0 pour un unsigned).

Par contre, il est un cas où j'utilise systématiquement des unsigned, c'est quand il s'agit de manipuler les bits d'un nombre individuellement. Là, on a bien moins de surprise avec les unsigned.

Citation:

---

Envoyé par Cheps

Ca dépend je pense du compilateur, du processeur et de la taille d'un mot de celui-ci. Par exemple, avec un processeur 32 bits les types sur 32 bits seront plus rapides que ceux sur 16 ou 64. Il ne faut pas oublier que la taille des variables n'est pas définie en C++ et varie d'un compilateur à un autre, il y a juste une relation du genre bool <= char <= short <= int <= long (on pourrait donc avoir un long de la même taille qu'un short).

---

Certes, mais sur un même système et un même compilateur, un int et un unsigned int auront la même taille mémoire et leur manipulation sera "optimale" (encore qu'il parais que sur les 64 bits, le int resterait en 32 bits... mais bon, je code pour du 32 bits). La question ne porte pas sur l'espace occupé en mémoire mais sur la vitesse de manipulation: un int est-il plus rapide à manipuler qu'un unsigned int ?

Citation:

---

Envoyé par LittleWhite

Bonjour,

Je pense qu'il faudrai utilisé un unsigned int, dès que tu sais que ton nombre ne descendra jamais en dessous de zero... ( Comme ça, au moins si quelqu'un te relis, il saura que ton nombre jamais < 0 ).
Cela permet aussi d'éviter les test if ( < 0 ) .
Par contre il se peut que tu es un bug en faisant une mauvaise utilisation du unsigned int ( genre valeur qui devient très grande car tu as fait 0 - 1 ...

---

Citation:

---

J'ai tendance à préférer les signés en règle générale (les calculs sont plus simple, et on a moins de chances de se trouver dans les cas limites, à savoir 0 pour un unsigned).

Par contre, il est un cas où j'utilise systématiquement des unsigned, c'est quand il s'agit de manipuler les bits d'un nombre individuellement. Là, on a bien moins de surprise avec les unsigned.

---

A vrai dire, si je met des unsigned int, ce serait plutôt pour m'assurer que ma valeur ne descend jamais en dessous de 0 pour qu'une exception soit remontée dans ce cas. c'est l'erreur qui m'interesse dans le unsigned int. Par contre, ayant besoin d'optimiser les performance, je serait heureux de savoir quelle méthode est la plus rapide.

Il n'y a en général pas de différence de performance entre signed et unsigned, à nombre de bit égal, même sur des dispositifs embarqués à quelques fractions d'euros (donc encore moins sur des µp puissants).

Je vous suggère d'utiliser systématiquement des unsigned, car il est rare de vouloir faire véritablement de l'arithmétique signée. Si c'est le cas, les compilateurs détectent toute combinaison inattendue entre signed et unsigned, ce qui permet de confiner les vraies manipulations arithmétiques signées et de les isoler des comptages et autres manipulations directes de bits.

Edit: je viens de lire votre message. attention, il n'y a pas d'exception déclenchée normalement en cas d'overflow ou underflow (sauf sur certains matériels embarqués), donc ne comptez pas sur l'utilisation des unsigned pour ceci.

en fait, je parlais de warning ou d'erreurs à la compilation si l'utilisateur essayait d'envoyer un int ou un négatif.

après une petite étude, j'ai calculé que ce serait plus rapide pour mes opération de corriger un résultat négatif que de prédire le résultat et de corriger l'opération, donc je vais manipuler des int mais prendre des unsigned en paramètre.


Merci à tous pour vos contributions. ;)

Citation:

---

Envoyé par méphistopheles

A vrai dire, si je met des unsigned int, ce serait plutôt pour m'assurer que ma valeur ne descend jamais en dessous de 0 pour qu'une exception soit remontée dans ce cas.

---

Sauf que rien n'est remonté dans ce genre de cas... L'exemple typique est la boucle :

Code:

---

for (unsigned int i = 0 ; i<10 ; ++i)

---

Que l'on transforme pour aller dans l'autre sens en :

Code:

---

for (unsigned int i=9 ; i>0 ; --i)

---

Et qui se transforme en boucle infinie....

On a le même genre de problème avec les signed int quand on approche de la valeur numeric_limits<int>::max(), mais c'est moins courant que d'être proche de 0.

Citation:

---

Envoyé par JolyLoic

Code:

---

for (unsigned int i=9 ; i>0 ; --i)

---

Et qui se transforme en boucle infinie....

---

Avec i>= 0 comme condition.

Salut,
un peu HS

Citation:

---

Envoyé par Cheps

<snip>
bool <= char <= short <= int <= long (on pourrait donc avoir un long de la même taille qu'un short).

---

A vrai dire, le type bool n'a pas de taille particulière et n'intervient pas dans la relation :P

En effet:

1. char est l'unité (sizeof(char) = 1 )
2. false représente une valeur nulle
3. true représente n'importe quelle valeur non nulle
4. N'importe quel type capable de représenter une valeur nulle et une (n'importe quel nombre de) valeur(s) non nulle peut être considéré comme un booléen, ce qui place au moins tous les types primitifs ainsi que les pointeurs dans le cas.

Pour le reste méphistopheles, je crois que tu cherche un problème là où il n'y en a pas à vouloir effectuer une optimisation basée sur la différence (unsigned) int...

En effet, si la version signée et la version non signée des types primitifs pour lesquelles les deux existent sont considérées comme des types différents, c'est parce qu'il y a chaque fois un certain nombre de valeurs pour lesquelles on observe une incompatibilité de conversion.

Cette plage d'incompatibilités prend toute sa raison d'être, entre autre, lorsqu'il s'agit de provoquer l'affichage d'un type primitif ou lorsqu'il s'agit, effectivement, de considérer la valeur qu'il représente.

Cependant, le fait est que le nombre de bits utilisé pour représenter chaque type primitif est chaque fois égal que nous envisagions la version signée ou la version non signée...

Le résultat est que, si tu regarde du point de vue du nombre de périodes processeurs le temps à effectuer une opération identique sur un type primitif utilisant un nombre de bits identiques (par exemple une simple incrémentation, sur un type (unsigned) int), le temps de traitement sera parfaitement identique et dépendra... de l'opération elle-même...

Si tu éprouves des problèmes de performances, la première chose que tu devrait vérifier, ce sont tes algorithmes, jusqu'à avoir la certitude que l'algorithme utilisé sera le meilleur que tu sois en mesure de fournir.

Cela implique, entre autres, d'éviter d'effectuer un traitement chaque fois que tu peux, surtout si le dit traitement est gourmand en temps d'exécution.

L'utilisation intelligente d'un "buffer" gardant le résultat en mémoire est une des solutions qui te permettent d'éviter quelques traitement inutiles ;)

Dans l'ordre des traitements inutiles, nous trouvons également les copies et les conversions, qu'il faut éviter au maximum et, surtout, sur les structures qui sont gourmandes en mémoires et ou en temps en temps d'exécution.

Enfin, le fait d'effectuer un simple test peut, si la valeur testée peut etre obtenue en temps constant, faire gagner énormément de temps à l'exécution d'une partie importante par le simple fait... de mettre en évidence que le traitement n'est pas nécessaire ;)

Une fois que tu as l'assurance d'utiliser les meilleures structures avec les meilleurs algorithme, l'utilisation de "sucres syntaxiques" en vue de gain de performances doit être parcimonieuse et justifiée au minimum par une différence claire mise en évidence par un profiling correct

N'oublie en effet pas qu'un programme passe en moyenne 80 de son temps d'exécution dans 20% du code et qu'il n'y a qu'un intérêt très limité à accélérer le code d'une fonction qui ne serait appelée qu'une fois au début (ou à la fin) de l'application ou qu'une fois "toutes les dix lunes"...

Citation:

---

Envoyé par koala01

Dans l'ordre des traitements inutiles, nous trouvons également les copies et les conversions, qu'il faut éviter au maximum et, surtout, sur les structures qui sont gourmandes en mémoires et ou en temps en temps d'exécution.

---

A ce sujet là, d'ailleurs, il me semble que le fait d'utiliser des opérateurs de type +-*/ est sous performant par rapport à des += -= *= /= puisque ceux-cis créent de nouveaux objet provisoire à chaque appel (puisque si je ne me trompe pas, leur déclaration est:

Code:

---

1 2 3 4 5

Classe & Classe::operator+(const Classe & ) { ... return Classe(...);//crée un nouveau classe provisoire }

---

) enfin, à moins que l'inlining évite celà...

En effet.
Le mieux est de faire les deux: Un opérateur += dans la classe, et un opérateur + libre.

Ensuite, ça dépend des cas:

• Parfois, le mieux est copie plus opérateur +=
• Parfois, une construction personnalisée du nouvel objet (définir l'opérateur en friend peut être nécessaire)
• Parfois, un peu des deux.

A vrai dire, tout part de la problématique de savoir si la copie et / ou le swap peuvent se faire en temps constant ou non...

Typiquement, si tu peux limiter la copie à un algorithme de complexité en O(1) (temps constant) sous une forme proche de

Code:

---

1 2 3 4

MaClass::MaClass(MaClass const& rhs):nbElem(rhs.nbElem),ptr(new Type[nmElem]) { memcpy(ptr,rhs->ptr, nmElem*sizeof(Type)); }

---

et que tu n'a qu'un nombre "suffisamment peut important" de membre à swaper, un idiome copy and swap peut devenir relativement rapide, et, par conséquent, les opérateurs "mathématiques" utilisant la copie et / ou le swap etre relativement efficaces...

Par contre, si tu dois en arriver à une copie qui s'effectuerait plutôt selon une complexité en O(n) sous une forme proche de

Code:

---

1 2 3 4 5 6 7 8 9 10 11

MaClass::MaClass(MaClass const& rhs):nbElem(rhs.nbElem) { Type *current=rhs->first; while(current) { push_back(*current);//push_back prend en charge la copie de l'élément // passé en paramètre current=current->next;   } }

---

Il semble clair qu'il y a fortement intérêt à éviter les copies inutiles ;)

Partant de là, il devient "facile" de se faire une idée de l'intérêt des différents opérateurs considérés comme "mathématiques" ;)

A vrai d'ire j'utilise ça avec des constructeur sans instruction:

Code:

---

1 2	Classe::Classe(const Classe & classe):donnees(classe.donnees) {}

---

avec peut-être une petite opération d'ints sur une partie de classe.donnees...

En fait, je me demandais s'il créait vraiment une nouvelle classe étant donné que tout était inliné...

A vrai dire, la seule différence entre une fonction inline et une fonction qui ne l'est pas, c'est le fait que le code d'une fonction inline est susceptible de se trouver à plusieurs endroits dans le code (typiquement, à chaque endroit où... la fonction est invoquée ;))

Le gain de performances que tu peux tirer d'un tel fait est généralement limité à quelque fréquences d'horloges tels que les "push" de chaque donnée ;)

Et encore, le fait de déclarer une fonction ne fait que demander au compilateur de copier le code de la fonction... ce qui peut ne pas être possible, dans le cas des fonctions virtuelles et/ou des fonctions récursives (pour ce qu'il y a des cas les plus courents)...

Si donc, un constructeur ("classique" ou par copie) est défini inline, il aura exactement le même comportement que le comportement défini en non inline, à l'exception du fait que le code sera... copié partout où une variable du type adéquat devra être créée ou copiée ;)

Au final, le fait de créer une fonction inline n'apporte qu'un gain de performance finalement très limité, mais présente l'inconvénient principal que, si la fonction est importante et souvent appelée, tu obtiendra un exécutable de taille fortement augmentée ;)

Ensuite, le fait est qu'il est finalement rare que la plupart des classes que tu manipule se contentent de manipuler des types primitifs ;)...

Dés que tu décide, d'une manière ou d'une autre, de travailler avec des "structures dynamique" (comprend: pile, file, liste, etc...), les algorithmes que tu créera seront, d'office d'une complexité en O(N);)