Pourquoi ne sont pas là des conflits bancaires en mémoire globale pour Cuda / OpenCL?

Question

Une chose que je n'ai pas compris et Google ne me aide, est pourquoi est-il possible d'avoir des conflits bancaires avec mémoire partagée, mais pas dans la mémoire globale? il peut y avoir des conflits bancaires avec les registres?

UPDATE Wow, j'apprécie vraiment les deux réponses de Tibbit et Grizzly. Il semble que je ne peux que donner une coche verte à une réponse bien. Je suis assez nouveau pour dépassement de la pile. Je suppose que je dois choisir une réponse comme le meilleur. Puis-je faire quelque chose à dire merci à la réponse que je ne donne pas un chèque vert?

Answer 1

Réponse courte:. Il n'y a pas de conflits bancaires en soit la mémoire globale ou dans des registres

Explication:

La clé pour comprendre pourquoi de saisir la granularité des opérations. Un seul thread n'a pas accès à la mémoire globale. accès mémoire globaux sont « coalescées ». Étant donné que la mémoire globale est soo lente, tout accès par les fils dans un bloc sont regroupés pour faire aussi peu de demandes à la mémoire globale que possible.

La mémoire partagée peut être accédé par des fils en même temps. Lorsque deux threads tentent d'accéder à une adresse dans la même banque, ce qui provoque un conflit bancaire.

Registres ne peut être consulté par un fil, sauf celle à laquelle elle est affectée. Puisque vous ne pouvez pas lire ou écrire à mes registres, vous ne pouvez pas me empêcher d'y accéder - par conséquent, il n'y a pas de conflits bancaires

.

Qui peut lire et écrire à la mémoire globale?

