Les entiers de type 'fast' ?

Bonjour,

Tout ou presque est dans le titre.

Suite à une précédente discussion, j'ai découvert que la norme n1256 prévoyait des types qualifiés de 'fast' : int_fastN_t et uint_fastN_t. Ces types sont obligatoires. Ils sont décrits à la section 7.18.1.3 Fastest minimum-width integer types.

Si j'ai bien tout compris, créer un objet de type int_fast32_t nous donne un entier de largeur au moins égale à 32 bits et garanti comme étant le plus rapide sur l'architecture cible. Avec un processeur 64 bits, c'est donc normalement un entier de largeur 64 bits puisque c'est la taille naturelle de manipulation de données du processeur : http://www.linuxbase.org/navigator/b...y-id&Tid=16619

Je me demande pourquoi je découvre seulement maintenant l'existence de ce type... Pourquoi est-ce qu'on ne voit jamais ce type dans les cours de C, dans des codes sur ce forum ? Ne devrait-il pas être utiliser pour toutes les variables locales dés que l'occupation mémoire est peu critique, pour améliorer la vitesse ? Ne devrait-il pas simplifier le portage et l'efficacité du code ?

J'attends vos avis, commentaires, remarques, expériences,... ;)

Merci d'avance !

Fie,

Bref, déclarer un int_fast32_t va conduire à un entier de 64 bits si on travaille sur du 64 bits.

Je ne les félicite pas sur la "clarté" finale du code ! :(

Citation:

---

Envoyé par Bktero

Si j'ai bien tout compris, créer un objet de type int_fast32_t nous donne un entier de largeur au moins égale à 32 bits et garanti comme étant le plus rapide sur l'architecture cible. Avec un processeur 64 bits, c'est donc normalement un entier de largeur 64 bits puisque c'est la taille naturelle de manipulation de données du processeur

---

C'est l'idée mais dans le cas présent, ce n'est pas nécessairement le cas non plus. Il faut déjà que le bus de données et la mémoire soient en 64 bits eux-aussi, sinon il faut faire deux transactions bus pour compléter un seul transfert.

Ensuite, il est tout-à-fait possible que du point de vue du micro-processeur, charger une valeur 32 bits ou 64 revienne exactement au même : il suffit d'afficher la bonne adresse et de lire normalement la donnée et d'ignorer les 32 bits de poids fort. Évidemment, cela implique que ledit micro-processeur soit câblé pour cela. On comprend également que, dans ce cas, c'est l'alignement en mémoire qui va être prépondérant.

Par contre, si on lit une adresse 32 bits « impaire », il faut qu'il soit également câblé pour reporter directement les bits 32 à 63 vers les bits 0 à 32 sinon, en lisant une chaîne d'entiers 32 bits consécutifs, on serait pénalisés en lisant une entrée sur deux.

Enfin, il y a un effet pervers dont il faut tenir compte : utiliser des entiers trop grands lorsqu'on traite des chaînes pénalise la ligne de cache.

Citation:

---

Je me demande pourquoi je découvre seulement maintenant l'existence de ce type... Pourquoi est-ce qu'on ne voit jamais ce type dans les cours de C, dans des codes sur ce forum ? Ne devrait-il pas être utiliser pour toutes les variables locales dés que l'occupation mémoire est peu critique, pour améliorer la vitesse ? Ne devrait-il pas simplifier le portage et l'efficacité du code ?

---

Je reconnais humblement que j'étais passé à côté moi-aussi. Cela dit, l'intérêt est mineur dans le cadre d'une programmation non spécialisée :

D'abord il ne reste aujourd'hui que peu de gens, malheureusement, qui s'intéressent réellement à l'optimisation et l'efficacité du code. Il est vrai que la puissance démesurée des machines contemporaines, les différences entre tous les modèles possibles et l'augmentation des couches successives exploitées par les langages de haut niveau rendent la différence difficile à mesurer. Ensuite, beaucoup de gens considèrent que c'est aujourd'hui le travail du compilateur de le faire. C'est vrai mais dans une certaine mesure seulement.

Ensuite, le C définit déjà une taille minimum pour les types natifs entiers et ce sont ces types qui donnent le plus de latitude au compilateur en matière de compilation. Ça veut dire que les types « fast » sont exclusivement tournés vers la rapidité d'exploitation. En se basant sur ce point et au vu des arguments exposés ci-dessus, sur une machine 64 bits, tous les entiers devaient être traduits en int64_t ou uint64_t. Une chaîne de caractère, par exemple, utiliserait donc huit octets par caractère.

On comprend alors aisément que même en environnement où la mémoire est abondante, ce genre de pratique est déconseillée (et remplit le cache). Il vaut mieux que ce soit une facilité offerte au programmeur, donc prévue par le langage, mais que celui-ci n'y recoure que dans les sections critiques.

Réponse tardive :)

Citation:

---

Bref, déclarer un int_fast32_t va conduire à un entier de 64 bits si on travaille sur du 64 bits.

---

Moins clair que d'utiliser un long qui fait 32 bits sur machine 32 bits et 64 bits sur machine 64 bits ? La norme ne donne qu'une taille minimum pour la plupart des types, au moins ceux-là l'affichent clairement. Je pense que quand tu commences à écrire ce genre de code, tu mets une balise "big beard needed" et que les gens susceptibles de lire le code derrière ne seront sûrement pas refoulé à l'entrée parce que les contraintes du projet sont telles qu'ils se laissent pas perdre par un 32 qui est en fait un 64.

Citation:

---

Je reconnais humblement que j'étais passé à côté moi-aussi. Cela dit, l'intérêt est mineur dans le cadre d'une programmation non spécialisée

---

Je travaille justement dans de la programmation assez spécialisée. On est dans l'embarqué, on est potentiellement à la recherche du gain de quelques cycles (de manière portable c'est encore mieux !).

Citation:

---

rendent la différence difficile à mesurer

---

Mmmm... C'est pas faux !

Citation:

---

On comprend alors aisément que même en environnement où la mémoire est abondante, ce genre de pratique est déconseillée (et remplit le cache). Il vaut mieux que ce soit une facilité offerte au programmeur, donc prévue par le langage, mais que celui-ci n'y recoure que dans les sections critiques.

---

Je vois ce que tu veux dire. Ca peut servir mais faut pas s'en servir de manière automatique : il faut savoir pourquoi et mesurer l'effet (bénéfique ou pas).

Citation:

---

Envoyé par Bktero

Je travaille justement dans de la programmation assez spécialisée. On est dans l'embarqué, on est potentiellement à la recherche du gain de quelques cycles (de manière portable c'est encore mieux !).

---

Je vois bien le cote portable, mais je crains neanmoins que tu ne perdes en compatibilte : si vous faites des optimisations poussees, ne penses-tu pas que vous risquez de vous retrouver a un moment ou a un autre a faire des conversions de 32 en 64 bits ou vice-versa ?


Un petit lien sur une autre optimisation (memoire) : http://glandium.org/blog/?p=2361
Et un autre sur les champs de bits : http://lwn.net/Articles/478657/