operator new et problemes d'alignement memoire + multithreading

Bonjour,

Je suis en train de decouvrir l'ecriture de ses propres operator new et delete sur la base de "Efficient C++: Performance Programming Techniques". A terme, c'est pour servir dans un code de calcul qui tournera sur differents types de machines paralleles, utilisant MPI et a terme OpenMP en plus. J'ai deux "petites" questions :

1) les auteurs proposent, pour ds objets de taille constante, de reserver une taille memoire grace a sizeof(objet) mais ils ne disent rien des problemes d'alignement en memoire : est-ce que la taille calculee par sizeof a de fait le bon gout de fournir des objets correctement alignes ? sinon, j'imagine qu'on peut perdre du temps au lieu d'en gagner...
2) A quoi convient-il d'etre attentif pour developper un code compatible OpenMP ? Notamment, y a-t-il des risques si on reserve un morceau de memoire et que differents bouts du calcul OpenMP creent/detruisent dans la meme zone ? Est-ce seulement le cas ? Je ne connais pas du tout OpenMP pour le moment, mais il serait bon de ne pas trop se planter a ce stade histoire de ne pas avoir a tout reecrire quand on s'y mettra... d'ou mon appel a l'aide

Merci beaucoup :)

Hugo

Citation:

---

1) les auteurs proposent, pour ds objets de taille constante, de reserver une taille memoire grace a sizeof(objet) mais ils ne disent rien des problemes d'alignement en memoire : est-ce que la taille calculee par sizeof a de fait le bon gout de fournir des objets correctement alignes ? sinon, j'imagine qu'on peut perdre du temps au lieu d'en gagner...

---

Non, ça ne dépend que de la fonction d'allocation elle-même. Sous Windows, malloc() aligne automatiquement sur 16 octets, ce qui est généralement suffisant pour tout.
VirtualAlloc(), par contre, aligne sur 64 ko (ou plus précisément, sur SYSTEM_INFO::dwAllocationGranularity).

Ensuite, si tes objets font 8 octets ou moins, c'est là qu'il devient avantageux d'en allouer tout un tableau plutôt que les allouer un par un.

Bonjour Medinoc,

Un grand merci pour ta reponse !!! Je vois que je dois preciser un peu : mes objets font de fait plus de 8 octets, et les calculs seront en 64 bit (est-ce que cela affecte les affaires ?) et en environnement unix/linux. Le truc c'est que ce sont des objets assez "volatiles" (creation/destruction frequentes) d'ou mon desir de gagner du temps en ecrivant op new et delete... je devine que je vais devoir plonger un peu plus dans la doc et je reviendrai avec des questions... Merci en tout cas :)

Hugo

Bonjour,

Citation:

---

Envoyé par [Hugo]

1) les auteurs proposent, pour ds objets de taille constante, de reserver une taille memoire grace a sizeof(objet) mais ils ne disent rien des problemes d'alignement en memoire : est-ce que la taille calculee par sizeof a de fait le bon gout de fournir des objets correctement alignes ?

---

sizeof te renvoie la taille d'un objet telle que l'a décidé le compilateur. C'est au minimum la taille de toutes tes variables membres + la vtable etc.. (bref, tout ce qui constitue ton instance en mémoire), et il peut aussi y avoir un peu de padding pour améliorer l'alignement mémoire : ça dépend entièrement de ton compilateur. Mon intuition me dit qu'il aligne sur la taille des mots mémoire de la machine (32 bits), mais je me trompe certainement.
Ce qui est sûr, c'est que tu peux plus ou moins contrôler cela via des extensions du type #pragma pack, mais... je ne pense pas que ce soit la solution la plus intelligente.

A mon avis, tu devrais jeter un oeil à des solution du type boost pool :
http://www.boost.org/doc/libs/1_39_0...doc/index.html

Citation:

---

Envoyé par Médinoc

Sous Windows, malloc() aligne automatiquement sur 16 octets, ce qui est généralement suffisant pour tout.

---

malloc est implémentée par le compilo C/C++, donc c'est spécifique à chaque (version de) compilateur et pas vraiment lié à Windows.

Citation:

---

Envoyé par Médinoc

VirtualAlloc(), par contre, aligne sur 64 ko (ou plus précisément, sur SYSTEM_INFO::dwAllocationGranularity).

---

Tu fais bien de le mentionner. VirtualAlloc est la fonction système de base de gestion mémoire sous Windows et ne devrait pratiquement jamais être utilisée. Il y a tout une "pile" d'autres fonctions bâties les unes sur les autres qui offrent une gestion mémoire perso : VirtualAlloc -> HeapAlloc (tas Win32) -> malloc (tas C) -> new (tas C++) -> boost pool / conteneurs STL / etc...

Citation:

---

Envoyé par [Hugo]

Le truc c'est que ce sont des objets assez "volatiles" (creation/destruction frequentes) d'ou mon desir de gagner du temps en ecrivant op new et delete...

---

En fait, ce sont les appels à new/delete qui sont très couteux, car derrière il y a des algorithmes complexes de gestion de l'espace libre pour "caser" ton nouvel objet, c'est une première cause de lenteur. Il y a aussi l'aspect dégradation des performances à cause de la fragmentation mémoire (particulièrement vrai si tes objets ont des durées de vies très aléatoires). Donc l'idéal est de ne pas appeler new/delete du tout, mais plutôt d'allouer un gros tableau que tu gères à la main pour caser tes objets comme l'a dit Médinoc. C'est grosso-modo le fonctionnement de boost pool, ce qui t'évite de coder tout ça !

Sous Linux, généralement, malloc (ou operator new) alloue sur un alignement de 8 octets. (ce qui n'est pas suffisant pour faire du SIMD)
C'est à l'algorithme d'allocation de déterminer l'alignement de ses allocations. (plus l'alignement étant grand, plus il y a de potentiel de gaspillage)

Citation:

---

Envoyé par Aurelien.Regat-Barrel

malloc est implémentée par le compilo C/C++, donc c'est spécifique à chaque (version de) compilateur et pas vraiment lié à Windows.

---

Sauf que je ne connais pas de compilateur dédié à Windows qui n'utilise pas MSVCR*.DLL (à part Visual quand on compile en statique)

Sinon, la CRT de Microsoft propose également _aligned_malloc() et _aligned_offset_malloc(), qui peuvent s'avérer utiles.

Citation:

---

Envoyé par Médinoc

Sinon, la CRT de Microsoft propose également _aligned_malloc() et _aligned_offset_malloc(), qui peuvent s'avérer utiles.

---

Je connaissais pas... intéressant !

Bonjour,

Merci a tous pour vos reponses !!! Je vais editer tout cela des la semaine prochaine (je finis mes vacances d'abord ;) ). boost:pool a l'air effectivement bien sympa !

Merci encore :)

Hugo