Discussion :

[Astraya]

Bonjour à tous,

Je me penchais sur ce qu'on appel le padding. J'aurais aimé savoir si cette affirmation était vrai et si elle l'ai, pourquoi 128bytes? est-ce la taille d'un bus afin d'optimiser les transferts de données?

Arrange the member variables of classes and structures in such a way that the most used variables are in the first 128 bytes, and then sorted from the longest object to the shortest.

Voila, je vous remercie.
Avez vous sinon des sources expliquant ceci avec des exemples c++?

Merci

[MatRem]

C'est marrant d'utiliser un axiome de la sorte surtout en l'argumentant avec ça :

Code :

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

On some processors, the addressing of a member is more efficient if its distance from the beginning of the structure is less than 128 bytes.

Pour combien de processeurs (lesquels serait intéressant) est ce vrai.
Et est ce qu'il existe des processeurs pour lequel c'est faux ? .

Pour faire ce genre d'optimization, à mon avis, il faut un peu connaitre le matériel sur lequel le code va tourner.

[Joel F]

Ca sent le caca. Ce qui reste vrai c'ets qu'il faut jouer sur le padding des membres pour eviter des trous qui font gonfler outrageusement le sizeof de l'objet.

[Jean-Marc.Bourguet]

Je me penchais sur ce qu'on appel le padding

C'est l'introduction d'un espace inutilisé entre deux champs. La raison est qu'il est plus efficace d'accéder à des données alignées (càd dont l'adresse modulo la taille est 0) et sur certains processeurs il faut générer du code spécial sinon on se prend une interruption.

Avez vous sinon des sources expliquant ceci avec des exemples c++?

Pour l'alignement

Code :

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

1
2
3
 
struct NA { char c1; double d; char c2; int i };
struct AL { double d; int i; char c1; char c2 };

AL n'a vraisemblablement pas de padding entre les membres et 2 bytes de padding à la fin.
NA a vraisemblablement 7 bytes de padding entre c1 et d et 3 bytes de padding entre c2 et i mais pas de padding à la fin.

J'aurais aimé savoir si cette affirmation était vrai et si elle l'ai, pourquoi 128bytes?

C'est marrant d'utiliser un axiome de la sorte surtout en l'argumentant avec ça :

Code :

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

On some processors, the addressing of a member is more efficient if its distance from the beginning of the structure is less than 128 bytes.

Pour combien de processeurs (lesquels serait intéressant) est ce vrai.
Et est ce qu'il existe des processeurs pour lequel c'est faux ? .

Il y a au moins deux aspects pouvant être à l'origine de cette recommandation:
- mettre ensemble les données souvent utilisées ensemble de sorte qu'elle se retrouve sur la même ligne de cache -- ce qui suppose qu'elles soient correctement alignée par rapport à la taille d'une ligne de cache -- permet à la fois de s'assurer que l'accès à la première chargera les autres dans le cache. Ca diminue aussi la pression sur le cache en évitant de mettre dans celui-ci des données inutiles. C'est vraisemblablement la cause des améliorations qu'on pourrait observer en appliquant le conseil sur des processeurs modernes.
- l'accès à des membres de structure se fait avec des instructions adressant la mémoire sous forme adresse de base dans un registre + déplacement à partir de cette adresse. Certains processeurs ont plusieurs codages pour le déplacement suivant la taille de celui-ci. Ne pas utiliser un encodage plus long du déplacement ou surtout ne pas devoir faire le calcul parce qu'il n'y a pas moyen d'encoder le déplacement peut aussi offrir un avantage en rapidité d'exécution. Le 127 provient vraisemblablement d'un processeur permettant de coder le déplacement sur un octet interprété comme un entier signé (x86 est un candidat). Je ne suis pas sûr que l'effet soit important sur des processeurs modernes, mais sur un 8086 ou un 8086 sur lequel le temps d'exécution est quasiment proportionnel au temps d'accès à la mémoire pour récupérer le programme et les données, l'effet a pu être important.

Pour faire ce genre d'optimization, à mon avis, il faut un peu connaitre le matériel sur lequel le code va tourner.

Garder ensemble ce qui est utilisé ensemble, séparer ce qui n'est pas utilisé ensemble -- encore plus si ça peut être utilisé simultanément par des threads différentes -- c'est utile en général. Les détails permettant de savoir ce qu'est "ensemble" ou "séparé", ça va dépendre effectivement pas mal du matériel.

[Astraya]

Merci pour vos réponses.

Je ne sais pas trop ce que fait le compilo ou le processeur lorsque qu'il vas utiliser les structures d'exemples de Jean-Marc Bourguet

