Ceci dit, de manière général, il vaut mieux se méfier de ce genre d'optimisation.
Si je ne m'abuse, quand on utilise openMP, c'est souvent parce qu'on ne souhaite pas se plonger dans la complexité d'une parallélisation tout à fait explicite (avec des pthreads ou MPI par exemple). La démarche est donc, globalement, de faire confiance à l'outil automatique openMP + compilo + OS. Se préoccuper de l'allocation physique de la mémoire, est une démarche un peu à l'opposé. Puisqu'il s'agit de ne même pas faire confiances aux mécanismes usuelles de l'OS.
En tout état de cause, il est possible que votre question soit totalement pertinente dans votre cas particulier. Mais on ne saurait trop vous recommander des tests de performance extensifs ; histoire d'éviter de vous échiner sur un faut problème, pour ensuite vous éreinter à corriger des complexités inutilement ajoutées.
Pour étayer mon point de vue, un exemple : dans le noyau, les gens avaient pris l'habitude d'ajouter des instructions spécifiquement destinées à mettre en cache processeur certaines données qui seraient utilisée prochainement. Et l'habitude à vécu de nombreuses années. Jusqu'à ce qu'un jour quelqu'un prenne la peine de se rendre compte que ces instructions, au mieux n'accéléraient rien et qu'elles provoquaient souvent des ralentissements (pour les références conférer l'une des dépêches noyaux de Patrick_G dont le numéro ne me revient pas).
[^] # Re: First touch
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . En réponse au message Allocation de mémoire NUMA dans un code parallèle (threads). Évalué à 3.
Ceci dit, de manière général, il vaut mieux se méfier de ce genre d'optimisation.
Si je ne m'abuse, quand on utilise openMP, c'est souvent parce qu'on ne souhaite pas se plonger dans la complexité d'une parallélisation tout à fait explicite (avec des pthreads ou MPI par exemple). La démarche est donc, globalement, de faire confiance à l'outil automatique openMP + compilo + OS. Se préoccuper de l'allocation physique de la mémoire, est une démarche un peu à l'opposé. Puisqu'il s'agit de ne même pas faire confiances aux mécanismes usuelles de l'OS.
En tout état de cause, il est possible que votre question soit totalement pertinente dans votre cas particulier. Mais on ne saurait trop vous recommander des tests de performance extensifs ; histoire d'éviter de vous échiner sur un faut problème, pour ensuite vous éreinter à corriger des complexités inutilement ajoutées.
Pour étayer mon point de vue, un exemple : dans le noyau, les gens avaient pris l'habitude d'ajouter des instructions spécifiquement destinées à mettre en cache processeur certaines données qui seraient utilisée prochainement. Et l'habitude à vécu de nombreuses années. Jusqu'à ce qu'un jour quelqu'un prenne la peine de se rendre compte que ces instructions, au mieux n'accéléraient rien et qu'elles provoquaient souvent des ralentissements (pour les références conférer l'une des dépêches noyaux de Patrick_G dont le numéro ne me revient pas).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace