Je suppose que même la lecture de données partagées dans OpenMP entraîne des frais généraux parallèles, en fonction de l'architecture du processeur (si différents cœurs ont leur propre cache ...) Il peut être nécessaire de rafraîchir le cache de s'assurer qu'aucun autre CPU a modifié les données avant de lire.
Ai-je raison de penser cela?
Si tel est le cas, existe-t-il un moyen de dire OpenMP (sur le compilateur Intel FWIW) que certaines des données partagées sont constantes, de sorte que ce rafraîchissement de cache n'est pas nécessaire?
Si la réponse est C ++ mise à jour
ah, ok. Je me souviens maintenant d'où j'ai eu mon impression que Comme cela se produit, cela n'est pas pertinent dans ma propre situation - de grandes matrices et des conteneurs STL de données dans lesquels la granularité de lecture / écriture couvrira de nombreuses lignes de cache et qui sont allouées à partir de différents pools de mémoire dans tous les cas. Donc, ceux-ci seront naturellement situés sur différentes lignes de cache. Pas de problème! Const Existe-t-il un moyen facile de transformer les données non constituées dans des données de const, sans réaffecter réellement la mémoire, une fois que le programme a passé un certain point au moment de l'exécution?
const était une bonne chose dans ce contexte: http://www.akkadia.org/drepper/cpumemorory.pdf , section 6.4.1. C'est à faire avec un faux partage, où les variables réadonnées qui partagent des lignes de cache avec des variables Readwrite incrusent la pénalité de la ligne de cache étant marquée exclusive de la variable Readwrite. Le document lié recommande, par exemple avec GCC, de marquer ces Vars comme __ attribut __ ((Section (quelque chose.else))) Pour s'assurer qu'ils sont stockés ailleurs.
3 Réponses :
imprimera par conséquent, ici, le stockage est const n'implique pas que la mémoire est constante. Il implique que votre poignée à cette mémoire ne puisse pas écrire (ce qui est subtilement différent): 4 , même si quand j a été limité à i la valeur était 3 . const ne peut que dire que vous ne doit pas modifier les données sous-jacentes (et le compilateur l'appliquera, à un point). Il ne dit rien des données elles-mêmes, sauf lorsqu'elle est directement appliquée aux données: const , la valeur est immuable. et le compilateur est libre de placer cela dans la ROM.
Partage des données en lecture seule entre plusieurs cœurs n'a pas de frais générale. La même copie des données sera dans le cache pour tous les cœurs qui l'utilisent.
La seule fois que vous encourez des frais généraux, c'est lorsque l'un des noyaux écrit aux données partagées. Dans cette situation, vous encourrez une surcharge (potentiellement grande) car l'écriture invalidera toutes les autres copies de cette ligne de cache et les obligera à la saisir de la mémoire ou d'un cache différent.
En d'autres termes, le cache n'est que "rafraîchi" lorsque quelqu'un change les données. Il n'y a pas de "rafraîchissant" périodique.
La réponse à votre question est donc: vous n'avez rien à faire. Il n'y a aucun moyen de dire OpenMP ou du matériel que les données sont constantes et const n'ayant aucun effet de côté de la syntaxe.
Je pense que vous avez raison. Consultez ma mise à jour de la question pour expliquer où la confusion est venue en premier lieu (faux partage).
Je consultitais également ce sujet et j'ai trouvé une recommandation générale de performance de Oracle:
Si une variable partagée dans une région parallèle est lue par les threads exécuter la région, mais non écrite à aucun des threads, puis Spécifiez cette variable à être préventive au lieu de partagé. Cette évite d'accéder à la variable par la déséroférance d'un pointeur et évite Conflits de cache.
Guide de l'utilisateur OpenMP API Oracle OpenMP - Chapitre 7 - Considérations sur la performance