Code :

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

1
2
struct NA { char c1; double d; char c2; int i }; 
struct AL { double d; int i; char c1; char c2 };

Ce que je ne comprend pas, sur NA, c'est pourquoi 7 bytes entre c1 et d? pkoi pas 3?
Et pourquoi il met 3 bytes après c2 et pas c1,c2 puis 3 bytes?En analysant j'ai l'impression qu'il remplit des blocs de 8 bytes? pourquoi pas 4?

Merci

[Joel F]

Chaque membre doit avoir une addresse alignée sur la taille de son type.

[koala01]

Salut,

Merci pour vos réponses.

Je ne sais pas trop ce que fait le compilo ou le processeur lorsque qu'il vas utiliser les structures d'exemples de Jean-Marc Bourguet

Code :

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

1
2
struct NA { char c1; double d; char c2; int i }; 
struct AL { double d; int[ i; char c1; char c2 };

Ce que je ne comprend pas, sur NA, c'est pourquoi 7 bytes entre c1 et d? pkoi pas 3?
Et pourquoi il met 3 bytes après c2 et pas c1,c2 puis 3 bytes?
En analysant j'ai l'impression qu'il remplit des blocs de 8 bytes? pourquoi pas 4?

Merci

Les adresses mémoires représentent des éléments d'une taille suffisante pour remplir les différents acumulateurs du processeur.

On ne peut en effet pas courir le risque de voir les données qui sont représenter aux différentes adresses se "chevaucher"

Il est donc "logique", lorsque toute l'architecture est en 64 bits, que le padding se fasse... sur 64 bits

[Jean-Marc.Bourguet]

Merci pour vos réponses.

Je ne sais pas trop ce que fait le compilo ou le processeur lorsque qu'il vas utiliser les structures d'exemples de Jean-Marc Bourguet

Code :

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

1
2
struct NA { char c1; double d; char c2; int i }; 
struct AL { double d; int i; char c1; char c2 };

Ce que je ne comprend pas, sur NA, c'est pourquoi 7 bytes entre c1 et d? pkoi pas 3?
Et pourquoi il met 3 bytes après c2 et pas c1,c2 puis 3 bytes?
En analysant j'ai l'impression qu'il remplit des blocs de 8 bytes? pourquoi pas 4?

En C et en C++, le compilateur ne peut pas reordonner les champs lui-meme (en C++, il peut reordonner les sections entre private:, protected: et public: mais pas les champs a l'interieur d'une section, je n'ai pas connaissance d'un compilateur qui le fasse).

J'ai pris l'hypothese (qui est le cas de quasiment toutes les archi 32 bits) ou l'alignement d'un char est le byte, d'un double est 8 bytes, d'un int 4 bytes. Cad que les adresses doivent etre un multiple de ces valeurs (c'est au moins plus efficace de faire ainsi, parfois c'est impose par le proc qui genere une exception ou fait des choses plus ou moins bizarres -- certains ignorent les bits de poids faibles de l'adresse p.e. -- quand ce n'est pas le cas).

Donc c1 a l'offset 0.
d a un offset multiple de 8 superieur a 0, donc c'est 8, laissant 7 bytes inutilises.
c1 a un offset superieur a 8, donc c'est 9.
i a un offset multiple de 4, superieur a 9, donc c'est 12 laissant 3 bytes inutilises.

La taille totale doit etre un multiple de l'alignement le plus fort (8 ici). 16 est bien un multiple donc il n'y a pas de padding a la fin.

[Astraya]

Ok je vous remercie pour tout ces détails.
Donc à ce que j'ai pu comprendre, le padding dépendra de l'architecture 32 ou 64 bits et fera en conséquence.

Une dernière chose, et dite moi si je me trompe, sur 32 bits par exemple, on devras mettre le maximum de données du même type pour qu'il puisse les aligner sur un même mot mémoire. Donc , sur une architecture 32 bits, nous n'aurons pas de padding, si on déclare :

Code :

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

1
2
char c[4];
int i;

Mais nous aurons 3 bytes de padding avant l'entier i si on déclare :

Code :

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

1
2
char c[5];
int i;

Excuser moi encore, je ne connais pas trop le fonctionnement à ce niveau qui me semble tout même très important. Je dispose juste de vague notion lointaine au temps du lycée ^^

Je vous remercie.

[koala01]

En C et en C++, le compilateur ne peut pas reordonner les champs lui-meme (en C++, il peut reordonner les sections entre private:, protected: et public: mais pas les champs a l'interieur d'une section, je n'ai pas connaissance d'un compilateur qui le fasse).

J'ai pris l'hypothese (qui est le cas de quasiment toutes les archi 32 bits) ou l'alignement d'un char est le byte, d'un double est 8 bytes, d'un int 4 bytes. Cad que les adresses doivent etre un multiple de ces valeurs (c'est au moins plus efficace de faire ainsi, parfois c'est impose par le proc qui genere une exception ou fait des choses plus ou moins bizarres -- certains ignorent les bits de poids faibles de l'adresse p.e. -- quand ce n'est pas le cas).

Donc c1 a l'offset 0.
d a un offset multiple de 8 superieur a 0, donc c'est 8, laissant 7 bytes inutilises.
c1 a un offset superieur a 8, donc c'est 9.
i a un offset multiple de 4, superieur a 9, donc c'est 12 laissant 3 bytes inutilises.

La taille totale doit etre un multiple de l'alignement le plus fort (8 ici). 16 est bien un multiple donc il n'y a pas de padding a la fin.

En fait, sur un PC 32 bits, le pading est de ... 4 bytes (car, il en faut 4 pour arriver à nos 32 bits )

Par contre, je n'avais pas réagi aux 8 bytes essentiellement parce que le pading est, effectivement, de 8 sur les architecture 64 bits, avec application compilées comme telles

[Astraya]

Ok merci beaucoup tout le monde.

Il pourrait être intéressant de mettre des informations sur le padding dans un faq ou tutoriel d'optimisation en c++. Ainsi que divers autres techniques bête mais auxquelles on ne porte pas forcement attention sans expérience.

[Jean-Marc.Bourguet]

En fait, sur un PC 32 bits, le pading est de ... 4 bytes (car, il en faut 4 pour arriver à nos 32 bits )

La taille sans padding fait 16 bytes, il n'y a pas besoin de padding a la fin.

Par contre, je n'avais pas réagi aux 8 bytes essentiellement parce que le pading est, effectivement, de 8 sur les architecture 64 bits, avec application compilées comme telles

Je ne comprends pas ce que tu as ecrit. Si tu as mis padding pour alignement, tu oublies que l'alignement depend des donnees. De plus en C et en C++, il n'est pas possible d'avoir comme alignement autre chose qu'un diviseur de la taille. Or sur la plupart des implementations 64 bits, les int font quand meme 32 bits; ils seront donc alignes sur 32 bits.

[MatRem]

Un petit article à propos de l'alignement et du padding :
http://virtrev.blogspot.com/2010/09/...-examples.html

[Astraya]

Je reviens avec un peu de code de test que voici:

Code :

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

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
41
42
43
44
45
46
47
48
49
50
51
52
#include <iostream>
#include <conio.h>
 
using std::cout;
using std::endl;
 
struct SWorst // 24 bytes
{
    int i;    //4 bytes
    char c;   //1 bytes + 3 bytes for padding
    double d; //8 bytes
    char c2;  //1 bytes + 7 bytes for padding
};
 
struct SBest //16 bytes
{
    double d; //8bytes
    int i;    //4 bytes
    char c;   //1 bytes
    char c2;  //1 bytes + 2 bytes for padding
};
 
struct BadSWorstAndSBest //64 bytes
{
    char c; // 1 bytes + 7 bytes for padding
    SWorst sw; // 24 bytes
    char c1; // 1 bytes + 7 bytes for padding
    SBest sb; //16 bytes
    char c2; //1 bytes + 7 bytes for padding
};
 
struct GoodSWorstAndSBest //48 bytes
{
 
