En fait, je ne suis pas certain qu'il soit vraiment utile « d'allouer » des tableaux par filaments. En général, j'aurais tendance à me contenter d'une seule allocation et de partager ensuite la mémoire. C'est ce qui se fait de plus simple avec openMP. Cette approche présente l'avantage de la simplicité et d'un nombre réduit d'appels systèmes.
Comme signaler plus haut, la mémoire n'est physiquement allouée qu'au moment de son premier remplissage. Du coup on peut s'attendre à ce que les données se retrouvent spontanément proches du cœur qui les traitera. À condition toutefois de bien contrôler le découpage en filament de openMP (il me semble qu'on imagine aisément qu'openMP fait N filaments pour traiter un segment, alors qu'en réalité il en fait au maximum N simultanément et qu'en permanence des filaments naissent vivent et meurent dans l'indifférence générale ;-).
[^] # 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é à 2.
En fait, je ne suis pas certain qu'il soit vraiment utile « d'allouer » des tableaux par filaments. En général, j'aurais tendance à me contenter d'une seule allocation et de partager ensuite la mémoire. C'est ce qui se fait de plus simple avec openMP. Cette approche présente l'avantage de la simplicité et d'un nombre réduit d'appels systèmes.
Comme signaler plus haut, la mémoire n'est physiquement allouée qu'au moment de son premier remplissage. Du coup on peut s'attendre à ce que les données se retrouvent spontanément proches du cœur qui les traitera. À condition toutefois de bien contrôler le découpage en filament de openMP (il me semble qu'on imagine aisément qu'openMP fait N filaments pour traiter un segment, alors qu'en réalité il en fait au maximum N simultanément et qu'en permanence des filaments naissent vivent et meurent dans l'indifférence générale ;-).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace