Étude des temps d’accès aux diverses mémoires et de l’exploitation du parallélisme gros grain sur GPU Nvidia

Étude des temps d’accès aux diverses mémoires et de l’exploitation du parallélisme gros grain sur GPU Nvidia

Dans le chapitre 3, nous avons défini une méthodologie de portage d’algorithmes sur GPU. Celle-ci considère les domaines d’itérations des nids de boucles pour les adapter aux domaines d’instances des GPUs. Cette méthodologie, validée au cours du chapitre 4, est décomposée en plusieurs étapes :Ces diverses optimisations contribuent à l’identification d’une solution de placement qua- litative, réduisant le temps d’exécution de l’algorithme résultant. Mais l’optimisation de code est un sujet très vaste. Le flot de calculs, le flot d’instructions et le flot de données, abordés dans la section 1.3, sont respectivement exploités, au sein des GPUs, par des ressources dédiées telles que :cution des algorithmes placés sur GPU. Nous abordons ainsi, dans ce chapitre, deux en- sembles de mesures expérimentales, préalables à de futures optimisations fines de code pour CUDA, dans le cadre de notre méthodologie, qui améliorent le placement sur les GPUs Nvidia.Cette thèse s’intéressant en particulier aux applications de traitement d’image, nous retrouvons dans ce domaine trois facteurs dont la prise en compte présente une source potentielle d’accélération du temps d’exécution :Nous évaluons ainsi, dans la section 5.1, plusieurs performances des différents espaces mémoire sur GPU pour le premier facteur. Pour les deux derniers, nous étudions, dans la section 5.2, le comportement du GPU lors d’un placement exploitant un parallélisme à gros grain (coarse grained parallelism).

Étude des espaces mémoire sur GPU

Notre méthodologie de placement sur GPU (chapitre 3) spécifie, lors du processus de génération de code (section 3.6), le placement des données sur la global memory. Dans cette section, nous étendons les capacités de notre méthodologie à l’usage des autres espaces mémoires mis à disposition par CUDA.Ces trois mémoires physique sont exploitées, au travers du langage de programmation CUDA, au moyen de sept espaces mémoires. La différence entre ces espaces provient es- sentiellement des différentes méthodes d’accès aux données et plus particuliérement des mémoires caches dédiées. En reprenant la nomenclature issue de la documentation officielle de CUDA [123], ces espaces correspondent à :Nous faisons ainsi la distinction entre les unités de mémoires physiquement présentes sur le GPU des espaces mémoires logiques fournis par CUDA. En complément, CUDA appelle « Host memory », l’espace mémoire du processeur hôte mis à disposition pour le contexte CUDA.L’ensemble des solutions présentées dans l’état de l’art (chapitre 2) propose le place- ment des données en global memory. La local memory et les unités registres sont utilisées de manière implicite par le compilateur NVCC.

De manière générale, les informations sur les modèles de placement mémoire utilisés par les compilateurs sont assez rares et peu détaillées. Nous ne connaissons, de plus, aucune publication portant sur la détermination automatisé de l’espace mémoire le plus adapté à chaque espace de données d’un algorithme donné.Ce constat peut s’expliquer par les modifications architecturales, spécifiques aux mé- moires, apportées à chaque nouvelle génération de GPU chez Nvidia [132, 131, 130, 129, 120]. Les optimisations dans ce domaine sont donc spécifiques à chaque génération. Ces modifications permanentes soulignent le besoin actuel d’améliorer les bandes passantes d’accès aux données, abordé en introduction du chapitre 1.Nous nous intéressons ainsi à la problématique portant sur l’identification de l’espace mémoire minimisant le temps d’accès aux données dans un algorithme. Pour cela, nous synthétisons, dans la section 5.1.1, les caractéristiques de chacun de ces espaces mémoire. Nous établissons ensuite l’objectif de cette expérimentation dans la section 5.1.2 et dé- taillons notre protocole de test dans la section 5.1.3. Enfin, dans la section 5.1.4, nous analysons les performances des différents espaces mémoire afin d’établir des critères de sélection.Son utilisation a déjà été décrite dans la section 3.6.2. Les espaces de données sont alloués au moyen de l’instuction cudaMalloc, qui garantit un alignement des données sur 256 Bytes. Leur libération se fait au moyen de la fonction cudaFree. Les données non libérées ont une persistance correspondant à la durée de vie du contexte CUDA utilisé.Depuis la génération Fermi (compute capability ≥ 2.x), les communications de données avec la global memory passent par un processus de cache. Pour la génération Fermi, il s’agit d’un cache à double niveaux (L1 + L2). Cependant, depuis la génération Kepler (compute capability ≥ 3.x), les données ne transitent plus que par le cache L2. Les lignes de cache L1 font 128 Bytes tandis que celles du cache L2 font 32 Bytes.