|
Le CSI ou calcul Scientifique intensif fait appel à plusieurs techniques logicielles et matérielles. Pour une application scientifique donnée, le choix des techniques à appliquer pour obtenir les meilleures performances en terme de vitesse d'exécution et de précision des résultats va dépendre d'un certain nombre de paramètres : - liés à l'application : degré de parallélisme, granulométrie du parallélisme, rapport calcul/communications entre processeurs, ... - liés à l'environnement : système ou réseau de systèmes, réseau d'interconnection, système d'exploitation, librairies disponibles, ... Avant d'examiner les différentes classes de solutions, en fonction des types de problème, il semble utile de rappeler un certain nombres de définitions fondamentales, qui, malgré leurs années d'existence, sont toujours d'actualité. En tout premier lieu, la loi d'Amdhal, souvent utilisée de nos jours par le marketing, reste incontournable dès qu'il s'agit de s'attaquer à l'optimisation d'un programme (optimisation et non seulement parallélisation, car la loi d'amdhal s'applique dès que des portions de programme ne s'éxecutent pas à la même vitesse. Par exemple, séquentiel et parallèle, séquentiel et vectoriel, séquentiel et parallelo-vectoriel). Cette loi peut s'exprimer de 2 façons, en commençant par la plus simple : - 1 - Pour un programme comportant deux parties distinctes, l'une étant très lente et l'autre très rapide en temps d'exécution, l'influence de la partie lente peut pénaliser fortement le temps total d'exécution. Loin de ne s'appliquer qu'à l'informatique, cette loi peut se généraliser à tout processus dont la vitesse change dans le temps, par exemple la moyenne horaire obtenue à l'issue d'un trajet automobile est très pénalisée par les passages pendant lesquels la vitesse a été réduite. ce qui peut se traduire par, dans le cas du parallélisme (mais cela fonctionnerait de façon similaire pour le vectoriel) : - 2 - Facteur d'accélération = 1 / (Ps + (1-Ps)/Np), avec : Ps = pourcentage s'exécutant en mode scalaire et Pp = pourcentage s'exécutant en parallèle (1-Ps = Pp), et Np le nombre de processeurs. Cela peut également s'écrire en utilisant les temps d'exécution sur 1 processeur (T1) et sur Np processeurs (Tnp) : Tnp = T1 (Pp/Np +Ps) La conséquence directe (et dramatique !) de cette loi peut être ressentie dans le tableau suivant : | Np | 2 | 4 | 8 | 16 | 32 | Pp = 70 %
| 1,54 | 2,11 | 2,58 | 2,91 | 3,11 | Pp = 80 %
| 1,67 | 2,5 | 3,33 | 4,00 | 4,44 | Pp = 90%
| 1,82 | 3,08 | 4,71 | 6,40 | 7,80 | Pp = 95 %
| 1,90 | 3,48 | 5,93 | 9,14 | 12,55 | Pp = 98%
| 1,96 | 3,77 | 7,02 | 12,31 | 19,75 | Pp = 99 %
| 1,98 | 3,88 | 7,48 | 13,91 | 24,43 | Pp = 100 %
| 2 | 4 | 8 | 16 | 32 | | | | | | | |
Ce qui indique clairement au combien il est important d'explimer clairement tout le parallélisme possible dans un applicatif pour tirer partie au mieux de plusieurs processeurs. Cette table simple nous apprend de plus que : - ce n'est qu' à un niveau très élevé de parallélisation que l'on obtient des résultats probants. Or toutes les applications ne sont pas parallélisables, loin de là. - plus le nombre de processeurs est important, plus le degré de parallélisation est important. - cette table ne tient pas compte de différents niveaux de parallélisme, permettant de hiérarchiser les traitements, mais celà dépasse le cadre de cette introduction. La deuxième notion importante, particulièrement avec les architectures modernes reposant sur des noeuds de calcul plus ou moins importants reliés entre eux par un réseau de communication, concerne le rapport calcul/communication d'une application parallèle. Les réseaux sont de plus en plus rapides, mais restent loin de la bande passante obtenue de mémoire à processeur et il est donc important de minimiser cette activité pour espérer tirer le meilleur parti d'une architecture distribuée. La notion de localité des données est également essentielle, et il faut s'efforcer, pour minimiser les transferts de données coûteux en bande passante, de placer les données au plus près des processeurs. C'est déjà vrai pour un microprocesseur seul dont il faut essayer d'utiliser au maximum le cache, mémoire rapide la plus proche des unités de calcul, et c'est également vrai pour les architectures à mémoire virtuellement partagée de dernière génération. Le lecteur intéressé se reportera aux liens donnés à la page liens, dont certains détaillent les différents types d'architecture, leurs avantages et leurs inconvénients. Ce bref rappel des notions de base, très incomplet, n'a pour but que de vous sensibiliser à quelques éléments clés. En effet, l'arrivée en masse des processeurs multi-coeurs ne simplifie pas le problème, puisque les applications ne sont pas toutes destinées à tirer avantage de cette nouveauté. Il paraît difficle de croire qu'en pratique, deux coeurs équivalent à deux processeurs, ou naïf de croire que toutes les applications iront deux fois plus vite. Tridiagonal peut vous accompagner dans le choix et la mise en oeuvre d'une architecture destinée au calcul, qui dépendra principalement de vos applications. Il n'y a pas de solution universelle, et les architectures particulières peuvent également apporter des solutions, si les outils de mise en oeuvre et d'exploitation sont au rendez-vous. La couche logicielle et l'environnement système sont donc des éléments capitaux à prendre en compte lors du choix d'une solution, qui ne peut se faire que sur la seule base de l'architecture matérielle.
|