    SWorst sw; // 24 bytes
    SBest sb;  // 16 bytes
    char c;    // 1 bytes 
    char c1;   // 1 bytes 
    char c2;   // 1 bytes + 5 bytes for padding
 
};
 
 
int main()
{
    cout << " SWorst " << sizeof(SWorst) << endl;
    cout << " SBest " << sizeof(SBest) << endl;
    cout << " BadSWorstAndSBest " << sizeof(BadSWorstAndSBest) << endl;
    cout << " GoodSWorstAndSBest " << sizeof(GoodSWorstAndSBest) << endl;
 
    _getch();
}

Donc jusque la j'ai compris le principe sauf une chose.
Apparemment, un int suivit d'un char est mis sur le même mot mémoire, mais ce ne sont pas les même types. Une explication à ça? Existe-t-il une "hiérarchie" au niveau des types disant que un char pourrais être un int mais pas l'inverse?
A moins que j'ai fait un erreur au niveau du padding.

Merci

[Jean-Marc.Bourguet]

Il n'y a pas une notion de mot memoire tres forte sur un x86. Ce qui compte c'est que les adresses soient des multiples de l'alignement (et celui-ci c'est la taille pour les types de bases, long double sur 10 bytes excepte).

[Astraya]

Ok merci, ceci explique que la struct suivante soit de 16 bytes.

