Discussion :

[Bakura]

Bonsoir ^_^,

Je ne savais pas où mettre ce message, j'ai hésité avec la rubrique "Contribuez", mais ce n'est pas vraiment de moi =). J'ai trouvé cette astuce sur un blog et je vous la partage car je la trouve très utile. Par contre, elle ne fonctionne que sous Visual.

Vous n'êtes sûrement pas sans savoir que, afin de minimiser l'espace mémoire, les variables membres d'une classe ou d'une structure doivent être organisées suivant un ordre précis afin d'éviter de créer des "paddings" inutiles. J'imagine que le compilateur est suffisamment intelligent pour pouvoir réorganiser lui-même les variables (quelqu'un pourrait confirmer ou infirmer ?), mais c'est toujours mieux de le faire soi-même.

Concrètement, voici une structure qui illustre ce soucis :

Code :

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

1
2
3
4
5
6
7
struct Test
{
    char a; // 1 octet
    int b; // 4 octets
    char c; // 1 octet
    int d; // 4 octets
};

Puisque l'alignement se fait sur 4 octets, le compilateur va donc automatiquement ajouter un padding de 3 octets entre la variable a et b, et 3 autres entre c et d, ce qui donnera en fait ceci :

Code :

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

1
2
3
4
5
6
7
8
9
struct Test
{
    char a; // 1 octet
    char pad[3]; // 3 octets
    int b; // 4 octets
    char c; // 1 octet
    char pad2[3]; // 3 octets
    int d; // 3 octets
};

On a donc, dans cette structure, 6 octets qui sont gâchés. Il est parfois assez chiant de devoir compter soi-même pour réorganiser les données, et en fait, il existe un warning à activer qui permet de lever un warning automatiquement pour indiquer ça. C'est bizarre car même avec le warning niveau 4 il n'est pas activé.

L'astuce consiste en encadrer la structure par #pragma warning(error: 4820) et #pragma warning(disable: 4820), ce qui donne :

Code :

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

1
2
3
4
5
6
7
8
9
#pragma warning(error: 4820)
struct Test
{
			char a; // 1 octet
                        int b; // 4 octets
                        char c; // 1 octet
                        int d; // 4 octets
};
#pragma warning(disable: 4820)

Et le compilateur lève le warning suivant :

'Test' : '3' bytes padding added after data member 'Test::a'
'Test' : '3' bytes padding added after data member 'Test::c'

On sait donc immédiatement ou le padding est ajouté, et on peut donc réorganiser la structure comme ceci :

Code :

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

1
2
3
4
5
6
7
8
struct Test
{
    int b; // 4 octets
    int d; // 4 octets
   char a; // 1 octet
   char c; // 1 octet
   char pad[2]; // 2 octets
};

Et hop ! Au lieu de perdre 6 octets sur la structure on n'en perd que deux =). Je sais très bien que c'est le genre de micro-optimisation qui ne va pas changer grand chose en terme de performances, mais c'est tellement simple à réorganiser que je vois pas pourquoi on s'en priverait On peut ensuite enlever les #pragma et aller tester une autre classe.

[JulienDuSud]

Sur GCC, il y a ça aussi:

Code :

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

1
2
3
4
5
6
struct s {
	char a;
	int  b;
	char c;
	int  d;
} __attribute((packed));

Qui me donne sizeof( s ) == 10

Et je trouve que ça accentue gravement la lecture. (important par exemple pour un protocole réseau)

[Bakura]

Le __attribute ((packed)) réorganise donc automatiquement les variables ? Le pragma que j'ai montré ne réorganise rien, il t'indique juste les paddings ajoutés.

Par contre, j'obtiens, au mieux, 12 octets (avec l'alignement sur 4 octets). L'équivalent sous Visual semble être #pragma pack(1), et j'obtiens aussi 10 octets. Mais, sur le blog ou j'ai trouvé cette astuce, l'auteur indique ceci à propos du #pragma pack(1) :

#pragma pack(1) is not a good option, since it breaks natural alignment.

Qu'en est-il ?

