optimisation : malloc et alignement de structures

Version imprimable

13/06/2016, 14h43
boboss123

optimisation : malloc et alignement de structures
Bonjour,

Je veux réserver via malloc un espace mémoire contenant un tableau de type STRUCT_FOO (une structure quelconque).

Est-ce que ce code fonctionne forcement ? (pour simplifier le code, on admettra que malloc ne renvoit pas NULL)
Code:

1 2 3 4 5 const int nb_elements = 10; STRUCT_FOO * tab = malloc(sizeof(STRUCT_FOO)*nb_elements); tab[5].prop1 = 5; tab[10].prop2 = 10; ...
=> Entre deux éléments de mon tableau, il ne faut pas du padding ? comment le calculer/gérer ?
=> L'adresse du premier élément du tableau ne doit pas être aligné sur une adresse divisible par la taille de STRUCT_FOO ? Comment gérer ce problème ?

Merci d'avance,
13/06/2016, 15h04
Matt_Houston

Toutes les contraintes d'alignement / offsets sont automatiquement prises en charge, c'est un avantage du C par rapport à l'assembleur. ;) Par curiosité, pourquoi pensais-tu que tu devais te préoccuper de ce genre de chose ?

Si pour d'obscures raisons techniques tu dois toi-même spécifier et / ou contrôler l'alignement de tes champs, des directives plus ou moins standards selon la norme utilisée existent pour ton compilateur.

En revanche ce code plantera pour une autre raison qui est un dépassement de capacité. :mrgreen:
13/06/2016, 15h37
boboss123

Citation:

Envoyé par Matt_Houston

Par curiosité, pourquoi pensais-tu que tu devais te préoccuper de ce genre de chose ?

Parce que par le passé, j'ai déja eu des problèmes de gestion de pointeurs à cause de problèmes d'alignement... malheureusement, je ne me rappelle plus exactement du problème : ma mémoire flanche :aie:
13/06/2016, 16h07
Matt_Houston

Tu devras t'en préoccuper si tu comptes interpréter manuellement ta structure sous forme de char *, mais si tu t'en tiens aux champs définis c'est transparent.
13/06/2016, 16h38
boboss123

ok merci

Bonjour,

Plus précisément c'est sizeof() qui gère le padding, et malloc() retourne toujours une donnée alignée sur le plus petit entre
* l'alignement maximum (typiquement 8 ou 16)
* et la taille requise tronquée en puissance de 2.
On a ainsi un resultat qui fonctionnera dans tous les cas.
Exemple en 32bits
Code:

1 2 3 4 5 6 7 8 struct A { short x; char y; }; sizeof(A) //=> 4=2+2 qui est multiple du plus grand alignement, ici celui du short vaut 2 A* p = malloc( 5 * sizeof(A) ); // => un pointeur multiple de 16 avec réservation de 4*5=20 octets A* q = malloc( 3 * sizeof(A) ); // => un pointeur multiple de 8 avec réservation de 4*3=12 octets p[1] // est à l'offset 1*8=8

14/06/2016, 09h07
boboss123

ok merci pour ces précisions

Par contre si dans ma zone mémoire, je cascade deux tableaux de type différent, je ne risque pas d'avoir de problème d'alignement (ex: si STRUCT_FOO1 plus petit que STRUCT_FOO2) ?
Code:

1 2 3 4 5 6 const int nb_elements = 10; void * ptr = malloc((sizeof(STRUCT_FOO1) + sizeof(STRUCT_FOO2))*nb_elements); STRUCT_FOO1 * tab1 = ptr; STRUCT_FOO2 * tab2 = ptr + (sizeof(STRUCT_FOO1) * nb_elements);
Comment géré ce problème de manière générique (que si je change la taille d'une des structure, que mon code fonctionne quand même) ?

Je ne sais pas ce que tu entends par « cascader », ce que tu cherches à obtenir en mémoire (un schéma peut-être ?).

Si tu veux « mélanger » les deux éléments au sein d'un seul tableau, alors il faut utiliser une union :
Code:

1 2 3 4 5 6 7 8 9 10 11 typedef union { STRUCT_FOO1 foo1; STRUCT_FOO2 foo2; } UNION_BAR; STRUCT_FOO1 myfoo1; STRUCT_FOO2 myfoo2; // ... UNION_BAR *tbar = malloc(10 * sizeof(UNION_BAR)); tbar[2].foo1 = myfoo1; tbar[6].foo2 = myfoo2;
Bien évidemment sizeof(UNION_BAR) vaut la taille du plus « gros » membre de l'union. Les éléments d'un tableau ou assimilé ont toujours tous la même taille.

À noter qu'en général on recourt à un identifiant afin de savoir quel membre de l'union est initialisé, soit interne (un dans chaque membre), soit externe comme ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 typedef enum { BAR_FOO1, BAR_FOO2 } BARTYPE; typedef struct { union { STRUCT_FOO1 foo1; STRUCT_FOO2 foo2; }; // membre anonyme : requiert au moins C99 BARTYPE type; } STRUCT_BAR; STRUCT_BAR bar; // ... switch (bar.type) { case BAR_FOO1: return bar.foo1; case BAR_FOO2: return bar.foo2; }

Par cascader, je voulais dire que dans la zone mémoire réservée, je place au début le premier tableau et ensuite le second (ce n'est pas une union)
=> en faite le plus simple je pense est de créer une nouvelle structure qui contient le deux tableaux, non ?
Code:

1 2 3 4 5 6 7 8 9 10 11 typedef struct { STRUCT_FOO1 tab1[10]; STRUCT_FOO2 tab2[20]; } STRUCT_MERGE; STRUCT_MERGE * ptr = malloc(sizeof(STRUCT_MERGE)); STRUCT_FOO1 * tab1 = ptr->tab1; STRUCT_FOO2 * tab2 = ptr->tab2;
... mais cette solution fonctionne que si on connait à l'avance le nombre d'éléments des tableaux

14/06/2016, 10h58
Matt_Houston

C'est-à-dire interlacer les structures en contigü comme ceci : 12121212121212... ? Oui la solution est de définir un enregistrement composite.
14/06/2016, 11h40
boboss123

je n'ai pas compris ton message
j'ai complété mon précédent message peut-être que tu comprendras mieux
14/06/2016, 12h29
Matt_Houston

C'est pour cela que je recommandais un schéma qui vaut souvent tous les discours.

Ok je pense avoir enfin saisi, tu veux deux tableaux indépendants mais contigüs c'est cela (alloués d'un bloc) ? Je pense que mélanger les deux types c'est s'exposer à un comportement indéfini.

NOn ça ne fonctionne pas

code de test :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 #include <stdio.h> #include <stdlib.h> typedef struct{ char a; char b; char c; } STRUCT_FOO1; typedef struct{ int a; int b; } STRUCT_FOO2; int main() { printf("sizeof(STRUCT_FOO1) : %i\n", sizeof(STRUCT_FOO1)); printf("sizeof(STRUCT_FOO2) : %i\n", sizeof(STRUCT_FOO2)); char *ptr = malloc(3 * (sizeof(STRUCT_FOO1) + sizeof(STRUCT_FOO2))); printf("ptr : %p\n", ptr); STRUCT_FOO1 *tab1 = (STRUCT_FOO1 *)ptr; STRUCT_FOO2 *tab2 = (STRUCT_FOO2 *)(ptr + 3 * sizeof(STRUCT_FOO1)); printf("tab1 : %p\n", tab1); printf("tab2 : %p\n", tab2); return 0; }
=> tab2 pointe sur une adresse impaire : sur un PC, ce type d'erreur ne semble pas trop poser de problème mais sur un µControlleur, c'est certains que ça pose problème car un int (4 octets sur architecture 32bits) ne peut pas être stocké sur une adresse impaire.

En encapsulant tout dans une structure, l'alignement devient correcte :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#include <stdio.h>
#include <stdlib.h>
 
typedef struct{
    char a;
    char b;
    char c;
} STRUCT_FOO1;
 
typedef struct{
    int a;
    int b;
} STRUCT_FOO2;
 
typedef struct{
    STRUCT_FOO1 tab1[3];
    STRUCT_FOO2 tab2[1];
} STRUCT_MERGE;
 
 
int main()
{
    printf("sizeof(STRUCT_FOO1) : %i\n", sizeof(STRUCT_FOO1));
    printf("sizeof(STRUCT_FOO2) : %i\n", sizeof(STRUCT_FOO2));
 
    char *ptr = malloc(sizeof(STRUCT_MERGE));
    printf("ptr : %p\n", ptr);
 
    STRUCT_MERGE * struct1 = (STRUCT_MERGE *)ptr;
    STRUCT_FOO1 *tab1 = struct1->tab1;
    STRUCT_FOO2 *tab2 = struct1->tab2;
    printf("tab1 : %p\n", tab1);
    printf("tab2 : %p\n", tab2);
 
    return 0;
}

... mais on ne peut pas utiliser cette méthode pour gérer des tableaux a taille variable : comment faire (en utilisant qu'un seul malloc) ?

14/06/2016, 17h11
Matt_Houston

Tu as raison, je suis probablement fatigué... j'ai édité mon précédent message pour ne pas induire des lecteurs en erreur. Je pense qu'il est impossible de mélanger les types sans entraîner un comportement indéfini (je ne parviens pas à trouver un extrait de la norme là qui l'exprime noir sur blanc). Je veux dire, ça fonctionnera probablement sur beaucoup de plate-formes, jusqu'au jour où ça craquera.

Pourquoi ne veux-tu faire qu'un seul malloc ?

On peut mettre deux tableaux dans un seul malloc(), mais il faut faire gaffe lors du calcul de la taille totale et de l'offset du second tableau, aux contraintes d'alignement.

Par chance, on peut aller "du côté de la sécurité" en utilisant la taille de la structure comme alignement (vu que sizeof() doit inclure l'alignement, il ne retournera jamais une valeur fausse). On aurait donc un truc du genre:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
size_t tailleTotale = 0;
size_t offset1 = 0, offset2 = 0;
 
/*Le tableau de Struct1*/
tailleTotale = arrondirAuMultipleSuperieur(tailleTotale, sizeof(Struct1));
offset1 = tailleTotale;
tailleTotale += numberOfStruct1 * sizeof(Struct1);
 
/*Le tableau de Struct2*/
tailleTotale = arrondirAuMultipleSuperieur(tailleTotale, sizeof(Struct2));
offset2 = tailleTotale;
tailleTotale += numberOfStruct2 * sizeof(Struct2);
 
/*etc.*/
 
/*Avec la fonction définie du genre:*/
size_t arrondirAuMultipleSuperieur(size_t valeur, size_t tailleBloc)
{
	valeur += tailleBloc - 1;
	return (valeur / tailleBloc) * tailleBloc;
}

Et on peut même décider de se faire une structure d'en-tête contenant les pointeurs vers les tableaux voulus:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
size_t tailleTotale = 0;
size_t offset1 = 0, offset2 = 0;
 
tailleTotale += sizeof(StructEnTete);
 
/*Le tableau de Struct1*/
tailleTotale = arrondirAuMultipleSuperieur(tailleTotale, sizeof(Struct1));
offset1 = tailleTotale;
tailleTotale += numberOfStruct1 * sizeof(Struct1);
 
/*Le tableau de Struct2*/
tailleTotale = arrondirAuMultipleSuperieur(tailleTotale, sizeof(Struct2));
offset2 = tailleTotale;
tailleTotale += numberOfStruct2 * sizeof(Struct2);
 
/*etc.*/
 
void* buf = malloc(tailleTotale); /*C'est du C, pas besoin de cast explicite pour void* */
StructEnTete* pEnTete = buf;
pEnTete->pTableau1 = ajoutPointeurOffset(buf, offset1);
pEnTete->pTableau2 = ajoutPointeurOffset(buf, offset2);
/*etc.*/
 
/*Avec la fonction définie du genre:*/
void* ajoutPointeurOffset(void* pv, size_t offset)
{
	intptr_t valeur = (intptr_t)pv;
	valeur += offset;
	return (void*)valeur;
}
void const* ajoutPointeurOffsetC(void const* pcv, size_t offset)
{
	intptr_t valeur = (intptr_t)pv;
	valeur += offset;
	return (void const*)valeur;
}

15/06/2016, 09h10
boboss123

Citation:

Envoyé par Matt_Houston

Pourquoi ne veux-tu faire qu'un seul malloc ?

Parce que sur des systèmes embarqués où la taille de la RAM est très limitée, si tu fais pleins de réservations mémoire pour de petites structures (ex: listes chainées), le gestionnaire de mémoire dynamique va devoir stocker toutes les adresses mémoires réservées et leur taille : ce qui va consommer de la RAM de manière non négligeable.
Actuellement, je n'ai pas de problème de taille de RAM mais autant utiliser les "bonnes pratiques" dès maintenant ;)
15/06/2016, 09h44
boboss123

Citation:

Envoyé par Médinoc

Par chance, on peut aller "du côté de la sécurité" en utilisant la taille de la structure comme alignement (vu que sizeof() doit inclure l'alignement, il ne retournera jamais une valeur fausse). On aurait donc un truc du genre:

Merci pour ta réponse
Il me semble que ce n'est pas forcément optimal car d'après les tests que j'ai fait, l'alignement d'une structure ne se fait pas sur sa taille totale mais sur la taille du type le plus gros utilisé dans la structure (à confirmer avec la norme que je ne connais pas bien).
Aussi, je pense que l'alignement est opérationnel si on utilise des adresses divisibles par la taille d'un "void *" : à confirmer.
15/06/2016, 14h40
Médinoc

Je n'ai pas dit que c'était optimal, j'ai dit que c'était "play it safe".
Si tu connais l'alignement des structures sur ta plate-forme (ou si ton compilo supporte alignof), tu peux faire quelque chose d'optimal au lieu de quelque chose de "safe".
15/06/2016, 14h53
boboss123

oki

Citation:

Envoyé par boboss123

Merci pour ta réponse
Il me semble que ce n'est pas forcément optimal car d'après les tests que j'ai fait, l'alignement d'une structure ne se fait pas sur sa taille totale mais sur la taille du type le plus gros utilisé dans la structure (à confirmer avec la norme que je ne connais pas bien).
Aussi, je pense que l'alignement est opérationnel si on utilise des adresses divisibles par la taille d'un "void *" : à confirmer.

Oui, bien sûr. Une structure doit avoir un alignement compatible avec tous ses éléments, elle a donc le plus grand alignement de ses éléments. Ainsi
Code:

1 2 3 struct A { short a; long b; char c; }; // => alignement 4 et taille 12 dont 5 octets de padding struct A2 { short a; int : 16; long b; char c; int : 24 }; // est équivalent struct B { long b; short a; char c; }; // organisation différente => alignement 4 et taille 8 dont 1 octets de padding
Un tableau de A ou de B doit garantir que le champ x.b est toujours aligné 4 et que le champ x.a est aligné 2.
Il est recommandé de mettre les objets nécessitant un alignement important en première position.

Bonsoir,

Citation:

Envoyé par Matt_Houston

Toutes les contraintes d'alignement / offsets sont automatiquement prises en charge, c'est un avantage du C par rapport à l'assembleur. ;) Par curiosité, pourquoi pensais-tu que tu devais te préoccuper de ce genre de chose ?

Si pour d'obscures raisons techniques tu dois toi-même spécifier et / ou contrôler l'alignement de tes champs, des directives plus ou moins standards selon la norme utilisée existent pour ton compilateur.

En revanche ce code plantera pour une autre raison qui est un dépassement de capacité. :mrgreen:

Vous avez écrit, « Toutes les contraintes d’alignement/offset sont automatiquement prises en charge, c’est un avantage du C par rapport à l’assembleur. » D’accord, mais comment le langage C, peut-il, prendre en charge ces contraintes ?
Comment peut-il gérer les alignements ? Ce n’est pas le travail du compilateur ?
Peut-être que je me trompe (corrigez moi si c’est le cas), il me semble qu’il n’est pas d'avantage du langage C sur l’assembleur. Les compilateurs proposent des options, et des optimisations qui ont pour but d’améliorer les performances et d’ailleurs ce sont les compilateurs qui se chargent de faire tout le travail nécessaire pas le langage C.
Citation:
Envoyé par dalfab
Bonjour,

Plus précisément c'est sizeof() qui gère le padding, et malloc() retourne toujours une donnée alignée sur le plus petit entre
* l'alignement maximum (typiquement 8 ou 16)
* et la taille requise tronquée en puissance de 2.
On a ainsi un resultat qui fonctionnera dans tous les cas.
Exemple en 32bits
Code:

1 2 3 4 5 6 7 8 struct A { short x; char y; }; sizeof(A) //=> 4=2+2 qui est multiple du plus grand alignement, ici celui du short vaut 2 A* p = malloc( 5 * sizeof(A) ); // => un pointeur multiple de 16 avec réservation de 4*5=20 octets A* q = malloc( 3 * sizeof(A) ); // => un pointeur multiple de 8 avec réservation de 4*3=12 octets p[1] // est à l'offset 1*8=8
« sizeof » ne gère aucun padding il permet de connaître la taille en octets de la structure en question et cette taille peut être supérieure à la taille des éléments, car « sizeof » tient compte de la représentation physique et intègre des zones inutilisées du cadrage sur un mot machine. Le padding vient du fait que le compilateur rajoute des octets pour respecter l’alignement et c’est là où il y a du gaspillage mémoire et que sizeof tient compte de ces octets padding, mais en aucun cas il les gère.
exemple:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 /* ============================================================================ Name : Untitled 4.c Author : SAMBIA39 Version : 0.1 Copyright : Copyright (c) 15/06/2016 SAMBIA39 Description : Ansi-style ============================================================================ */ #include <stdio.h> #include <stdlib.h> /* Les membres de la structures sont mal alignés un -Wpadded permet de nous le spécifié */ struct s_data_a{ char tab_A[3]; short data_s; /* defaut d'alignement le compilateur fait du padding */ char tab_b[1]; }; struct s_data_b{ char tab_b[1]; char tab_A[3]; short data_s; }; int main( void ){ struct s_data_a x; struct s_data_b y; fprintf( stdout, "size A\t:%ld\nsize B\t:%ld\n", sizeof(x), sizeof(y) ); return EXIT_SUCCESS; }
Citation:
Envoyé par dalfab
Oui, bien sûr. Une structure doit avoir un alignement compatible avec tous ses éléments, elle a donc le plus grand alignement de ses éléments. Ainsi
Code:

1 2 3 struct A { short a; long b; char c; }; // => alignement 4 et taille 12 dont 5 octets de padding struct A2 { short a; int : 16; long b; char c; int : 24 }; // est équivalent struct B { long b; short a; char c; }; // organisation différente => alignement 4 et taille 8 dont 1 octets de padding
Un tableau de A ou de B doit garantir que le champ x.b est toujours aligné 4 et que le champ x.a est aligné 2.
Il est recommandé de mettre les objets nécessitant un alignement important en première position.
Le code que vous proposez en forçant l’alignement, me signale des erreurs d’alignement avec les options de compilation suivantes.

Code:

gcc *.c -Wall -Wextra -Werror -Wpadded -o TEST
Citation:
Envoyé par boboss123
Bonjour,

Je veux réserver via malloc un espace mémoire contenant un tableau de type STRUCT_FOO (une structure quelconque).

Est-ce que ce code fonctionne forcement ? (pour simplifier le code, on admettra que malloc ne renvoit pas NULL)
Code:

1 2 3 4 5 const int nb_elements = 10; STRUCT_FOO * tab = malloc(sizeof(STRUCT_FOO)*nb_elements); tab[5].prop1 = 5; tab[10].prop2 = 10; ...
=> Entre deux éléments de mon tableau, il ne faut pas du padding ? comment le calculer/gérer ?
=> L'adresse du premier élément du tableau ne doit pas être aligné sur une adresse divisible par la taille de STRUCT_FOO ? Comment gérer ce problème ?

Merci d'avance,
=> Entre deux éléments de mon tableau, il ne faut pas du padding ? comment le calculer/gérer ?:
Le padding influence sur la taille de la structure, il vous est possible de corriger ce gâchis manuellement soit en forçant l’alignement comme dans le dernier exemple de dalfab ou en faisant comme dans mon précédent exemple.

=> L'adresse du premier élément du tableau ne doit pas être aligné sur une adresse divisible par la taille de STRUCT_FOO ? Comment gérer ce problème ?: Quel est l’intérêt d’une telle manoeuvre ? Honnêtement, je n’ai pas vraiment saisi le fond de la question. Mais si vous souhaitez aligner ou gérer les alignements voire une zone mémoire correctement alignée vous avez les fonctions suivantes:
Code:

1 2 3 4 void * aligned_alloc (size_t alignment , size_t size ); void * memalign (size_t boundary , size_t size ); int posix_memalign (void ** memptr , size_t alignment , size_t size );
à bientôt.

15/06/2016, 21h23
dalfab

Citation:

Envoyé par sambia39

Bonsoir,

Vous avez écrit, « Toutes les contraintes d’alignement/offset sont automatiquement prises en charge, c’est un avantage du C par rapport à l’assembleur. » D’accord, mais comment le langage C, peut-il, prendre en charge ces contraintes ?
Comment peut-il gérer les alignements ? Ce n’est pas le travail du compilateur ?
Peut-être que je me trompe (corrigez moi si c’est le cas), il me semble qu’il n’est pas d'avantage du langage C sur l’assembleur. Les compilateurs proposent des options, et des optimisations qui ont pour but d’améliorer les performances et d’ailleurs ce sont les compilateurs qui se chargent de faire tout le travail nécessaire pas le langage C.

Distinguer le compilateur de langage C du langage C, est d'une subtilité qui me dépasse.

Citation:

Envoyé par sambia39

« sizeof » ne gère aucun padding il permet de connaître la taille en octets de la structure en question et cette taille peut être supérieure à la taille des éléments, car « sizeof » tient compte de la représentation physique et intègre des zones inutilisées du cadrage sur un mot machine. Le padding vient du fait que le compilateur rajoute des octets pour respecter l’alignement et c’est là où il y a du gaspillage mémoire et que sizeof tient compte de ces octets padding, mais en aucun cas il les gère.

Oui sizeof ne fait rien, mais sizeof d'un objet inclut toujours le padding éventuel qui devra être effectué

Citation:

Envoyé par sambia39

Le code que vous proposez en forçant l’alignement, me signale des erreurs d’alignement avec les options de compilation suivantes.

Code:

gcc *.c -Wall -Wextra -Werror -Wpadded -o TEST

Avec les options
-Wpadded
* Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure. Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller.
-Werror
* Make all warnings into errors.
On demande de considérer la nécessité de faire du padding comme un warning et on demande aux warnings d'être considérés en erreur :roll:

Citation:

Envoyé par dalfab

Distinguer le compilateur de langage C du langage C, est d'une subtilité qui me dépasse.

Oui sizeof ne fait rien, mais sizeof d'un objet inclut toujours le padding éventuel qui devra être effectué

Avec les options
-Wpadded
* Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure. Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller.
-Werror
* Make all warnings into errors.
On demande de considérer la nécessité de faire du padding comme un warning et on demande aux warnings d'être considérés en erreur :roll:

Vous avez écrit que «Oui sizeof ne fait rien, mais sizeof d'un objet inclut toujours le padding éventuel qui devra être effectué». D’accord, et j’ai écrit "sizeof tient compte de la représentation physique et intègre des zones inutilisées du cadrage sur un mot machine".
Zone inutilisée c’est le padding venant du fait que le compilateur rajoute des octets pour respecter l’alignement et honnêtement, je n’ai pas compris ce que vous avez essayé de me faire comprendre.

Citation:

Envoyé par dalfab

Distinguer le compilateur de langage C du langage C, est d'une subtilité qui me dépasse.
Oui sizeof ne fait rien, mais sizeof d'un objet inclut toujours le padding éventuel qui devra être effectué

J’ai souligné que si je me trompais, que l’on me corrige.
De plus la phrase qui a été écrite peut porter à confusion. On peut comprendre que l’avantage du C par rapport à l’assembleur est que toutes les contraintes d’alignement/offset sont automatiquement prises en charge sans plus de précision à croire que c’est le C qui le prend en charge d’où peut-être l’intérêt d’un distinguo.

Citation:

Envoyé par dalfab

Avec les options
-Wpadded
* Warn if padding is included in a structure, either to align an element of the structure or to align the whole structure. Sometimes when this happens it is possible to rearrange the fields of the structure to reduce the padding and so make the structure smaller.
-Werror
* Make all warnings into errors.
On demande de considérer la nécessité de faire du padding comme un warning et on demande aux warnings d'être considérés en erreur :roll:

-Wpadded: Permet de savoir si une structure est alignée ou pas, et que si cela arrive, il est à la charge du développeur de faire le nécessaire pour réorganiser les champs afin de rendre la structure plus petite.
-Werror: Veut juste dire que tout warning est considéré comme erreur et de ce fait, la compilation est arrêtée donc:

Code:

-Wall -Wextra -Werror -Wpadded -o TEST

veut dire:
Activer tous les warnings; activer les warnings de padding de structure; considérer tous les warning comme étant des erreurs ce qui arrête la compilation et affiche les erreurs.
voici un exemple en partant de mon code précédent:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 /* ============================================================================ Name : Untitled 6.c Author : SAMBIA39 Version : 0.1 Copyright : Copyright (c) 14/06/2016 SAMBIA39 Description : Ansi-style ============================================================================ */ #include <errno.h> #include <string.h> #include <stdio.h> #include <stdlib.h> struct s_data_a{ char tab_A[3]; short data_s; char tab_b[1]; }; /*struct s_data_b{ char tab_b[1]; char tab_A[3]; short data_s; };*/ int main( void ){ struct s_data_a x; //struct s_data_b y; fprintf( stdout, "size A\t:%ld\n", sizeof(x) ); //fprintf( stdout, "size B\t:%ld\n", sizeof(y) ); return EXIT_SUCCESS; }
Code:

1 2 3 4 5 6 7 8 9 10 11 gcc source.c -Wall -Wextra -Werror -g -Wpadded -o OUT_TEST source.c:20:8: error: padding struct 'struct s_data_a' with 1 byte to align 'data_s' [-Werror,-Wpadded] short data_s; ^ source.c:18:8: error: padding size of 'struct s_data_a' with 1 byte to alignment boundary [-Werror,-Wpadded] struct s_data_a{ ^ 2 errors generated.
Le même code avec une autre variante de la structure
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 /* ============================================================================ Name : Untitled 6.c Author : SAMBIA39 Version : 0.1 Copyright : Copyright (c) 14/06/2016 SAMBIA39 Description : Ansi-style ============================================================================ */ #include <errno.h> #include <string.h> #include <stdio.h> #include <stdlib.h> /*struct s_data_a{ char tab_A[3]; short data_s; char tab_b[1]; };*/ struct s_data_b{ char tab_b[1]; char tab_A[3]; short data_s; }; int main( void ){ //struct s_data_a x; struct s_data_b y; //fprintf( stdout, "size A\t:%ld\n", sizeof(x) ); fprintf( stdout, "size B\t:%ld\n", sizeof(y) ); return EXIT_SUCCESS; }
Code:

1 2 3 4 5 VMDesk:Desktop VMDesk$ gcc source.c -Wall -Wextra -Werror -g -Wpadded -o OUT_TEST VMDesk:Desktop VMDesk$ ./OUT_TEST size B :6 VMDesk:Desktop VMDesk$
Et les deux sans l'option "-Werror"
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 /* ============================================================================ Name : Untitled 6.c Author : SAMBIA39 Version : 0.1 Copyright : Copyright (c) 14/06/2016 SAMBIA39 Description : Ansi-style ============================================================================ */ #include <errno.h> #include <string.h> #include <stdio.h> #include <stdlib.h> struct s_data_a{ char tab_A[3]; short data_s; char tab_b[1]; }; struct s_data_b{ char tab_b[1]; char tab_A[3]; short data_s; }; int main( void ){ struct s_data_a x; struct s_data_b y; fprintf( stdout, "size A\t:%ld\n", sizeof(x) ); fprintf( stdout, "size B\t:%ld\n", sizeof(y) ); return EXIT_SUCCESS; }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 VMDesk:Desktop VMDesk$ gcc source.c -Wall -Wextra -g -Wpadded -o OUT_TEST_B source.c:19:8: warning: padding struct 'struct s_data_a' with 1 byte to align 'data_s' [-Wpadded] short data_s; ^ source.c:17:8: warning: padding size of 'struct s_data_a' with 1 byte to alignment boundary [-Wpadded] struct s_data_a{ ^ 2 warnings generated. VMDesk:Desktop VMDesk$ ./OUT_TEST_B size A :8 size B :6 VMDesk:Desktop VMDesk$
Citation:

Envoyé par dalfab

~~On demande de considérer la nécessité de faire du padding comme un warning et on demande aux warnings d'être considérés en erreur :roll:~~

On remarque que l’on a deux structures identiques, mais l’un bouffe plus d’octets que l’autre j’espère qu’avec mes exemples vous avez compris.
à bientôt

16/06/2016, 11h07
Matt_Houston

Citation:

Envoyé par boboss123

Parce que sur des systèmes embarqués où la taille de la RAM est très limitée, si tu fais pleins de réservations mémoire pour de petites structures (ex: listes chainées), le gestionnaire de mémoire dynamique va devoir stocker toutes les adresses mémoires réservées et leur taille : ce qui va consommer de la RAM de manière non négligeable.
Actuellement, je n'ai pas de problème de taille de RAM mais autant utiliser les "bonnes pratiques" dès maintenant ;)

On cause justement d'allocation en bloc puisque ce sont des tableaux. Tu as beaucoup de tableaux de ce type à allouer et manipuler ? Sinon, économiser un appel sur deux via des interprétations d'adresses ô combien dangereuses c'est typiquement de l'optimisation prématurée, attention à ne pas tomber dans le you aren't gonna need it (je cause d'expérience ;) ). Tu dis toi-même n'avoir rencontré aucun souci.

Si c'est le cas plus tard, il sera toujours temps pour toi de modifier le système. Tu peux utiliser un realloc, ou déclarer une partie du bloc en statique (si tu n'as jamais besoin de plus de N foos, autant déclarer foo tab[N];). Certes c'est moins flexible mais cette flexibilité (qui a un coût) est-elle pertinente pour ton projet ?

Citation:

Envoyé par sambia39

Vous avez écrit, « Toutes les contraintes d’alignement/offset sont automatiquement prises en charge, c’est un avantage du C par rapport à l’assembleur. » D’accord, mais comment le langage C, peut-il, prendre en charge ces contraintes ?
Comment peut-il gérer les alignements ? Ce n’est pas le travail du compilateur ?
Peut-être que je me trompe (corrigez moi si c’est le cas), il me semble qu’il n’est pas d'avantage du langage C sur l’assembleur. Les compilateurs proposent des options, et des optimisations qui ont pour but d’améliorer les performances et d’ailleurs ce sont les compilateurs qui se chargent de faire tout le travail nécessaire pas le langage C.

Citation:

Envoyé par dalfab

Distinguer le compilateur de langage C du langage C, est d'une subtilité qui me dépasse.

En effet le compilateur étant l'Implémentation du langage C (avec un grand I puisqu'on cause de la définition normalisée du langage), il ne m'a pas paru essentiel de faire la distinction théorique.
16/06/2016, 12h26
boboss123

Faire le choix d'optimiser ou non un code c'est toujours la grande question mais s'il y a des méthodes simples pour le faire autant les utiliser. De manière général, j'essaie d'optimiser mon code lorsque que ça ne demande pas trop de temps supplémentaires en dev (temps de codage + temps de test).
Donc pour résumer :
- Si tableaux de dimensions fixes : utiliser une structure qui englobe tous les tableaux
- Si tableaux de dimensions non fixes : à traiter au cas pas cas (car risque d'erreur élevé. Et possibilité de ne pas détecter le problème => ex: on peut tomber sur le cas où l'alignement par chance est bon et lorsque le l'on recompile suite à un changement du code, que l'alignement n'est plus bon)