Discussion :

[cosmoff]

bonjour à tous,

voila si j'ai

Code :

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

1
2
3
4
5
6
7
8
9
struct A{
    int m_value ;
    char c;
}
 
struct B{
    int m_value;
    char c;
}__attribute__((packed))

B aura une taille de 5 octets alors que la structure de A aura une taille de 8 octets. Le compilateur rajoute des octets de padding mais pourquoi?

sur un pc 64 bits, le bus de donné et de 128 bits, donc on peut recupérer a chaque coup d'horloge jusqu'a 16 octets de mémoire. Donc si mon processus a besoin de récupérer la valeur de m_value quel est l'interet
d'ajouter des octets de padding. ca ne va rien changer car je peux lire facilement mon/mes octets avec ou sans padding. Je pense que mon probleme de compréhesion est plus un probleme hardware que logiciel mais je poste quand meme ici.

Merci d'avance pour votre aide

[dalfab]

Bonjour,

La réponse dépend du processeur que tu utilises.
Pour la plupart des processeurs, tel qu'il ont été câblés ils ne peuvent accéder aux données que si elles sont alignées. Ainsi un nombre entier sur 4 octets n'est directement lisible que si sont adresse est un multiple de 4. D'où la nécessité d'agrandir la structure pour garantir que l'entier est toujours à une adresse multiple de 4.
Et plus le bus est large, plus ceci devient un problème pour le processeur, donc tous les processeurs 64 bits ont forcément le problème.

Si on prend la structure "packed", l'entier ne sera pas aligné donc sera illisible tel quel par la processeur. Tous les accès à cet entier se feront en effectuant 4 lectures d'octets puis un regroupement (le compilateur se charge d'ajouter les instructions assembleurs nécessaires). Conséquences : un code plus gros et un temps d'accès au donnes multipliés par 3 environ!
D'où ne jamais jamais utiliser de structure "packed"' à moins d'avoir une très bonne raison.

[cosmoff]

pourtant si je fais ca :

Code :

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

1
2
3
4
5
struct B b;
b.m_value = 12;
b.c = 'f';
 
	printf("m_value = %i, char = %c\n", b.m_value, b.c);

le terminal me retourne bien les bonnes valeurs

[dalfab]

pourtant si je fais ca :

Code :

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

1
2
3
4
5
struct B b;
b.m_value = 12;
b.c = 'f';
 
	printf("m_value = %i, char = %c\n", b.m_value, b.c);

le terminal me retourne bien les bonnes valeurs

Oui car

Si on prend la structure "packed", l'entier ne sera pas aligné donc sera illisible tel quel par la processeur. Tous les accès à cet entier se feront en effectuant 4 lectures d'octets puis un regroupement (le compilateur se charge d'ajouter les instructions assembleurs nécessaires)

Le code généré va se tordre pour extraire b.m_value et le printf va bien recevoir le nombre entier attendu en paramètre.

[Sve@r]

Bonjour

Le compilateur rajoute des octets de padding mais pourquoi?

Il y a aussi une histoire de tableaux.
Si tu crées un tableau de "struct X", (ex struct X tab[10000]), les accès à tab[n] seront plus rapides si "struct X" a une taille d'une puissance de 2 (2, 4, 8, 16, 32, 64, 128, ...)

[gerald3d]

Bonjour

Il y a aussi une histoire de tableaux.
Si tu crées un tableau de "struct X", (ex struct X tab[10000]), les accès à tab[n] seront plus rapides si "struct X" a une taille d'une puissance de 2 (2, 4, 8, 16, 32, 64, 128, ...)

Bonjour.

Je m’immisce dans la conversation 😁.

Une espèce d’intuition me vient mais je sens que je suis dans l’erreur. Je pose donc ma question.

L'accès aux données en lecture ne serait-il pas plus rapide avec une liste chaînée plutôt qu’avec un simple tableau ?

Je me dis que côté assembleur il doit être plus rapide d’accéder à une donnée en lui donnant directement l’adresse plutôt que de faire des regroupements d’octets...

[sambia39]

Bonsoir,

Si on prend la structure "packed", l'entier ne sera pas aligné donc sera illisible tel quel par la processeur. Tous les accès à cet entier se feront en effectuant 4 lectures d'octets puis un regroupement (le compilateur se charge d'ajouter les instructions assembleurs nécessaires). Conséquences : un code plus gros et un temps d'accès au donnes multipliés par 3 environ!
D'où ne jamais jamais utiliser de structure "packed"' à moins d'avoir une très bonne raison.

Attention ce n'est pas l'entier qui est illisible ou qui le devient, c'est l'adresse mémoire qui devient invalide, car effectivement, sur certaines architectures, on a besoin des adresses alignées cas contraire, cela se solde par une "erreur bus" tel est le cas avec des architectures telles que SPARC qui ne gère pas des adresses impaires contrairement à des architectures hybrides ou ceux de la famille Intel.

à bientôt

[foetus]

L'accès aux données en lecture ne serait-il pas plus rapide avec une liste chaînée plutôt qu’avec un simple tableau ?

Moi je dirais non voire un tableau c'est mieux

Parce qu'un tableau c'est techniquement une adresse plus un décalage. Et une addition coûte moins en temps qu'un déférencement.
L'avantage du tableau, c'est que lorsque le processeur va lire une valeur dans ton tableau, il va mettre en cache une partie du tableau. Donc les lectures contiguës vont coûter cacahuète.

Mais bon ce sont les avantages et les inconvénients des structures de données connus depuis 15-20 ans : rien de neuf

[Médinoc]

Il y a aussi des considérations pour la synchronisation: Sous Windows sur x64, une lecture ou écriture n'est atomique que sur un entier correctement aligné, et les opérations atomiques comme InterlockedIncrement() nécessitent également que la variable soit alignée.
Il est possible que cela soit lié à la pagination mémoire: Un entier non-aligné risque de se retrouver à cheval sur deux pages de mémoire, ce qu'un entier aligné évite.