Snow Leopard : pas de miracle en vue ?

Arnaud de la Grandière |
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.

avatar philus | 
@ Biniou, Xilix Bon, on est tous d'accord en fait. Si je résume, Os X devrait bien profiter de grand centrale, la puissance apportée ne suffira peut-être pas encore à avoir une réactivité parfaite de l'ordi (il faut pour ça ajouter d'autres chip qui ne sont pas présent actuellement dans les micro, bien qu'ayant existé à une époque lointaine où l'on réfléchissait plus que maintenant à l'architecture matérielle et logicielle). Il est (heureusement) possible de faire encore évoluer nos concepts en matière de hard et de soft, ce qui ne fera pas de mal quand on sera dans 'le mur du silicium'. Peut-être à cette époque une conception plus sérieuse de que doit être un noyau pourra débarquer sur nos micros. Ravis d'avoir discuté avec des passionnés ayant des connaissances autres que le copier/coller (comme le sont la majorités des lecteurs de mac gé, bien entendu)
avatar Psylo | 
Ca fait du bien d'avoir des commentaires avec des vrais infos, et des arguments appuyés. Ca change des debats steriles, des chasses aux trolls et des éternels combats d'ego. Merci les gars.
avatar Anonyme (non vérifié) | 
Bon je vais en rajouter une couche mais la programmation pour système multicoeur, en parallèle, n'a rien à voir avec ce que vous dites dans votre articles. D'une le nombre de coeur importe peu, de deux contrairement à ce que vous pensez les instructions peuvent être facilement mise en parallèle, car ce n'est pas des instructions de haut niveau du style "une copie de dossier, ou l'ouverture d'une application ,mais des instructions de bas niveau comme un décalage de bits, un saut ou une addition. Trois, le disque dur et la mémoire vive ne peuvent être considérés comme des goulots d'étranglement puisque les instructions utilisées lors du parallélisme sont lu depuis des registres et différents caches (je simplifie volontairement même si bien sur la vitesse de la ram joue mais moins que l'on ne pense). Je pourrai ajouter des points 4 5 6 sur les caches préemptif et leurs rôles dans le parallélisme, la compilation et le rôle du jeu d'instruction ou encore la prédiction. Vous avez raison sur un point une application développée pour du monoprocesseur passe difficilement en un claquement de doigt en multi processeur mais avec le GrandCentral, mais cela va quand même permettre d'accélérer les applis, car une partie du byte code peut être parallélisée sans optimisation particulière.
avatar Anonyme (non vérifié) | 
personnellement, il y a un truc que je ne comprends pas, mais à dire vrai, je n'y connais rien, donc si c'est trop compliqué, ne vous sentez pas obliger de m'expliquer. en gros, si j'ai bien compris, "grand central" permet de gérer la répartition des tâches entre les différents processeurs sans que les applications aient à s'en charger. donc... à partir de ce moment-là, je ne vois pas pourquoi certaines applications devraient être codées d'une certaine manière pour exploiter la puissance du parallélisme ou non des processeurs puisque "grand central" s'en charge.
avatar hawker | 
Qu'est ce c'est cet article ? Bien évidement personne ne s'attend a voir les perfs se décupler sous SL. Un gain de 20 pourcent serait déjà super. Donc pas vraiment la peine d'enfoncer la réputation de SL avec des titre d'article pareils pour des articles qui ne font que contredire des espérances que personne n'a. Moi ce que j'attends de Snow Leopard, c'est d'être super léger, encore meilleur sur les petits points qui facilitent l'utilisation de tous les jours, d'être encore plus performant, et d'être plus stable (? a la 10.6.1 je pense espérer). On sait bien que ce n'est pas avec une simple nouvelle API de gestion, si bonne soit elle, que les perfs vont se multiplier. D'ailleurs, le parallélisme des logiciels et des processeurs se fera en passant par une nouvelle architecture (en clair dans quelques années fini le bon vieux x86...), et c'est la qui faudra faire de tels articles. La meilleur chose a faire, c'est attendre la présentation officielle, voir la commercialisation et après on parlera de tout ça.
avatar Québec | 
Outre le vocabulaire technique, faut vraiment le lire 2 fois ce texte pour tout comprendre, pas un mot à dire le type s'y connait en vocabulaires, mais pas celui de tous les jours. Bon en gros pas d'évolution avant plusieurs années, lorsque les programmeurs auront fait de grosses màj de leur logiciel, ou simplement d"arriver à lire et comprendre ce texte, hihi.
avatar Dr_cube | 
Très bon article. Un développeur de logiciels ne sait pas s'il va y avoir 2 ou 32 ou 200 processeurs sur la machine. Il doit donc, dans la mesure du possible, mettre au point une solution qui passe à l'échelle. Il n'est donc théoriquement pas plus difficile de faire un logiciel pour 2 processeurs que pour 200. Bien sûr, d'autres contraintes s'appliquent, puisqu'il y a un coût en communication. En effet, les tâches sont souvent liées, et les processeurs doivent donc se synchroniser pour récupérer des résultats et en envoyer d'autres. Mais ces coûts se calculent, et il y a de nombreux modèles pour cela. Parfois, les processeurs sont reliés entre eux selon une topologie particulière (grille, tore, anneaux...), et les développeurs se servent de cette topologie pour créer leurs algorithmes. Avec certains outils, on peut créer facilement sa propre topologie "virtuelle", et ainsi avoir l'illusion que les processeurs sont organisés d'une certaine manière. Bref, il y a pleins d'outils (logiciels ou conceptuels) qui permettent de mettre au point "facilement" des algorithmes parallèles et de prévoir leur coût. Ca reste selon-moi une véritable torture pour l'esprit, mais certains y arrivent très bien. Un simple produit matriciel devient une prise de tête incroyable lorsqu'on veut le faire en parallèle (essayez et vous verrez !). Mais le gain est considérable. Dans tous les cas, il faut bien comprendre qu'il y a plusieurs grains de parallélisme : - entre les processus, - entre les tâches indépendantes d'un processus, - dans une même tâche, calculs indépendants (boucles...), - piplelinage d'instructions - ... C'est en mettant du parallélisme à tous les niveaux qu'on arrivera à des solutions vraiment efficaces. Même si pour un logiciel donné, Snow Leopard n'améliorera peut-être pas grand chose, il sera peut-être possible de lancer plus de logiciels/calculs en même temps et d'avoir les résultats plus rapidement.
avatar kissscoool | 
Oui enfin, le parallélisme c'est pas nouveau non plus. J'ai l'impression que les auteurs de cet articles tombent des nues en disant que ça ne s'applique pas à n'importe quelle donnée et que ça nécessite de penser le programme d'une certaine façon par moment. Après lecture de l'article, je ne vois pas en quoi ça va être plus compliqué qu'avant de faire un programme parallèle. Je pense d'ailleurs qu'un programme qui l'était déjà (comme beaucoup devraient l'être), ne demandera pas trop trop de gymnastique pour adapter ça avec OpenCL. Le seul inconvénient est sûrement le rapatriement des données depuis les GPU vers la mémoire centrale ou CPU, ce qu'il faudra éventuellement anticiper...
avatar lefoudupuit | 
ou le parallélisme permettra d'exploiter une nouvelle architecture basé sur la spécialisation des processeurs (1 pour chaque fonction de base) comme le conçoit le fabriquant qualcomm avec ses solutions ARM l'avantage est que le besoin de puissance n'est plus nécessaire (d'où des gains de consommation, meilleure réactivité) et celà permettra de garder les procédés actuels sans avoir à suivre la loi de moore. le temps gagné permettra de trouver des solutions viables industriellement (ordinateur quantique ou autres) d'ailleurs cette spécialisation est une technologie maitrisée par PA semi... tiens donc!!
avatar biniou | 
Pas de stress. Au moins on pourra faire tourner 20 threads en parallèle. C'est extrêmement compliqué de couper un logiciel en bloc d'instructions surtout qu'il faut habituellement plus de blocs à calculer que de processus parallèles de calcul (afin d'être optimum : cf. documentation Cuda). Ca servira, ça c'est sûr et le multicore/processeur aussi. Ce qu'il manque c'est une réelle synchronisation dans l'exécution des threads !
avatar Dr_cube | 
@ biniou : Qu'est-ce que tu entends exactement par "une réelle synchronisation des threads" ? Par définition, s'il y a plusieurs unités d'exécution, on a forcément de l'asynchronisme. Il y a mille méthodes pour synchroniser des flots d'exécution, ou pour protéger des données qui pourraient être lues/écrites par plusieurs entités en même temps.

Pages

CONNEXION UTILISATEUR