Code :

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

1
2
3
4
5
6
7
struct Test
{
    double d;
    int i;
    short s;
    char c[2];
};

Merci beaucoup pour ces explications fortes utiles!

[ac_wingless]

Les règles d'alignement peuvent varier légèrement entre membres d'une même famille de circuits (par exemple, pour les microprocesseurs, on doit souvent aligner les données sur des multiples exacts de leur taille, avec pour certains des relaxations de contraintes si on accepte de la latence, comme les modes segmentés des anciens x86).

En revanche, entre familles d'appareils, on peut avoir de grosses surprises. Par exemple, il existe des processeurs qui n'acceptent que des alignements fixes de 256 bits. Si on veut lire un caractère, on lit 32 octets de toute façon. Parfois, on n'a même pas de mémoire réellement présente sur la fin. Par exemple sur un projet récent, nous avions deux banques de 960 bits réels, décalés de 1024 bits, et alignés tous les 2048 (disposition classique en full HD). Quand on programme pour ce genre de système embarqué, on doit pas mal changer ses habitudes, mais c'est clairement documenté et bien connu.

Ce qui l'est moins, et peut poser des problèmes, c'est quand on doit transférer des données sur un bus. Si le protocole est conçu par un programmeur ayant grandi sur PC, on est sûr de se prendre tôt ou tard de la latence pour de mauvaises raisons.

Pour en revenir au conseil initial, c'est une très bonne base. Mais il ne faut pas trop s'inquiéter et aller plus loin: les systèmes pour lesquels l'alignement est significativement différent de ceux des microprocesseurs sont souvent très spécialisés, et la question ne se pose pas vraiment en termes de types C++ (float, int64 etc.), mais plutôt en termes d'interface VHDL. Après 26 ans de carrière en informatique embarquée, je ne connais pas d'exemple de processeur capable de traiter nativement un nombre à virgule flottante et en même temps nécessitant des alignements supérieurs à 64 bits (ça ne veut pas dire qu'il n'y en a pas, mais que si un jour vous en rencontrez un, vous pouvez être sûr que la doc va allouer 25 pages en rouge rien que sur ce problème).

[Obsidian]

Bonsoir,

Je me penchais sur ce qu'on appel le padding. J'aurais aimé savoir si cette affirmation était vrai et si elle l'ai, pourquoi 128bytes? est-ce la taille d'un bus afin d'optimiser les transferts de données?

Non, « padding » est un terme général et l'affirmation en question dépend beaucoup du compilateur dont la doc contient l'info que tu as extraite. On peut savoir sur quelle machine tu travailles ?

Pour combien de processeurs (lesquels serait intéressant) est ce vrai. Et est ce qu'il existe des processeurs pour lequel c'est faux ? . Pour faire ce genre d'optimization, à mon avis, il faut un peu connaitre le matériel sur lequel le code va tourner.

Ça doit être inutile dans la plupart des cas mais, sur 6809 par exemple, l'adressage se faisait sur 16 bits, mais il existait un mode d'adressage spécial (dit « direct ») dans lequel on plaçait les 8 bits de poids fort dans un registre spécial (« DP : Direct Page ») pour ne passer ensuite que l'octet de poids faible de l'adresse à pointer dans le code opération.

Sur un 8 bits, on stockait beaucoup de choses en 256 octets. La quasi-totalité des variables de fonctionnement du BASIC 512 de mon TO8D y tenait, et ça permettait de gagner entre 15 et 30% d'espace dans la ROM du logiciel, ce qui n'était pas négligeable. L'interpréteur et tout le backend système, puisque le BASIC servait souvent d'OS sur ces machines tenait dans 2×16Kio. Autant dire que le tout y était rentré au chausse-pied.

Donc, ce genre de considération doit encore être vrai sur les micro-contrôleurs. Maintenant, il n'y a pas de raison a priori que ce soit 128 octets en particulier. Ça dépend effectivement de la puce que tu utilises.

[Astraya]

Non, « padding » est un terme général et l'affirmation en question dépend beaucoup du compilateur dont la doc contient l'info que tu as extraite. On peut savoir sur quelle machine tu travailles ?

Un dell inspiron core 2 duo, Windows 7 64bits. La compilation est sous visual studio 2010x64 en 32 bits et non 64.