J'ai lu des articles et donc des réponses sur la manière dont nous pouvons couper le compilateur supplémentaire supplémentaire si nous mettons la configuration des structures dans l'ordre décroissant de la taille des champs indépendants.
par exemple: au lieu de mettre en place (l1) la structure comme celle-ci < / p> créer la mise en page (L2) comme ceci Ma question ici est, existe-t-il des scénarios où la mise en page L2 a des descentes Par rapport à L1 ou à toute autre mise en page? Ou puis-je le prendre dans mes règles de conception pour toujours utiliser L2? Est également la règle d'alignement naturel toujours vrai pour les types primitifs?
3 Réponses :
Vous devez vous émerveiller à propos de la taille de l'alignement / de la structure uniquement si vous utilisez un système à la mémoire contrainte (vous souhaitez limiter la taille de chaque élément). Cela n'a aucun sens que pour les systèmes / conceptions où vous savez que vous stockerez beaucoup de telles structures et que l'espace de stockage utilisé est un problème. D'autre part, regrouper le contenu d'une structure peut logiquement apporter une clarté à votre code. Je favoriserais toujours la clarté contre la performance, en particulier aux premières phases de conception. Encore plus si vous n'avez pas de contraintes liées à la performance.
À propos de la performance Il pourrait arriver que l'accès au contenu "aléatoire" de L2 soit pire que de L1, car les contraintes d'alignement du cache de mémoire peuvent également entrer en jeu. (par exemple, l'accès dans une rangée 2 éléments de la structure L1 peut être plus lent ou plus rapide que 2 éléments de L2). Pour une telle optimisation, le profilage est le seul moyen de savoir quelle mise en page est la meilleure.
Merci pour la perspective sur la clarté. Je travaille sur des systèmes avec des contraintes de mémoire et j'ai donc dû poser cette question. En ce qui concerne la mise en cache, je ne suis pas sûr de si j'ai eu votre point. Voulez-vous dire des cas où un objet de L1 ou L2 dépasse une ligne de cache et affecte les performances dues à l'accès du champ en dehors de la ligne?
Salut. Oui, en fonction de l'alignement de la structure elle-même et de sa propre taille contre la taille de la ligne de cache (correspond à une ligne de cache?) L'accès à 2 éléments d'affilée peut avoir une pénalité de cache ou non en fonction de leur "distance" respective dans le cache ligne. Il sera avantageux d'avoir votre structure adaptée à une ligne de cache chaque fois que cela est possible.
Ma question ici est, existe-t-il des scénarios où layouche L2 a des descentes par rapport à L1 ou à toute autre mise en page?
Parfois, vous devez avoir des membres dans un ordre différent. Les raisons pour cela peuvent inclure:
- La structure fait partie d'un protocole de communication et doit être envoyé octet-octet sur un réseau ou un autre dispositif de communication. Dans ce cas, la disposition de la structure peut être dictée par le protocole et vous devrez le faire correspondre exactement (y compris le remplissage ou l'absence de celui-ci).
- La structure fait partie d'une famille de structures partageant des séquences initiales de membres, de sorte que ces membres doivent être placés en premier. Cela est parfois fait pour permettre des structures d'être traitées de manière «générique» en opérant uniquement sur ces membres initiaux.
- La structure comprend un tampon dont la longueur varie (en étant allouée de manière dynamique en fonction des besoins qui surviennent pendant l'exécution du programme). Un tel tampon est mis en œuvre avec un organe flexible, qui doit être le dernier élément de la structure.
En outre, il peut y avoir des effets accessoires de la manière dont les membres sont commandés. Par exemple, si membre
x devrait être utilisé beaucoup plus fréquemment que d'autres membres de la structure, le mettre à l'avant peut permettre au compilateur d'y accéder avec une adresse plus simple, de l'arithmétique, car sa compensation depuis le début de la structure sera zéro. C'est rarement une considération dans la programmation, mais je le mentionne pour l'exhaustivité.Outre de telles considérations, vous êtes généralement libre de commander des membres comme vous le souhaitez.
est également la règle d'alignement naturel
alignement naturel = taille de (t) toujours vrai pour les types primitifs?non. À titre d'exemple, un
long peut avoir un alignement d'un alignement d'un, deux, quatre ou huit octets.... Nous pouvons couper le compilateur supplémentaire supplémentaire si nous mettons la configuration des structures dans l'ordre décroissant de la taille des champs indépendants.
Ce n'est pas vrai pour les membres qui sont des agrégats (tableaux, structures et syndicats). Considérez qu'un membre
CHAR X [13]; est de 13 octets de taille mais nécessite uniquement l'alignement d'un octet. Pour minimiser le rembourrage, commandez des membres par ordre de diminution des besoins d'alignement, ne pas diminuer la taille.
"Commandez des membres par ordre de diminution des besoins d'alignement, sans diminution de la taille". Merci Eric. C'est logique
IMO abstrait des détails de la mise en œuvre telles que la mise en cache (trop large pour être discuté dans la réponse postale) Il n'y a pas de différence.
La différence est si vous placez l'objet de taille variable (ou de taille zéro) à la fin. de la structure (exemple): Si la commande de membre logique (et l'emballage potentiel) est requise si la structure stocke certaines données binaires reçues (par exemple, en-tête de paquets de communication)
C & C ++ sont des langues distinctes et des structures en C est quelque chose de différent de celui de C ++. En C ++, la structure est généralisée en classe. Choisissez votre langue.
Je parlais de c pov. Cependant, je crois que l'alignement et le rembourrage s'appliquent toujours aux structures et aux classes C ++ pour les variables des membres?
@Rohitmat - Oui, l'alignement et le rembourrage sont applicables aux types de struct et de classe C ++. Cependant, le contrôle d'accès entre en jeu et peut affecter l'ordre des membres et donc le rembourrage. Tellement bonne pratique en C ++ - toutefois qui est mesurée - peut être différente de la bonne pratique dans C. Si vous parlez d'un C pov, je suggère donc de supprimer la balise C ++.
@Peter, je vais supprimer la balise. Merci
@P__J__ Un
struct valide en C aura généralement la même présentation de la mémoire lors de la compilation de C ++.