Discussion :

[Kaluza]

Bonjour.

J'ai un programme de calcul dans lequel je dois travailler avec des unsigned long long int (entier 64 bits). Mon problème est le suivant :
- certaines données seulement ont besoin d'être des entiers 64
- mais avec les autres, je dois pouvoir faire des opérations avec des entiers 64.

Imaginons par exemple que j'ai un tableau de 10000 nombres compris entre 0 et 65535. Je peux donc utiliser des "unsigned short int" pour prendre très peu de place en mémoire. Cependant j'ai besoin que pouvoir faire des opérations du type : a=b*c avec a et b "unsigned long long int" et "unsigned short int". Dans le cas d'une telle opération, est-ce que le cpu doit convertir c en "unsigned long long int" avant d'effectuer le calcul ?

Parce que si une telle conversion doit être faite, je suppose que cela doit coûter un certain nombre de ticks d'horloge... Du coup, est-ce qu'il est plus rapide de travailler avec un tableau de 10000 "unsigned long long int" qui me prends plus de place en mémoire, mais évite de perdre du temps à caster ?

Merci

[Nudger]

Bonsoir,

Ça dépend du processeur et du compilateur.
Pour en avoir le coeur net, il faudrait faire le test: avec une boucle d'un million d'itération faire la multiplication avec uniquement des entiers 64 puis dans les mêmes conditions la multiplication avec un cast et comparer les temps d'exécution.

[koala01]

Salut,

Il faut se rendre compte que, de manière générale, toute valeur numérique dont la taille est inférieure à celle des registre du processeur sera, hormis le cas où tu travailles sur un tableau de données, automatiquement promu dans le type correspondant (toujours en terme de taille ) à celui utilisé par le processeur.

Il faut en effet se bien comprendre que les adresses disponibles par le systèmes sont évaluées de manière à faire en sorte que les données récupérées entre entièrement dans un registre et qu'elles l'utilise entièrement.

La seule distinction pouvant, éventuellement, être faite étant le fait qu'un registre est lui-même "subdivisé" en différentes parties, correspondant au byte (il y a 8 sous parties composées de 8 bits dans un registre 64 bits )

Tu n'économisera donc pas de place si tu n'utilise qu'un (unsigned) short au lieu d'utiliser un (unsigned) long long, simplement parce que l'alignement des données en mémoire fera que tu "perdra" un nombre de bits correspondant à la différence entre la taille du registre et celle du short

Et le gain que tu pourrais avoir en utilisant un tableaux de (unsigned) short au lieu d'un tableau de (unsigned) long long est, hors particularité du système, suffisemment marginal pour décider, à mon sens, de ne pas "perdre son temps" à peaufiner le type des valeurs les plus petites

Le gros intérêt, par contre, sera que le compilateur pourra déterminer plus facilement s'il y a risque de dépassement d'une valeur (t'indiquer que, si tu fais +1 sur 65535, tu retournes à 0 avec un unsigned short).

[Blustuff]

Pour illustrer, sur x86, les multiplications sont faites sur des opérandes 32 bits et donnent un résultat sur 64 bits. Il est alors facile de multiplier des nombres de taille arbitrairement grande. Si l'un des opérandes de la multiplication est sur 32 bits non signé, le compilateur va le promouvoir mais en notant bien que la partie haute vaut 0 ce qui permettra avec les optimisations arithmétiques de supprimer la multiplication de cette partie haute et économisera les quelques cycles.

Pour des registres plus grands (d'autres architectures, ou alors avec MMX/SSE/etc.) cette optimisation n'aura aucun intérêt.

La promotion 32bits -> 64bits en elle même ne coûte quasiment rien. Il est même possible qu'elle n'ajoute aucun cycle sur ton exécution. Si cette promotion est dans une boucle sur une valeur qui ne change pas d'une itération sur l'autre, ton compilateur va probablement extraire la promotion invariante pour la faire hors de la boucle.

On parle ici de grandeurs de l'ordre du cycle. Le coût de la lecture en mémoire n'est pas du même ordre. Il est possible que ce soit la lecture de mémoire qui soit le principal facteur du temps d'exécution et de fait, en limiter la taille sera prédominant.

En conclusion, invariable sur ce genre de sujets : l'optimisation va être très dépendante de ton application, ne peut pas être exprimée en terme généraux (sinon ton compilateur la ferait) et va dépendre (souvent) de l'architecture cible. A ce point, toute optimisation te demandera un temps important 1/ à conçevoir 2/ à tester, et s'opérera au détriment de la lisibilité de ton code, tout ça pour une amélioration des performances souvent déçevante.