Avec l'arrivée prochaine de Snow Leopard, et de ses deux technologies phares, à savoir OpenCL et Grand Central, on parle de plus en plus de parallélisme.
Les processeurs en ont en effet terminé avec la progression verticale : au lieu d'augmenter la puissance brute des processeurs, on augmente leur nombre. On obtient ainsi, du moins potentiellement, un bien meilleur rapport puissance/consommation. Le problème c'est qu'il faut désormais bâtir les logiciels très différemment pour en tirer parti. Ainsi, il faut couper les tâches en petits morceaux afin de les faire exécuter simultanément par les différents processeurs et leurs multiples cores. L'opération n'est résolument pas aisée, et nécessite une refonte de l'architecture des logiciels. Si Grand Central a pour vocation de veiller à éviter les embouteillages et permettre aux multiples opérations de se dérouler sans encombre, il ne permet pas pour autant de faire des miracles, et les développeurs devront malgré tout déterminer eux-mêmes quelles tâches se plient le mieux au parallélisme.
Ne nous leurrons pas : le parallélisme n'est qu'un pis aller. S'il permet de mieux tirer parti de nos multicores, toutes les opérations ne s'y plient pas pour autant, et nécessiteront une refonte des logiciels, alors qu'une augmentation de la puissance brute des processeurs était directement exploitable sans rien changer du côté logiciel. On voit déjà bien peu d'applications qui tirent parti des biprocesseurs, alors que les Macs utilisent ce type d'architecture depuis bien longtemps. Les choses ne vont pas aller en s'arrangeant, car la multiplication des processeurs n'ira qu'en augmentant. Imaginez le casse-tête quand nous aurons pas moins de 32 processeurs dans nos machines!
Pourtant, l'industrie informatique a une longue expérience du multiprocessing, dans le champ d'application des serveurs notamment. Mais il y a un univers entre une application pour plusieurs utilisateurs et plusieurs applications pour un seul utilisateur, caractéristique essentielle qui différencie l'environnement serveur de celui que nous côtoyons quotidiennement. En effet, les applications serveur se prêtent par nature au parallélisme, chaque utilisateur étant susceptible de lancer une tâche qui s'exécute simultanément aux autres. Après tout, plusieurs processeurs dans une seule machine, c'est un peu comme si vous utilisiez plusieurs ordinateurs simultanément, et encore, ça n'en a pas tous les avantages, puisqu'on conserve une seule allocation mémoire vive, et la plupart du temps un seul disque dur, qui font figure de goulot d'étranglement en entrée et en sortie des processeurs. Les logiciels qui fonctionnent sur nos Mac se contentent, la plupart du temps, d'utiliser de la mémoire et quelques cycles processeur ici ou là lorsqu'elles sont en tâche de fond : ça n'est pas tous les jours qu'on lance plusieurs opérations simultanément. Le parallélisme sur l'ordinateur personnel s'attache donc à découper les opérations monolithiques en petits morceaux à exécuter concomitamment. Seulement voilà, nombre de ces opérations sont linéaires, chaque résultat dépend d'une opération précédente.
Il ne faut donc pas s'attendre à voir votre Mac mini se prendre pour un Mac Pro comme par magie avec le passage à Snow Leopard. Il faudra mettre les logiciels à jour pour qu'ils exploitent Grand Central et OpenCL. Les seuls cas d'accélération "spontanée" concerneront les appels au commandes du système qui auront été réécrites avec Grand Central et OpenCL. Certes, les beta-testeurs de Snow Leopard ont pu s'atteler à la tâche depuis la finalisation de ses API (voir notre article Snow Leopard : les API finalisées), on peut donc avoir bon espoir de voir nombre de mises à jour disponibles à la sortie du félin. Mais à bien y regarder, tout ceci ne rend l'augmentation de puissance de nos machines que bien théorique : s'il est si délicat d'en tirer toute la substantifique moelle, on finit par gâcher plus de puissance qu'on en exploite, et il semble bien que la stratégie n'avait d'autre objectif que de ne pas faire mentir la loi de Moore, si ce n'est de maintenir la dynamique du marché hardware.
Quoi qu'il en soit, le mal est fait et il faut bien composer avec. Et Grand Central présente un réel avantage une fois qu'un logiciel a été "parallélisé" : c'est le système qui se charge de gérer la répartition des opérations, quel que soit le nombre de processeurs disponibles et le nombre de tâches en cours d'exécution. Voilà qui présente un vrai bénéfice puisque c'est autant de travail que les développeurs n'ont pas à faire, et à vrai dire c'est bien au système d'exploitation de prendre en charge cette partie puisque chaque logiciel ne peut prétendre de contrôler ce que les autres font, ou encore d'intégrer tous les cas de figure matériels, de 2 à x processeurs. Pour résumer, il ne faut pas s'attendre à ce que Snow Leopard ouvre les vannes des logiciels qui exploitent les multiprocesseurs : il y a peu de chances d'en voir bien plus qu'avant, mais ceux qui seront conçus dans ce sens le feront mieux. Et l'avantage sera d'autant plus notable à mesure que le nombre de processeurs augmentera dans nos machines.
Il est d'ailleurs assez ironique de constater que, en regard de cette mise en parallèle des tâches avec les multiprocesseurs, une autre poussée va dans le sens radicalement opposé avec les GPGPU, qui seront gérés par OpenCL. Quand l'un s'attache à découper les opérations pour les répartir sur plusieurs processeurs, l'autre les unifie pour les traiter en une seule passe. C'est sans doute ce qui permet de mieux appréhender la différence fondamentale entre un CPU et un GPU. L'un dispose d'une multitude de portes étroites, quand l'autre n'en propose qu'une seule, mais béante. Jerry Harris, responsable scientifique au sein de l'équipe de développement de Photoshop, l'explique en termes imagés dans cette interview : le multiprocessing, c'est comme si on travaillait avec un troupeau d'ânes : on peut se débrouiller avec deux, mais à partir de quatre ou cinq, ça devient invivable, car ils n'en font qu'à leur tête (c'est justement là où Grand Central donnera toute sa mesure). Alors qu'un GPU se comporte plus comme un banc de poissons ou une volée d'oiseaux : plus il y en a, et mieux ça se passe.
Les GPU sont entièrement voués à traiter de larges amas de données de manière très véloce. Mais cette approche n'est pas exempte d'inconvénients. Il faut déjà que les données et les opérations s'y prêtent, ce qui n'est pas le cas de toutes. Mais même dans ce cas, les GPU étaient jusqu'ici conçus pour être autonomes : une fois qu'on leur a envoyé les données et la nature des opérations à effectuer dessus, on ne s'en préoccupe plus, le GPU les garde dans son coin, par exemple pour afficher une texture à l'écran, sans repasser par la case processeur. L'utilisation d'un GPU comme coprocesseur implique qu'on récupère le résultat pour en faire autre chose, et comme le GPU peut appliquer une seule et même opération sur un lot hétérogène de données, on est susceptible de n'en demander qu'une partie à un instant T. Or, cette opération fait figure de goulot d'étranglement, la récupération de données étant plus lente que le calcul !
Russel Williams, un autre ingénieur d'Adobe, n'est pas en reste en matière de métaphore imagée pour illustrer le cas de figure : c'est comme si vous souhaitiez imprimer un journal local pour San Jose, mais que vous le fassiez imprimer à New York, et livrer par un vieux coucou.
Comme on le voit, Grand Central et OpenCL ne sont pas des solutions miracles, mais elles sont des réponses adaptées à un environnement matériel donné. On le sait depuis longtemps, le micro-processeur à base de silicium arrive en bout de course. On réduit la résolution de gravure d'année en année, vaille que vaille, mais viendra un moment où on ne pourra pas aller au-delà. La frontière ultime et indépassable, c'est la taille de l'atome. Alors que les nanotechnologies font parler d'elles dans d'autres industries, voilà bien longtemps que, d'une certaine manière, l'informatique en est une représentante de taille. Il faudra, tôt ou tard, changer de paradigme, ce qui représentera une révolution à bien des égards. S'il y a différentes pistes de recherche qui sont très prometteuses (processeur optique, processeur quantique, supraconductivité…), elles sont pour l'heure bien loin d'être mises en application et pour certaines font plus figure de science-fiction. D'ici là il faudra bien composer avec les moyens dont nous disposons. C'est ce qu'Apple fera avec Snow Leopard.
Les processeurs en ont en effet terminé avec la progression verticale : au lieu d'augmenter la puissance brute des processeurs, on augmente leur nombre. On obtient ainsi, du moins potentiellement, un bien meilleur rapport puissance/consommation. Le problème c'est qu'il faut désormais bâtir les logiciels très différemment pour en tirer parti. Ainsi, il faut couper les tâches en petits morceaux afin de les faire exécuter simultanément par les différents processeurs et leurs multiples cores. L'opération n'est résolument pas aisée, et nécessite une refonte de l'architecture des logiciels. Si Grand Central a pour vocation de veiller à éviter les embouteillages et permettre aux multiples opérations de se dérouler sans encombre, il ne permet pas pour autant de faire des miracles, et les développeurs devront malgré tout déterminer eux-mêmes quelles tâches se plient le mieux au parallélisme.
Ne nous leurrons pas : le parallélisme n'est qu'un pis aller. S'il permet de mieux tirer parti de nos multicores, toutes les opérations ne s'y plient pas pour autant, et nécessiteront une refonte des logiciels, alors qu'une augmentation de la puissance brute des processeurs était directement exploitable sans rien changer du côté logiciel. On voit déjà bien peu d'applications qui tirent parti des biprocesseurs, alors que les Macs utilisent ce type d'architecture depuis bien longtemps. Les choses ne vont pas aller en s'arrangeant, car la multiplication des processeurs n'ira qu'en augmentant. Imaginez le casse-tête quand nous aurons pas moins de 32 processeurs dans nos machines!
Pourtant, l'industrie informatique a une longue expérience du multiprocessing, dans le champ d'application des serveurs notamment. Mais il y a un univers entre une application pour plusieurs utilisateurs et plusieurs applications pour un seul utilisateur, caractéristique essentielle qui différencie l'environnement serveur de celui que nous côtoyons quotidiennement. En effet, les applications serveur se prêtent par nature au parallélisme, chaque utilisateur étant susceptible de lancer une tâche qui s'exécute simultanément aux autres. Après tout, plusieurs processeurs dans une seule machine, c'est un peu comme si vous utilisiez plusieurs ordinateurs simultanément, et encore, ça n'en a pas tous les avantages, puisqu'on conserve une seule allocation mémoire vive, et la plupart du temps un seul disque dur, qui font figure de goulot d'étranglement en entrée et en sortie des processeurs. Les logiciels qui fonctionnent sur nos Mac se contentent, la plupart du temps, d'utiliser de la mémoire et quelques cycles processeur ici ou là lorsqu'elles sont en tâche de fond : ça n'est pas tous les jours qu'on lance plusieurs opérations simultanément. Le parallélisme sur l'ordinateur personnel s'attache donc à découper les opérations monolithiques en petits morceaux à exécuter concomitamment. Seulement voilà, nombre de ces opérations sont linéaires, chaque résultat dépend d'une opération précédente.
Il ne faut donc pas s'attendre à voir votre Mac mini se prendre pour un Mac Pro comme par magie avec le passage à Snow Leopard. Il faudra mettre les logiciels à jour pour qu'ils exploitent Grand Central et OpenCL. Les seuls cas d'accélération "spontanée" concerneront les appels au commandes du système qui auront été réécrites avec Grand Central et OpenCL. Certes, les beta-testeurs de Snow Leopard ont pu s'atteler à la tâche depuis la finalisation de ses API (voir notre article Snow Leopard : les API finalisées), on peut donc avoir bon espoir de voir nombre de mises à jour disponibles à la sortie du félin. Mais à bien y regarder, tout ceci ne rend l'augmentation de puissance de nos machines que bien théorique : s'il est si délicat d'en tirer toute la substantifique moelle, on finit par gâcher plus de puissance qu'on en exploite, et il semble bien que la stratégie n'avait d'autre objectif que de ne pas faire mentir la loi de Moore, si ce n'est de maintenir la dynamique du marché hardware.
Quoi qu'il en soit, le mal est fait et il faut bien composer avec. Et Grand Central présente un réel avantage une fois qu'un logiciel a été "parallélisé" : c'est le système qui se charge de gérer la répartition des opérations, quel que soit le nombre de processeurs disponibles et le nombre de tâches en cours d'exécution. Voilà qui présente un vrai bénéfice puisque c'est autant de travail que les développeurs n'ont pas à faire, et à vrai dire c'est bien au système d'exploitation de prendre en charge cette partie puisque chaque logiciel ne peut prétendre de contrôler ce que les autres font, ou encore d'intégrer tous les cas de figure matériels, de 2 à x processeurs. Pour résumer, il ne faut pas s'attendre à ce que Snow Leopard ouvre les vannes des logiciels qui exploitent les multiprocesseurs : il y a peu de chances d'en voir bien plus qu'avant, mais ceux qui seront conçus dans ce sens le feront mieux. Et l'avantage sera d'autant plus notable à mesure que le nombre de processeurs augmentera dans nos machines.
Il est d'ailleurs assez ironique de constater que, en regard de cette mise en parallèle des tâches avec les multiprocesseurs, une autre poussée va dans le sens radicalement opposé avec les GPGPU, qui seront gérés par OpenCL. Quand l'un s'attache à découper les opérations pour les répartir sur plusieurs processeurs, l'autre les unifie pour les traiter en une seule passe. C'est sans doute ce qui permet de mieux appréhender la différence fondamentale entre un CPU et un GPU. L'un dispose d'une multitude de portes étroites, quand l'autre n'en propose qu'une seule, mais béante. Jerry Harris, responsable scientifique au sein de l'équipe de développement de Photoshop, l'explique en termes imagés dans cette interview : le multiprocessing, c'est comme si on travaillait avec un troupeau d'ânes : on peut se débrouiller avec deux, mais à partir de quatre ou cinq, ça devient invivable, car ils n'en font qu'à leur tête (c'est justement là où Grand Central donnera toute sa mesure). Alors qu'un GPU se comporte plus comme un banc de poissons ou une volée d'oiseaux : plus il y en a, et mieux ça se passe.
Les GPU sont entièrement voués à traiter de larges amas de données de manière très véloce. Mais cette approche n'est pas exempte d'inconvénients. Il faut déjà que les données et les opérations s'y prêtent, ce qui n'est pas le cas de toutes. Mais même dans ce cas, les GPU étaient jusqu'ici conçus pour être autonomes : une fois qu'on leur a envoyé les données et la nature des opérations à effectuer dessus, on ne s'en préoccupe plus, le GPU les garde dans son coin, par exemple pour afficher une texture à l'écran, sans repasser par la case processeur. L'utilisation d'un GPU comme coprocesseur implique qu'on récupère le résultat pour en faire autre chose, et comme le GPU peut appliquer une seule et même opération sur un lot hétérogène de données, on est susceptible de n'en demander qu'une partie à un instant T. Or, cette opération fait figure de goulot d'étranglement, la récupération de données étant plus lente que le calcul !
Russel Williams, un autre ingénieur d'Adobe, n'est pas en reste en matière de métaphore imagée pour illustrer le cas de figure : c'est comme si vous souhaitiez imprimer un journal local pour San Jose, mais que vous le fassiez imprimer à New York, et livrer par un vieux coucou.
Comme on le voit, Grand Central et OpenCL ne sont pas des solutions miracles, mais elles sont des réponses adaptées à un environnement matériel donné. On le sait depuis longtemps, le micro-processeur à base de silicium arrive en bout de course. On réduit la résolution de gravure d'année en année, vaille que vaille, mais viendra un moment où on ne pourra pas aller au-delà. La frontière ultime et indépassable, c'est la taille de l'atome. Alors que les nanotechnologies font parler d'elles dans d'autres industries, voilà bien longtemps que, d'une certaine manière, l'informatique en est une représentante de taille. Il faudra, tôt ou tard, changer de paradigme, ce qui représentera une révolution à bien des égards. S'il y a différentes pistes de recherche qui sont très prometteuses (processeur optique, processeur quantique, supraconductivité…), elles sont pour l'heure bien loin d'être mises en application et pour certaines font plus figure de science-fiction. D'ici là il faudra bien composer avec les moyens dont nous disposons. C'est ce qu'Apple fera avec Snow Leopard.