Question annexe : l'alignement "par défaut" est-il également de 4 sur les plates-formes 64-bits ?

[JulienDuSud]

Le __attribute ((packed)) réorganise donc automatiquement les variables ?

Pas exactement.

En réalité, au lieu d'aligner sur 4 octets, il aligne sur 1 octet.

#pragma pack(1) is not a good option, since it breaks natural alignment.

Ca dépend pour quoi.

Le padding peut être différent d'implémentation en implémentation. Or, si tu veux sérialiser par exemple une structure assez longue, tu vas vraiment galérer à trouver des padding convenant à toutes tes implémentations (si seulement c'est possible).

Prenons par exemple le cas de la sérialisation: si tu fais un alignement de 1, alors toutes tes données seront alignées l'une à la suite de l'autre, exactement comme tu le veux. Tu n'as plus à te soucier du padding du tout. Par contre il faut le faire partout.

C'est le padding explicite qu'il faut en général éviter, car il peut ne rien vouloir dire sur certaines implémentations, et la norme ne garanti rien sur les tailles, ce qui va bien sûr influencer le padding.

Par contre, le padding va complètement sauter, et parfois on ne peut pas car le CPU va mal le prendre.

Exemple: les short (2 bytes chez moi) ont un alignement de 2 bytes. C'est à dire qu'ils ne peuvent se retrouver que dans des adresses multiples de 2, je dis bien normalement (avec les CPU actuels rien ne t'empêche de ne pas le respecter).
Les int (4 bytes chez moi) ont un alignement sur 4 bytes. Ils peuvent donc se retrouver sur toutes les adresses multiples de 4, etc...

Là où ça devient intéressant, c'est que __attribute((packed)) ignore ça. Ca peut être problèmatique si tu fais de l'arithmétique sur l'adresse de tes variables, mais en général le compilateur s'arrange pour mettre tes variables dans les bons endroits.

Question annexe : l'alignement "par défaut" est-il également de 4 sur les plates-formes 64-bits ?

Chez moi (Debian x64), oui.

[Bakura]

Le padding peut être différent d'implémentation en implémentation. Or, si tu veux sérialiser par exemple une structure assez longue, tu vas vraiment galérer à trouver des padding convenant à toutes tes implémentations (si seulement c'est possible).

J'avais pas pensé à ce détail, intéressant .

C'est le padding explicite qu'il faut en général éviter, car il peut ne rien vouloir dire sur certaines implémentations, et la norme ne garanti rien sur les tailles, ce qui va bien sûr influencer le padding.

C'est-à-dire ? J'ai toujours lu que c'était une bonne idée de justement explicité le padding :

Code :

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

1
2
3
4
5
6
 
struct s
{
   char a;
   char pad[3];
};

Mais effectivement ça pose problème si l'alignement "naturel" n'est pas sur 4 octets.

EDIT :

Exemple: les short (2 bytes chez moi) ont un alignement de 2 bytes. C'est à dire qu'ils ne peuvent se retrouver que dans des adresses multiples de 2, je dis bien normalement (avec les CPU actuels rien ne t'empêche de ne pas le respecter).

Pareil chez moi. Par contre les char (1 byte chez moi) ont un alignement de 2 octets... Il y a une explication ?

[JulienDuSud]

Pareil chez moi. Par contre les char (1 byte chez moi) ont un alignement de 2 octets... Il y a une explication ?

Chez moi, l'alignement se fait sur 1 byte (GCC 4.3). Preuve que ça dépend bien de l'implémentation.

L'alignement dans une structure se fait en général selon le plus restrictif des variables.

Exemple:

Code :

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

1
2
3
4
struct s {
  char a;
  char b;
};

Prend bien 2 bytes, pas besoin d'alignement, le plus restrictif est 1 byte.

Code :

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

1
2
3
4
struct s {
char a;
int    b;
};

Chez moi prend 8 bytes.

Par contre

Code :

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

1
2
3
4
struct s {
char a;
long long b;
};

Prend 16 bytes ! (et non 12) (x64)
Par contre ça prend 12 bytes sur du x86

Je me rends donc compte que l'alignement n'est pas sur 4 bytes max en x64 mais bien sur 8 bytes. Mes excuses

[ram-0000]

J'imagine que le compilateur est suffisamment intelligent pour pouvoir réorganiser lui-même les variables (quelqu'un pourrait confirmer ou infirmer ?)

