Padding et optimisation

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?

Citation:

---

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

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

Code:

---

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.

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.

Citation:

---

Envoy� par Astraya

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.

Citation:

---

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

---

Pour l'alignement

Code:

---

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.

Citation:

---

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

---

Citation:

---

Envoy� par MatRem

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

Code:

---

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.

Citation:

---

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.

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:

---

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

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

Salut,

Citation:

---

Envoy� par 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:

---

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" :P

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

Citation:

---

Envoy� par 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:

---

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.

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:

---

1 2	char c[4]; int i;

---

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

Code:

---

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.

Citation:

---

Envoy� par Jean-Marc.Bourguet

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 :D)

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

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.

Citation:

---

Envoy� par koala01

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

---

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

Citation:

---

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.

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

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

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 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

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).

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

Code:

---

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!
:ccool:

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).

Bonsoir,

Citation:

---

Envoy� par Astraya

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 ?

Citation:

---

Envoy� par MatRem

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.

Citation:

---

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.