Selon Gartner, le nombre de coeurs des processeurs augmente trop vite pour les logiciels serveurs
Carl Claunch, analyste au Gartner, publie un document en forme d'avertissement. Non seulement les logiciels ne profitent pas de la puissance des serveurs multicoeurs, mais ils en pâtissent ! Et les entreprises doivent absolument se préparer pour encaisser ce phénomène qui risque de durer plusieurs années.
Le Gartner s'inquiète. Les serveurs évoluent beaucoup trop rapidement pour le logiciel. Les puces comptent un nombre de plus en plus important de coeurs. Qui plus est, ces coeurs gèrent souvent chacun plusieurs threads (instructions élémentaires). Dans le monde du x86, de deux coeurs, on est passé à quatre, et on annonce bientôt huit. Or, le multicoeur n'est pas forcément synonyme de performances améliorées, au contraire ! Car les logiciels restent à la traîne. Très à la traîne. Systèmes d'exploitation, hyperviseurs, middlewares et applications sont loin de tirer parti de toute la puissance proposée par les serveurs multicoeurs. Deux coeurs dans un processeur ne donnent pas deux fois plus de puissance. Pire encore... Carl Claunch, analyste pour le Gartner, spécialiste des infrastructures serveurs, prévient : dès qu'on dépasse deux coeurs, on peut très bien voir la performance décroître ! Le surplus de travail imposé au système par la gestion de quatre coeurs, par exemple, peut induire un tel phénomène. L'analyste estime qu'un nombre significatif d'entreprise est déjà touché et qu'il ne va cesser d'augmenter. Les hyperviseurs sont de toute façon limités à quelques dizaines de coeurs Dans deux ans, selon Carl Claunch, on devrait déjà voir apparaître des serveurs équipés de 512 coeurs au total (32 sockets hébergeant chacun 16 coeurs). Dans quatre ans, ils en accueilleront le double... Or, l'analyste rappelle que la plupart des hyperviseurs ne peuvent dépasser 64 puces. Selon lui, ESX de VMware se limite à 32 coeurs et Hyper-V de Microsoft à 24. Du coté des OS, si Linux et Windows ne dépassent pas 64 coeurs à base de x86, z/OS atteint tout juste 64 et les Unix, moins limités, supportent entre 128 et 512 puces suivant l'éditeur. Pour adapter un logiciel à une configuration multicoeur, il ne suffit pas, comme on pourrait le croire, de découper le code en plusieurs parties pour le répartir sur les puces. « Diviser le logiciel en deux ou en quatre morceaux, n'est pas très compliqué, confirme Carl Claunch. Mais quand on passe à 128 ou 256 coeurs, c'est une autre question. » D'autant que, comme le précise l'analyste, il faut aussi équilibrer ces 'morceaux' de code pour qu'ils se répartissent judicieusement sur les coeurs du processeur. Le principe même de la parallélisation, du multithreading, de la répartition de tâches... L'industrie fait des efforts pour faciliter le portage des applicatifs Bien sûr, l'industrie informatique, celle du matériel comme celle du logiciel, travaille dur pour sortir de ce qui ressemble fort à une impasse. Ainsi, Intel et Microsoft ont tous deux rendu disponible un ensemble d'outils facilitant le travail des développeurs. « Il faut dire qu'aucun fournisseur n'a intérêt à voir réduire le taux de renouvellement des machines en entreprise ! » rappelle Carl Claunch. Les utilisateurs pourraient en effet décider de ne pas changer de matériels, pour éviter les problèmes. Les laboratoires de recherche universitaire se penchent eux aussi sur ces questions de portage. Tous s'appuient aussi, bien entendu, sur les travaux réalisés durant des décennies par le monde du HPC (calcul haute performance), même s'ils ont été menés dans des contextes très différents. « Pour l'instant, persiste cependant Carl Claunch, il n'existe pas de solution unique et simple au développement de logiciel parallélisé. » Les entreprises doivent se préparer à une migration permanente des logiciels En résumé, il faudra des mois, voire des années, pour que le logiciel rattrape son retard sur le matériel. D'autant que les constructeurs ne vont pas stopper les évolutions de leurs serveurs pour attendre le logiciel. C'est pourquoi Carl Claunch conseille aux entreprises utilisatrices de se préparer à entrer dans une période de migration permanente de leurs logiciels. « Elles ne pourront plus stabiliser les installations durant 5 ou 6 ans comme avant. » « Les entreprises étaient habituées à migrer des versions de logiciel inchangées d'une infrastructure vers une autre. Ce ne sera plus possible. En conséquence, le cycle de vie du logiciel sera de plus en plus court. » Les utilisateurs devront investir davantage de budget dans les nouvelles versions et se doter de ressources plus importantes pour la maintenance. En ces temps de crise, ce genre de conseils risque de ne pas être très bien accueilli. « Pourtant aujourd'hui, il n'y a pas beaucoup d'autre solution, note cependant Carl Claunch. Quand un éditeur sort un système d'exploitation serveur, celui-ci va durer près de dix ans. Et il devra donc s'adapter à toutes les infrastructures qui sortiront durant cette période. Il faudrait que le fournisseur écrive son OS en anticipant ces machines, y compris celles dont on ne connaît absolument rien aujourd'hui... Impossible. »
