Actualités
|
![]() |
Emploi
|
![]() |
Start-up
|
![]() |
Avis d'expert | ![]() |
Vidéos | ![]() |
Indicateurs
|
![]() |
Distribution
|
![]() |
Telecharger Pro
|
![]() |
Livres blancs | |||||||||||||||||||||||||












“ Jusqu'à présent, la vitesse des processeurs évoluant régulièrement, on ne se posait guère de questions sur le gain de performance des applications, qui allait de soi à chaque changement de matériel. Mais nous arrivons aux limites des possibilités des semi-conducteurs à continuer dans cette voie ”, résume Jacques Truchet, consultant Solaris chez Sun.
En effet, la hausse de fréquence des processeurs se heurte aux lois de la physique, et son coût devient insupportable en énergie et en dissipation thermique. La nouvelle voie de développement consiste à multiplier les unités de traitement au sein des processeurs par des technologies telles que le multicœur et le Simultaneous MultiThreading (SMT), cette dernière consistant à faire exécuter à un même processeur plusieurs files d'instructions (threads) en même temps. Résultat : on voit sur le marché des processeurs à deux, quatre, voire huit cœurs, capables d'exécuter jusqu'à trente-deux threads dans le cas de l'UltraSPARC T1 de Sun.
L'augmentation mathématique des performances est-elle donc acquise pour les prochaines années par ce gain de parallélisme ? Pas aussi simple, alors que tous les logiciels bénéficiaient du gain de fréquence, tous ne sont pas capables de bénéficier de ce parallélisme.
Lors d'une conférence l'an dernier à Paris, Herb Sutter, architecte logiciel chez Microsoft et spécialiste du langage C++, expliquait que l'époque où chaque nouvelle génération de processeurs améliorerait les performances des applications était révolue, et appelait à une réforme des outils de développement multithread.
“ Aujourd'hui, la façon de développer est telle que peu de gens tirent pleinement parti de ces nouvelles architectures matérielles ”, considère Sami Jaber (lire encadré) contre l'avis de Stanislas Odinot, responsable marketing chez Intel France : “ La programmation de logiciels multithreads est courante, et ce depuis des années. ” Mais Stephen Herrod, vice-président de VMware, rappelle “ qu'il est très dur d'écrire un programme parallèle pour plus de quatre processeurs. Mais, comme la technologie multicœur décolle, il faut trouver un moyen de s'en servir. ”
En fait, comme le résume Jacques Truchet, “ il existe une pile de niveaux d'optimisation à prendre en compte, et le choix d'intervenir à l'un ou l'autre de ces niveaux dépend des besoins et des ressources. Les entreprises n'en sont pas encore à réécrire leurs applications, mais l'optimisation pour ces nouvelles architectures les préoccupe. ” L'équation est complexe, elle fait entrer en jeu les compilateurs, les systèmes d'exploitation, les environnements d'exécution (tels Java et .NET), les middlewares, mais aussi la façon dont les logiciels sont développés. Le compilateur tire du code du parallélisme dit “ explicite ”, basé sur les structures du langage de développement.
Sun et Intel ont d'ailleurs mis à jour dernièrement leurs outils de compilation en promettant justement des améliorations dans ce sens. Ensuite, les systèmes d'exploitation modernes ont tous une capacité à générer du parallélisme. “ Solaris est conçu pour gérer un nombre important de processus. Comme une application est généralement composée de plusieurs processus, on bénéficiera du parallélisme à travers l'OS ”, rappelle Jacques Truchet.
Les environnements d'exécution ont aussi leur rôle à jouer. “ Une JVM fait beaucoup de choses pour le développeur, elle gère la mémoire, mais aussi les threads. Un grand nombre de développeurs Java ne voit jamais un thread, car le serveur d'applications s'en charge ”, explique Alexis Moussine-Pouchkine, architecte Java chez Sun.
On peut aussi obtenir des optimisations en configurant la JVM de façon précise pour une application donnée. La virtualisation fournit aussi une partie de la solution, quoi qu'il soit plus juste de parler ici d'optimisation des ressources. “ Il est compliqué de développer des applications parallèles pour une machine à, disons, seize cœurs. Les techniques de virtualisation peuvent être une solution, en attachant x cœurs à une machine virtuelle. Il est vrai qu'à l'intérieur de chaque machine virtuelle, le fonctionnement reste séquentiel ”, explique Sylvain Siou, directeur technique de VMware pour la France.
Même s'il ne nie pas l'importance de toutes ces optimisations, Sami Jaber n'en démord pas : “ Si on veut aller plus loin dans l'utilisation efficace du parallélisme apporté par les architectures sous-jacentes, ce sera au développeur de placer les bons mots-clés dans son code au moment où il l'écrit, car c'est lui qui a la meilleure vision de la façon dont l'application est structurée. Faire de l'analyse de code par la suite est possible, mais cela reste très coûteux. ” “ Concevoir une application multithread ne peut se faire qu'en amont, confirme Jacques Truchet. Les spécialistes du système seront toujours là pour assurer une partie de l'optimisation, mais c'est plutôt la conception même des applications qu'il faudra revoir. ” Chez Intel, on confirme apporter de l'assistance à des éditeurs ou à des entreprises, sous forme de conseils ou parfois de retouche du code. “ Pour les éditeurs qui n'ont pas anticipé, cela demande un travail intellectuel de comprendre comment exploiter le multithreading, pour imaginer comment découper leur logiciel. Une fois ce découpage imaginé, il faut ensuite le programmer, et cela coûte souvent cher ”, affirme Stanislas Odinot.
En substitut de la course à la fréquence, les constructeurs de processeurs multiplient les cœurs au sein des processeurs, ainsi que les threads. Le gain en performances est au rendez-vous, mais peu d'applications en tirent pleinement parti.
Diverses solutions techniques existent pour optimiser la gestion des files d'instructions, mais cette parallélisation ne peut faire l'économie d'une façon différente de concevoir les applications en pensant autrement l'écriture du code. Cette prise en compte du parallélisme dans l'écriture accroît de 40 % les performances.
La recherche d'une meilleure utilisation du parallélisme dans la programmation va bon train. Certains composants sont déjà très avancés, telle la JSR133, un modèle révisé de gestion des threads et de la mémoire pour Java, ou l'interface de programmation d'applications OpenMP pour C, C++ et Fortran, qui fournit une famille d'outils pour la création d'applications parallèles.
Il existe aussi, avec Fortress chez Sun ou Concur chez Microsoft, de nombreuses recherches sur la façon d'introduire plus directement le parallélisme dans des langages de développement.
“ Aujourd'hui, le client demande une application avec un périmètre fonctionnel, le développeur l'écrit, mais la question de la performance ne se pose qu'à la mise en production. Très peu de développeurs pensent que leur application sera mise en œuvre sur une machine multiprocesseur. Ainsi, une grosse partie de la puissance informatique disponible est perdue car inexploitée. On sait faire de l'optimisation a posteriori, comme de paramétrer finement une JVM.
Le compilateur apporte aussi des optimisations et découvre du parallélisme. Mais il reste encore une marge, je dirais 40 % de performances, qui pourrait être gagnée en demandant au développeur de penser parallélisme dans son code, d'introduire les bons mots-clés au bon endroit. Mais un algorithme, c'est d'abord séquentiel, il y a donc un choc de culture pour les développeurs dans le fait de devoir penser parallélisme, ça demande plus de technicité. ”
“ Nous proposons des processeurs multicœur pour répondre aux attentes de performances et de baisse de la consommation des utilisateurs. Lorsque l'on passe de un à deux cœurs, le côté multitâche du système d'opérations tire profit de cette architecture. Maintenant, si l'on opte pour une architecture 4 à 8 cœurs, le système d'exploitation multitâche ne suffit plus.
Une solution consiste à écrire des programmes en parallèle. Dans le monde du serveur, de nombreuses applications ont été écrites en introduisant du parallélisme afin de fonctionner en cluster sur plusieurs serveurs. Passer d'une application fonctionnant sur plusieurs serveurs à une autre tournant sur plusieurs cœurs, cela ne change pas la philosophie. En revanche, c'est plus compliqué pour les applications écrites pour le poste client, où cette dimension de parallélisme n'a pas été introduite. ”
















