 |
|
|
| |
|
|
|
| Processeurs multicœur : comment les éditeurs de logiciel vont-ils s'adapter ? |
| Développements, tests, optimisations, licences, compétences : autant de données que les nouveaux processeurs d'AMD et d'Intel viennent chambouler - sans pour autant tout remettre en cause.
(15/09/2005) |
|
Présentés à l'occasion du deuxième trimestre 2005 successivement
par Intel puis AMD, les processeurs à double cur ou dual core,
s'installent petit à petit dans le monde des serveurs d'entreprise.
Avec pour objectif de faciliter le traitement des processus
en parallèle (lire l'article
du 07/09/2005), ces nouvelles puces impliquent des adaptations
plus ou moins profondes chez les éditeurs.
Premier impact chez les clients : la configuration nécessaire
pour un logiciel donné reste encore floue. "Nous commençons
à recevoir des petits éléments en matière de retour d'expérience
sur la configuration nécessaire, notamment du point de vue de la mémoire
partagée des processeurs qui varie d'un modèle à l'autre et
peut avoir un impact sur les performances des applications. Il est arrivé
pour des clients d'avoir quelques surprises", indique Yves Lhérault,
directeur technique chez BEA France.
Pour
les éditeurs, l'évolution des configurations nécessite alors
une batterie de tests supplémentaires pour constituer une grille
de référence en matière de matériel bicoeur. De plus, l'augmentation
des performances n'est pas systématiquement au rendez-vous,
tout dépend des traitements courants réalisés par le logiciel.
Les applications tirant le plus facilement profit de ces nouvelles
puces sont celles requérant de nombreux accès aux données tandis
qu'une application multipliant les entrées / sorties se montrera
plus limitée avec un processeur bi-cur qu'avec deux processeurs
distincts monocoeur.
D'autres applications, non conçues pour
traiter différents processus (threads) en parallèle ne tireront
aucun gain de cette nouvelle architecture et pourrait même en
être légèrement pénalisée.
| Le
cloisonnement des développements facilite la migration
du code |
"De notre côté, il n'y a eu que peu d'adaptation à faire entre
multiprocesseurs et multicurs. De plus, nos logiciels se basent
sur des composants communs ce qui nous a permis de gagner du
temps sur la phase d'optimisation des développements. Enfin,
nous supportons le multicur depuis qu'il existe sur les processeurs
RISC d'IBM, ce qui remonte à plus de deux ans", commente Michel
Granger, directeur des ventes Lotus Partenaires pour IBM Software.
Lorsque l'exploitation des ressources matérielles a bien été
séparée du reste du programme, le logiciel n'est généralement
pas influencé par les conséquences d'un processeur à deux curs,
même s'il convient de s'assurer de son bon fonctionnement.
La
tâche la plus problématique incombe cependant aux éditeurs qui
travaillent en couche basse, éditeurs de systèmes d'exploitations,
de logiciels embarqués ou de compilateurs par exemple.
"L'arrivée des dual core a nécessité une modification de l'ordonnanceur
des tâches pour le noyau Linux. Il doit répondre au challenge
suivant : équilibrer la charge en fonction des caractéristiques
du CPU qu'ils soient hyper-threadés, multi-CPU ou multicur.
Pour compliquer les choses, il existe des plate-formes NUMA
où certains CPU ont accès plus rapidement à la mémoire que d'autres",
explique Frédéric Lepied, Directeur recherche et développement
chez Mandriva.
| La
diversité des systèmes complexifie l'optimisation |
Selon les différents systèmes, l'accès à la mémoire, le cache
et le CPU peuvent être ou non partagés, nécessitant une répartition
différente des tâches pour une meilleure optimisation.
Sachant
qu'un même serveur peut combiner hyperthreading, multi-CPU et
bientôt multicur, le casse tête n'est pas loin. Heureusement,
le travail d'optimisation des architectures multi-processeurs
a été largement étudié depuis de nombreuses années et fait partie
des domaines bien maîtrisés.
Les constructeurs de micro-processeurs ont également participé
activement à l'adaptation des différents systèmes. "Nous travaillons
en relation étroite avec AMD et Intel. Pour le matériel AMD,
nous avons commencé le travail mi-2004 pour sortir notre premier
produit compatible Opteron dual core début 2005. Avec Intel,
nous y réfléchissons depuis le printemps 2005 et le premier
produit compatible avec leurs serveurs dual core est prévu pour
le mois d'octobre", ajoute Frédéric Lepied.
Mais le système Linux bénéficie d'un traitement de faveur. Son
cur, optimisé pour les traitements multitâches s'adapte parfaitement
aux notions de parallélisme proposées par ces nouvelles architectures.
De plus, l'ensemble de la communauté contribue à l'évolution
du noyau, mutualisant les ressources des différents éditeurs.
Pour les éditeurs détachés du matériel, la gestion de threads
par le système d'exploitation d'une part, et par le compilateur
d'autre part, détermineront l'efficacité du programme à être
subdivisé en sous-ensembles exécutés en parallèle.
Une part
de ce découpage s'effectue aussi de manière transparente par
le processeur lui-même de manière à optimiser les performances
même pour un serveur exécutant des vieilles versions de logiciels.
| Les
licences finalement harmonisées vers le bas |
Aussi, l'impact du multicur sur le temps de développement
ou les compétences des programmeurs devrait être faible, voire
nul. "Les gens qui ont le plus à optimiser leurs codes sont
ceux qui connaissent déjà bien le matériel et les systèmes d'exploitation.
Cela ne changera pas fondamentalement leurs profils : ceux qui
font du Java seront tranquilles en se reposant sur la JVM [NDLR
: machine virtuelle java / interpréteur], ceux qui font du C
se reposent sur le système d'exploitation", analyse le directeur
technique de BEA France.
Les licences logicielles, principal sujet de discorde il y a
un an (lire l'article
du 20/10/2004), semble aujourd'hui avoir trouvé une réponse
unique de la part de l'industrie du logiciel. "Sur des machines
Intel, nous n'avons pas des ratios x2 en performances, il ne
serait donc pas normal de faire payer x2 au client. Quant aux
évolutions futures vers le quadri processeur, je n'ai pas de
réponse. La vraie question est de savoir quel sera le mode de
facturation le plus adapté à l'entreprise", indique ainsi Michel
Granger d'IBM.
A l'origine, Oracle et IBM étaient favorables à une tarification
par cur présents et non plus au processeur, tandis que BEA
prônait une hausse du prix des licences indexée sur l'augmentation
des performances, 25% à l'époque.
Depuis, tous excepté Oracle,
se sont rangés aux côtés de Microsoft, Novell et Sun en ne facturant
qu'un seul processeur pour une puce à deux curs, la considérant
comme la nouvelle unité de base de l'informatique.
|
L'avis d'Alexis Moussine
Pouchkine (Architecte Java, Sun France)
|
|
"Les premières réflexions dans
la JVM de codes spécifiques aux multicurs ont abouti
avec Java 5, qui lui-même date d'environ un an, septembre
2004 pour être précis. Ceci dit, c'était seulement des
premières traces de code multicur car les mises à
jours trimestrielles de la JVM améliorent régulièrement
les performances par une meilleure utilisation des ressources
selon le processeur.
Notre position de constructeur informatique fait que
nous nous intéressons de très près au matériel. Nous
disposons de nombreuses compétences en interne, le travail
d'adaptation a donc été réalisé exclusivement chez Sun,
sur la base d'informations fournies par Intel et AMD
bien entendu. Nos propres processeurs Sparc fonctionnent
avec plusieurs curs et il a donc fallu adapter la JVM
au même moment.
Notre objectif a surtout été que le
développeur ait la même expérience entre multiprocesseur
et multicur. C'est de la responsabilité de la JVM
d'être une assurance du développeur face au temps qui
passe en tirant partie des nouveautés. Avec ce type
d'architecture, on voit rapidement la différence entre
du bon code et du code peu optimisé car basé sur une
approche assez monothreadé.
Avec Java 5.0 apparaît une nouvelle bibliothèque de
code multithreadée qui s'adresse aux développeurs et
doit leur permettre de respecter plus facilement les
bonnes pratiques de développement en multithread.
La JVM s'occupe de son coté d'optimiser l'utilisation
de la mémoire, de déclencher le garbage collector au
moment opportun et de passer en code natif ce qui doit
l'être."
|
|
L'avis d'Eric Nataf (Responsable marketing serveur, Microsoft France)
|
|
"La grande majorité des produits
serveurs Microsoft supporte le multicur, les prochaines
versions doivent tous gérer le multicur, ils font
partie des critères d'engagements communs ou CEC que
prend Microsoft vis-à-vis de ses clients. Parmi ces
critères, on trouve notamment l'environnement 64 bits,
des critères relatifs à la sécurité
Nous n'envisageons aucun changement au niveau de la
tarification de nos logiciels. La position de Microsoft
a été communiquée en 2004 : elle consiste à mettre à
disposition de nos clients la puissance maximum. Cela
signifie que le modèle reste basé sur le processeur,
quel que soit le nombre de curs présents ou à venir
sur les processeurs. L'apparition de cette technologie
s'inscrit dans la continuité de la loi de Moore.
Le découpage du prix s'effectue donc en fonction du
type de processeur, et non des curs. Sur les tests
actuels, les gains utilisateurs engendrés par cette technologie
sont plus significatifs pour les logiciels d'entreprise
que ne l'était la montée en fréquence. Toutefois, nous
ne constatons pas un gain proportionnel au nombre de
curs présents sur la puce, mais c'est un levier important
pour l'avenir."
|
|
|
|
|
|
|
|
Dossier 