• Aucun résultat trouvé

un réglage manuel, une approche intéressante consiste à automatiser la génération du code CUDA et/ou le tuning des paramètres sensibles. Les paramètres typiques des stratégies de Tuning, tels que le choix de la taille et de la forme appropriées pour les blocs de threads, la programmation d’une bonne coalescence, ou la maximisation de l’occupation, s’avèrent être interdépendants.

De plus, les choix dépendent également des détails de l’architecture sous-jacente, et le motif d’accès à la mémoire globale de la solution élaborée.

Avant de nous intéresser aux détails nécessaires pour une application optimisée sous GPU, nous allons présenter les aspects parallèles dans notre cas d’étude.

5.2

Coopération CPU-GPU

Le but de cette partie est de présenter la façon d’établir une coopération efficace entre le CPU et le GPU, ce qui nécessite le partage de tâches et l’optimisation du transfert de données entre les deux composants.

Il existe de nombreux facteurs qui doivent être considérés avant de décider si le pro- cessus doit être alloué au CPU ou au GPU. Certains de ces facteurs sont constants et d’autres peuvent compter sur les états du processus en temps réel.

Un processus correct de gestion de la distribution est important pour deux raisons : 1. Il est souhaitable que le CPU et le GPU aient des charges de processus similaires,

en évitant le cas où l’un est surchargé et l’autre est entièrement libre ;

2. Il est pratique de distribuer les processus en tenant compte de l’architecture qui serait la plus efficace pour ce genre de problème.

Tout d’abord, nous allons décrire brièvement le schéma commun de parallélisation des algorithmes évolutionnaires sous GPUs. Ensuite, nous allons nous concentrer sur l’opti- misation des transferts de données entre le CPU et le GPU, tant elle représente l’un des enjeux cruciaux pour atteindre les meilleures performances dans les applications GPUs. Finalement, nous allons projeter ces points critiques sur le problème étudié.

5.2.1

Répartition des tâches pour les algorithmes évolutionnaires

sur GPU

5.2.1.1 Cas de parallélisation de l’évaluation

La parallélisation des algorithmes évolutionnaires suit différents modèles. L’un d’entre eux consiste à paralléliser seulement la phase d’évaluation, tant cette phase est souvent la plus consommatrice en temps de calcul dans les algorithmes évolutionnaires spécialement et les méta-heuristiques généralement (Le modèle maître/esclave). L’avantage de cette approche est qu’elle garde le même comportement comparativement à un algorithme sé- quentiel. À chaque itération, le maître génère l’ensemble des solutions à évaluer. Chaque travailleur (esclave) reçoit une partition de l’ensemble des solutions depuis le maître. Ces solutions sont évaluées et retournées au maître. Un challenge de ce modèle est de déter- miner la granularité de chaque partition de solutions à allouer à chaque travailleur selon les délais de communication de l’architecture donnée. En termes de généricité, comme le modèle est indépendant du problème, il s’avère être générique et réutilisable.

5.2. COOPÉRATION CPU-GPU

Dans ce cas, selon le paradigme maître/esclave, l’idée est d’évaluer les solutions en parallèle sur GPU. Dans ce modèle, un Kernel est envoyé au GPU pour être exécuté par un grand nombre de threads groupés en blocs. La granularité de chaque partition est déterminée par le nombre de threads par bloc [202], [213], [2], [125], [176].

Ce genre de parallélisation est utile pour un algorithme dont le temps d’évaluation est prédominant. Ce modèle est décrit par la figure (5.1).

Figure 5.1 – Évaluation parallèle des solutions sur GPU.

5.2.1.2 Cas de l’algorithme complet

Notre étude diffère significativement des autres études du fait qu’elle représente une implémentation parallèle à base de GPU, qui de plus ne sera pas consacrée que pour l’évaluation, mais également pour toutes les autres phases, en suggérant des modifications aux opérateurs évolutionnaires existants en fonction de l’architecture du GPU (e.g. [171], [143], [2]), en fonction de la nature du problème étudié et en fonction des opérateurs évolutionnaires utilisés.

Par la suite, nous allons présenter quelques opérateurs évolutionnaires modifiés afin qu’ils soient situables pour l’architecture spécifique du GPU, suivie par les détails de la gestion du parallélisme, ainsi que la gestion de la mémoire du GPU.

5.3. ÉQUILIBRAGE DE LA CHARGE

Figure 5.2 – Stratégie évolutionnaire complet sur GPU

Afin de converger vers une haute performance d’un GPU, la parallélisation de chaque opérateur évolutionnaire est souhaitable. Un des premiers travaux pionniers sur les opé- rateurs évolutionnaires a été proposé par Wong et coll. dans [202], [201] dans le but de réaliser une mutation spécifique (Cauchy mutation) sur GPU. D’une manière similaire, Shah et coll. [171]ont proposé des versions modifiées des sélections dites uniforme et rou- lette pipée, ainsi qu’une autre version du croisement en un seul point, convenable pour les GPUs. Dans [128], Ogier et Coll. ont présenté une étude expérimentale de différents variantes de la sélection en tournoi. Osio et coll. [143] ont présenté les versions modifiées de la sélection de tournoi, de croisement en un seul point et la mutation en un point. Dans la même optique, Jaros et Coll. [98] ont proposé aussi des opérateurs modifiés convenables à une architecture GPU.

Dans notre cas, nous avons utilisé un algorithme évolutionnaire totalement plongé dans l’accélérateur graphique, tous les détails de l’algorithme ainsi que les modifications sont dans la partie 2 du chapitre 4.

5.3

Équilibrage de la Charge

Avoir un système qui intègre un processeur hôte, un ensemble de cartes avec plusieurs cœurs sur chaque carte, ayant un ensemble de tâches à accomplir, nécessite de diviser l’ensemble des tâches en sous-ensembles assignés, aux cartes, aux MPs et finalement aux cœurs.

L’objectif principal d’un processus d’équilibrage de charge est de réduire le temps d’exécution global.