211service.com
Programmation simplifiée pour les ordinateurs multicœurs
Le nombre de cœurs (ou unités de calcul) dans les microprocesseurs double à chaque génération, offrant un potentiel informatique énorme pour les ordinateurs de bureau, les ordinateurs portables et, éventuellement, les gadgets portables. Les machines quadricœurs actuelles, par exemple, sont particulièrement utiles pour des applications gourmandes en calculs telles que le traitement vidéo et les jeux. Cependant, les nouvelles machines multicœurs sont essentiellement des superordinateurs à petite échelle, et afin de tirer pleinement parti de la puissance de calcul qu'elles offrent, les logiciels doivent être écrits avec plusieurs cœurs à l'esprit, une tâche longue et difficile connue sous le nom de programmation parallèle. Et de nombreux experts pensent que si la programmation parallèle ne peut pas être facilitée, les progrès de l'informatique s'arrêteront brutalement.
Logiciel simplifié : StreamIt est un langage logiciel et un compilateur qui permet aux programmeurs de programmer facilement des machines multicœurs, une tâche appelée programmation parallèle qui prend autrement du temps et est difficile.
Les chercheurs du MIT cherchent un moyen de soulager la douleur de la programmation parallèle. Ils ont conçu un langage informatique et un compilateur - un outil spécialisé qui convertit le langage en instructions informatiques - qui masque essentiellement les défis de la programmation parallèle, tout en tirant parti de la puissance de plusieurs cœurs. Le langage et le compilateur, appelés StreamIt , ont été développés par Saman Amarasinghe , professeur de génie électrique et d'informatique au MIT. StreamIt fonctionne actuellement sur une machine multicœur spécialisée construite au MIT, mais d'ici cet été, Amarasinghe s'attend à ce que le logiciel soit prêt à fonctionner sur des puces commerciales fabriquées par IBM, Sony et Toshiba trouvées dans les machines PlayStation 3 de Sony.
Créer un logiciel est encore quelque chose que beaucoup de gens peuvent faire, mais s'ils devaient faire face au parallélisme, cela devient beaucoup plus difficile, explique Amarasinghe.
Dans les machines monocœur, le code logiciel s'exécute, pour la plupart, de manière séquentielle. Cela signifie que les tâches, telles que l'accès à certains morceaux de mémoire pour ouvrir un programme, se produisent les unes après les autres, de manière prévisible. Dans un système multicœur, les tâches sont réparties entre les cœurs. Et lorsque différentes tâches doivent accéder au même morceau de mémoire, les tâches doivent travailler ensemble pour soigneusement orchestrer ou synchroniser les accès. Si plusieurs tâches accèdent par inadvertance aux mêmes données sans synchronisation appropriée, les données seront corrompues, produisant des résultats incorrects ou faisant planter le programme.
Dans les machines monocœur, il est assez facile de déboguer les erreurs de programmation ou les problèmes involontaires, car la cause peut être attribuée à une instruction particulière. Mais Amarasinghe dit que certains bogues dans les systèmes parallèles sont plus difficiles à corriger car ils sont probabilistes, ce qui signifie qu'ils ne surviennent qu'occasionnellement ; chaque fois que le programme s'exécute, les multiples cœurs exécutent leurs tâches de manière indépendante, ce qui entraîne des milliards d'ordres d'exécution possibles pour le programme.
La solution d'Amarasinghe est basée sur un concept bien connu appelé flux de données, dans lequel les données sont transmises séquentiellement à travers une sorte de pipeline de fonctions. Au fur et à mesure que les données circulent, le compilateur voit quelles fonctions sont indépendantes. Ainsi, le compilateur peut placer des tâches distinctes sur des cœurs différents, sans craindre qu'elles interfèrent les unes avec les autres ou touchent le même morceau de mémoire.
Un programmeur n'a besoin que d'écrire un logiciel qui fonctionne de manière séquentielle. Le compilateur voit toutes les interactions qui doivent se produire, sur la base du code écrit par le programmeur, et alloue les instructions de manière appropriée pour empêcher l'apparition de bogues.
C'est une bonne idée basée sur des concepts bien connus, dit Course de Bodik , professeur d'informatique à l'Université de Californie à Berkeley. Si vous voulez que des programmeurs qui ne sont pas experts en parallélisme soient productifs, si vous voulez qu'ils écrivent efficacement des programmes, vous voulez leur donner un langage comme StreamIt, dit-il. Cependant, Bodik soupçonne que les ingénieurs logiciels devront s'appuyer sur une hiérarchie d'outils qui fonctionnent à différents niveaux. Par exemple, la mémoire transactionnelle, qui permet à de nombreuses tâches de partager la même mémoire en même temps, pourrait fonctionner en coulisse, aidant à maximiser le potentiel de StreamIt. (Voir Le problème avec les ordinateurs multicœurs .)