Only blocks. Un seul fil peut faire un accès, mais la transaction sera traitée au niveau du bloc (en fait le niveau de la chaîne chaîne / moitié, mais j'essaie de ne pas être compliqué). Si deux blocs accèdent à la même mémoire, je ne crois pas que cela va prendre plus de temps et il peut arriver accélérée par le cache L1 dans les nouveaux appareils -. Bien que ce n'est pas évidente en toute transparence

Qui peut lire et écrire à la mémoire partagée?

Any thread within a given block. Si vous avez seulement 1 fil par bloc, vous ne pouvez pas avoir un conflit bancaire, mais vous n'aurez pas des performances raisonnables. les conflits bancaires se produisent parce qu'un bloc est alloué avec plusieurs, disons 512 threads et ils sont tous en lice pour des adresses différentes dans la même banque (pas tout à fait la même adresse). Il y a quelques excellentes photos de ces conflits à la fin du Guide de programmation CUDA C - Figure G2, à la page 167 (en fait la page 177 du pdf). Lien vers la version 3.2

Qui peut lire et écrire sur les registres?

Only the specific thread to which it is allocated. conséquent un seul thread y accède à la fois.

Answer 2

Si oui ou non il peut y avoir des conflits bancaires sur un type de mémoire donnée est évidemment dépendante de la structure de la mémoire et donc de son objet.

Alors pourquoi est-mémoire partagée conçu d'une manière qui permet? Des conflits bancaires

Cest relativement simple, ne est pas facile de concevoir un contrôleur de mémoire qui peut gérer des accès indépendants à la même mémoire simultanément (prouvé par le fait que la plupart ne peuvent pas). Ainsi, afin de permettre à chaque fil dans un halfwarp d'accéder à un mot adressé individualy la mémoire est incliné, avec un contrôleur indépendant pour chaque banque (au moins thats comment on peut y penser, pas sûr du matériel réel). Ces banques sont intercalées pour faire des fils séquentiels un accès rapide mémoire séquentielle. Ainsi, chacune de ces banques peut gérer une demande à un moment permettant idéalement d'exécutions simultanées de toutes les demandes du halfwarp (évidemment ce modèle peut théoriquement soutenir la bande passante plus élevée en raison de l'indépendance de ces banques, ce qui est également un plus).

Qu'en est-il des registres?

Les registres sont conçus pour être accessibles comme opérandes pour les instructions ALU, ce qui signifie qu'ils doivent être accessibles avec une latence très faible. Par conséquent, ils obtiennent plus de transistors / bit pour que cela soit possible. Je ne sais pas exactement comment les registres sont accessibles dans les processeurs modernes (pas le genre d'information que vous avez souvent besoin et pas facile à trouver). Cependant, il serait (voir pour les architectures plus simples que vous généralement tous les registres suspendus sur un grand multiplexeur) évidemment très peu pratique pour organiser des registres dans les banques. Donc non, il n'y aura pas de conflits bancaires pour les registres.

mémoire globale

D'abord la mémoire globale fonctionne sur un autre granuality puis de mémoire partagée. La mémoire est accessible en 32, 64 ou blocs 128byte (pour GT200 atleast, pour fermi il est toujours 128B, mais mises en cache, AMD est un autre bit), où chaque fois que vous voulez quelque chose d'un bloc le bloc entier est accessible / transféré. C'est la raison pour laquelle vous avez besoin accès coalisées, car si chaque thread accède à la mémoire d'un bloc différent, vous devez transférer tous les blocs.

Mais qui dit qu'il n'y a pas de conflits bancaires? Je ne suis pas complètement sûr à ce sujet, parce que je ne l'ai pas trouvé de sources réelles pour soutenir ce pour le matériel NVIDIA, mais il semble logique: La mémoire globale est typiquement distribué à plusieurs puces de RAM (qui peut être facilement vérifié en regardant sur un graphicscard). Il serait logique, si chacun de ces puces est comme une banque de mémoire locale, de sorte que vous obtiendriez les conflits bancaires si plusieurs requêtes simultanées sur la même banque. Cependant, les effets seraient beaucoup moins prononcés pour une chose (puisque la plupart du temps consommé par accès mémoire est le temps d'attente pour obtenir les données de A à B de toute façon), et il ne sera pas un effet noticible « à l'intérieur » d'un groupe de travail (étant donné qu'une seule exécute de halfwarp à la fois et si que les questions de halfwarp plus d'une demande, vous avez un accès à la mémoire uncoalesced, de sorte que vous prenez déjà un coup ce qui rend difficile de mesurer les effets de ce conflit. donc, vous n'obtiendrez des conflits si plusieurs groupes de travail essayer d'accéder à la même banque. dans votre situation typique GPGPU vous avez un grand ensemble de données se trouvant dans la mémoire séquentielle de sorte que les effets ne devraient pas vraiment être noticible car il y a suffisamment d'autres groupes de travail accessinng les autres banques en même temps, mais il devrait être possible de construire des situations où l'ensemble de données est centrée sur quelques banques, qui font un succès de la bande passante (depuis la bande passante maximale proviendrait de la distribution equaly l'accès sur toutes les banques, de sorte que chaque banque serait o nly une fraction de cette largeur de bande). Encore une fois, je ne l'ai pas lu quelque chose à prouver cette théorie pour le matériel de nvidia (tout pour la plupart des concentre sur coalescent, ce qui est évidemment plus important car il fait un des ensembles de données naturelles Faux problème à). Toutefois, selon le calcul gu ATI Streamide c'est la situation pour les cartes Radeon (pour 5xxx: les banques sont en dehors 2kb et que vous voulez vous assurer que vous diffusez vos accès (ce qui signifie de tous worgroups simulateously actifs) equaly sur toutes les banques), donc j'imagine que les cartes NVidia se comportent similairement .

Bien sûr, pour la plupart scenarious la possibilité de conflits bancaires sur la mémoire globale est une question non, dans la pratique, vous pouvez dire:

• Surveillez coalescent lors de l'accès mémoire globale
• Surveillez les conflits bancaires lors de l'accès mémoire locale
• Aucun problème avec accès aux registres

Answer 3

plusieurs threads accédant à la même banque ne signifie pas nécessairement qu'il ya un conflit bancaire. Il y a un conflit si les discussions veulent lire en même temps d'un autre ROW au sein de la même banque.