J'espère bien que le compilateur ne se donne pas le droit de réorganiser l'ordre d'implémentation des membres dans une structure, cela peut poser de sérieux problèmes.

Par contre, qu'il rajoute du padding, pas de problème.

[Goten]

Si il réorganisait, alors ça irait pas avec la liste d'initialisation.. (il péterait un warning).

[screetch]

je crois (mais pas sur) que le compilo a le droit de reorganiser les membres qui ont une visibilité différente (protected, private, public) mais pas l'ordre au sein de ces groupes. je n'ai jamais trouvé la source cependant, et je suis 99% certain qu'aucun des compilos mainstream le fait (GCC, SunCC, Visual C++ ou Intel Compiler)

pour linux, il y a un warning : -Wpadded
mais le problème c'est que sa portée est de... tout le programme. si on sait qu'one structure est paddée, et qu'on ne peut rien y faire, on se tape le warning a chaque fois.

enfin, pour l'alignement, sur intel x86/x64 l'alignement naturel des types primitifs est en général leur taille; un char est aligné sur 1, un short sur 2, un float sur 4, un double sur 8 je crois (a verifier sur x86), un bool sur 1. Il y a une pénalité de lecture parfois sur une lecture non alignée. Certaines opérations requierent absolument un alignement correct (les instructions locked) et un resultat imprevisible se produit en cas d'adresse non alignée.
Les instructions SSE travaillent sur des registres et valeurs memoire 128 bits qui sont lues a des emplacements alignés sur 128 bits; il y a une instruction séparée pour lire sur une mémoire non alignée (plus lente que la version alignée), et si on lit a une adresse non alignée en utilisant l'adresse alignée, ca plantouille.
Enfin, certains processeurs (notamment le PowerPC) te jettent une exception a la gueule si tu leur file une mauvaise adresse.

[loufoque]

Mais effectivement ça pose problème si l'alignement "naturel" n'est pas sur 4 octets.

Il n'y a pas d'alignement naturel, simplement des alignements pour chaque type, ainsi qu'une taille pour chaque type.
Ce sont bien entendu des choses fortement spécifiques à la plate-forme.

Typiquement, pour les types primitifs, la taille et l'alignement sont les mêmes.

Les "bonnes" architectures interdisent tout simplement l'accès à la mémoire non alignée. D'autres, comme x86, le permettent mais c'est plus lent.

Pour toutes ces raisons, il ne faut pas essayer de manipuler l'organisation mémoire des structures ni d'écrire directement des structures sur disque ou réseau.
La bonne façon de procéder et de sérialiser la structure en un buffer de char vers le format désiré. (ce qui est bien plus portable)

[Mac LAK]

Enfin, certains processeurs (notamment le PowerPC) te jettent une exception a la gueule si tu leur file une mauvaise adresse.

Le pire est sûrement le SPARC (CPU des machines Solaris notamment) : un accès non-aligné = un signal "Bus Error" totalement impossible à chopper (dans l'esprit du "Segmentation Fault") et plantage. Sur un x86, par contre, c'est "masqué" mais l'accès est sensiblement plus lent.
De façon générale, il vaut mieux laisser le compilateur gérer l'alignement dans tout le code : on y gagne des performances, au prix (parfois) d'un peu de mémoire supplémentaire requise.

Les exceptions notables sont :

• Toute donnée binaire franchissant les frontières du processus courant (données vers les drivers, vers le réseau, vers un format de fichier particulier, vers d'autres machines) : dans ce cas, il faut systématiquement assurer l'alignement ET l'endianness.
• Les structures de données énormes (binaires ou non), où la perte de quelques pourcents de mémoire peut devenir critique.

Pour tout le reste, l'alignement automatique est souvent préférable.

[white_tentacle]

De façon générale, il vaut mieux laisser le compilateur gérer l'alignement dans tout le code : on y gagne des performances, au prix (parfois) d'un peu de mémoire supplémentaire requise.

Oui, et non .

En fait, oui, il faut laisser le compilateur gérer l'alignement, sauf cas particulier. Par contre, ça ne dispense pas d'écrire ses classes/structures correctement, de telle sorte que les pertes dues à l'alignement soient minimisées.

[Mac LAK]

En fait, oui, il faut laisser le compilateur gérer l'alignement, sauf cas particulier. Par contre, ça ne dispense pas d'écrire ses classes/structures correctement, de telle sorte que les pertes dues à l'alignement soient minimisées.

Cf. le deuxième cas d'exception que j'ai indiqué : quand c'est sur une classe présente à un ou deux exemplaires dans le processus, ça n'a (quasiment) aucune importance. C'est important si tu as des milliers (voire millions !) d'instances par contre.

[Aurelien.Regat-Barrel]

je crois (mais pas sur) que le compilo a le droit de reorganiser les membres qui ont une visibilité différente (protected, private, public) mais pas l'ordre au sein de ces groupes.

Il me semble aussi que le standard autorise les compilos à réorganiser les blocs dans l'ordre qu'il veut. Par exemple, on pourrait imaginer que le compilo réorganise de manière optimale notre struct si on l'écrit ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
struct Test
{
public:
    char a;
public:
    int b;
public:
    char c;
public:
    int d;
};

Ca reste à confirmer... d'un point de vue du standard. Dans la pratique, on sait déjà qu'il ne faut pas compter là dessus.

---

Le #pragma warning(error: 4820) ne fait qu'activer un warning. Ca peut être fait en ligne de commande / dans les options du projets. Idem pour la taille d'alignement par défaut : properties->C/C++->Code Generation->Struct Member Alignment. Ca correspond à l'option /Zp.

[koala01]

Salut,

Le #pragma warning(error: 4820) ne fait qu'activer un warning. Ca peut être fait en ligne de commande / dans les options du projets. Idem pour la taille d'alignement par défaut : properties->C/C++->Code Generation->Struct Member Alignment. Ca correspond à l'option /Zp.

Le fait est que, le pragma peut n'être applicable qu'à une ou un nombre limité de classe(s) / structure(s)...

Avec un Makefile, il est possible d'envisager de rajouter une option de compilation pour un (groupe de) fichier(s) particulier, mais, le fait de rajouter l'option directement à l'ensemble du projet risque, effectivement, de faire lever un tas d'avertissements "inutiles" du fait de l'impossibilité potentielle qu'il y a à réorganiser certaines structures.

A choisir, je pencherais (si je travaillais avec VC++) surement bien plus pour l'option de compilation, mais le fait d'avoir le choix n'est certainement pas un mal

Ceci dit, merci de l'avoir signalé en sus

[r0d]

Yop,

J'ai trouvé cette astuce sur un blog[...]

Tu pourrais donner l'adresse du blog s'il te plait?

[camboui]

Le #pragma warning(error: 4820) ne fait qu'activer un warning. Ca peut être fait en ligne de commande / dans les options du projets. Idem pour la taille d'alignement par défaut : properties->C/C++->Code Generation->Struct Member Alignment. Ca correspond à l'option /Zp.

Chez moi avec VS2005 c'est plus qu'un warning, c'est une erreur !

[Bakura]

Yop,


Tu pourrais donner l'adresse du blog s'il te plait?

http://msinilo.pl/blog/?p=478

[screetch]

en fait je preconiserai plutot le contraire
mettre le warning par défaut pour le projet
le désactiver sur des classes/structs que l'on ne souhaite pas optimiser
mais on ne sait jamais si le warning ne va pas peter sur une autre machine, sur un powerpc par exemple, donc le desactiver lors de la compilation par les utilisateurs.

[Mac LAK]

mais on ne sait jamais si le warning ne va pas peter sur une autre machine, sur un powerpc par exemple, donc le desactiver lors de la compilation par les utilisateurs.

Il serait étonnant qu'un compilateur pour PowerPC accepte les #pragma de Visual Studio...