Les processeurs modernes qui équipent l'ordinateur de Monsieur Tout-le-monde sont de véritables monstres de puissance. Ainsi, un Core 2 Duo atteint-il environ 25 milliards d'opérations par seconde, soit 25 gigaflops. Certes, une paille en regard du dernier supercalculateur d'IBM, le Roadrunner (alias Bip-bip), qui vient de franchir la barre du petaflop (un million de milliards d'opérations par seconde, , soit la moitié de la capacité théorique d'un cerveau humain, ça laisse rêveur…), malgré tout le vulgum pécé est 25 fois plus rapide qu'un supercalculateur Cray 2 de 1985. Vu comme ça, on réalise subitement la marche du progrès. Pourtant, dans les grandes lignes, les ordinateurs ne font rien de radicalement différent dans le traitement automatique des données… où est donc passée toute cette grisante puissance?
Il faut dire que dans les débuts de ce qu'on appelait alors la micro-informatique, les développeurs devaient déployer des trésors d'ingéniosité pour que tout fonctionne. Imaginez-vous que les premiers Macs faisaient tenir un système et un logiciel dans 128 Ko de RAM, le tout chargé à partir d'une disquette de 400 Ko, de quoi faire rire la moindre clé USB… Il fallait donc optimiser à tout crin, écrire le code en assembleur pour gagner en vitesse, en compacité, et en efficacité, et racler tous les fonds de tiroir, pour réaliser l'impossible. C'était éreintant, et restreint à une élite. La montée en puissance des processeurs a permis de réaliser les mêmes choses, mais en se compliquant beaucoup moins la vie, ce qui a également mis la programmation à la portée de beaucoup plus de monde. Moralité, les logiciels modernes n'exploitent pas les processeurs modernes dans leurs moindres retranchements.
Qui plus est, la progression des logiciels souffre de beaucoup plus d'inertie que le matériel : ainsi au fil de leurs versions, les logiciels doivent-ils subir le poids de leur propre héritage, pour finir en véritables "bloatwares" (inflatuiciels). Certes, du côté d'Apple, les lourdes remises en question constituées par le passage du processeur 68000 au PowerPC, puis de MacOS 9 à MacOS X, et enfin au processeurs Intel, ont permis d'épurer quelque peu la ligne des applications et de moins reposer sur les acquis que dans le clan Windows, mais le constat demeure néanmoins.
Avec l'arrivée des processeurs gravés à 45 nanomètres (tout juste de quoi faire tenir 450 atomes…), on touche aux limites physiques de la course à l'augmentation pure et simple de la fréquence d'horloge des processeurs. Pour ne pas faire mentir la fameuse loi de Moore, les fabricants se sont repliés sur l'augmentation du nombre de processeurs, et de cœurs dans ces derniers. L'inconvénient, c'est que l'utilisation de cette augmentation transversale de la puissance ne peut plus se faire à l'aveugle, et qu'il faut désormais créer du code capable d'exploiter cette nouvelle donne dans l'architecture informatique : vous aurez beau augmenter le nombre de processeurs, vous n'en sentirez pas le moindre effet si les logiciels continuent à n'en exploiter qu'un seul. Apple l'a pris en compte dans ses plans avec Snow Leopard, qui intégrera des technologies comme OpenCL pour tirer parti des processeurs graphiques en tant qu'unités de calcul pures, et surtout Grand Central. Ce nom de gare n'est pas anodin, puisqu'il s'agit d'une véritable gare de triage pour les opérations "multithread" : au lieu d'une liste de courses que le processeur effectue une à une, on envoie des requêtes simultanées, et on cherche à effectuer le chemin le plus court pour chacune d'entre elle : gare à l'embouteillage!
En passant au processeur Intel, Apple vient se battre sur le même terrain que Windows, et ne peut plus guère compter sur une différence matérielle pour marquer la distance de puissance entre un Mac et un PC. Pour y remédier, il faut donc tirer le meilleur parti possible de la même architecture, ce qui est autrement plus accessible à Apple, qui a plus de maniabilité que l'ogre de Redmond. D'autant que Windows doit continuer à fonctionner sur des architectures matérielles fort hétéroclites. On mesure d'ailleurs le poids de ce handicap avec les soucis auxquels Microsoft doit actuellement faire face pour imposer Vista.
Pour mettre toutes les chances de son côté, Apple travaille également à l'efficacité structurelle de tous les logiciels créés pour le Mac, en investissant dans l'élaboration et le déploiement d'un nouveau compilateur. Comme on l'a évoqué plus haut, il est devenu quasi impossible à l'esprit humain d'écrire en langage machine, d'autant que chaque famille de processeurs dispose du sien propre. Pour y remédier, on a créé des langages intermédiaires, dits de haut-niveau, tel qu'Objective-C par exemple. Cependant il faut en passer par un compilateur pour transformer ce code en fichier binaire exécutable. Le compilateur va donc traduire le code C++ ou autres en assembleur, avec plus ou moins d'efficacité. C'est à ce niveau là qu'Apple s'investit, en aidant à la création d'un nouveau compilateur, répondant au doux nom de LLVM (pour Low-Level Virtual Machine, autrement dit machine virtuelle de bas niveau). Après SproutCore, AppleInsider s'arrête à nouveau sur une des sessions de la WWDC pour faire la lumière sur un autre projet open-source soutenu par la firme de Cupertino, et dévoiler sa stratégie.
Jusqu'ici le compilateur qui avait la bénédiction de la pomme, et qu'on retrouvait dans son outil de programmation Xcode, c'était GCC, vénérable compilateur open-source créé au milieu des années 80. LLVM quant à lui a été initié en 2000 en tant que projet de recherche à l'Université de l'Illinois par Chris Lattner, dont il diffusera la version 1.0 en 2003. Apple a commencé à participer au projet à partir de 2005, puis a embauché Lattner pour financer son travail. L'année dernière, le projet a abouti à la sortie de Clang, un compilateur autonome basé sur LLVM et mené par Apple, qui permet une compilation rapide tout en faisant une utilisation restreinte de la mémoire, en apportant des diagnostics explicites, une architecture modulaire basée sur des bibliothèques, et une intégration soignée à un environnement de développement tel que celui d'Xcode, le tout proposé sous la houlette de la licence open-source BSD. Apple proposera dorénavant LLVM au sein d'Xcode, parallèlement à GCC 4.2, laissant le choix aux programmeurs du compilateur qui conviendra le mieux à leur projet.
Dans le détail, LLVM maintient un semblant de compatibilité avec GCC tout en s'avérant bigrement plus efficace : le code compilé par LLVM ne requiert uniformément que deux tiers du temps nécessité par l'exécution du même code compilé par GCC. Un avantage de taille, donc, puisqu'une recompilation suffit à rendre tout logiciel 33% plus rapide! Pour cela LLVM tire parti des moindres optimisations pour le matériel moderne, à toutes les étapes de la compilation. Ainsi la gestion des architectures multi-processeurs et multi-cœurs, entre autres, en sera-t-elle grandement améliorée. Le compilateur introduit en outre une couche d'abstraction matérielle, qui lui vaut son titre de machine virtuelle, évitant aux développeurs de trop mettre les mains dans le cambouis. Ainsi, la version d'OpenGL implémentée dans Leopard a-t-elle été compilée à l'aide de LLVM-GCC, ce qui permet de faire fonctionner les API quelles que soient les capacités matérielles de la carte vidéo à laquelle les logiciels s'adressent. L'outil pourra également s'avérer précieux pour d'autres projets d'Apple, notamment concernant les processeurs de PA Semi qu'elle a fraîchement acquise, ainsi que pour l'iPhone de manière plus générale, étant donné que l'appareil, de moindre puissance, demande d'autant plus d'optimisation du code. En tant que principal contributeur, Apple s'emploie d'autre part à promouvoir ce compilateur auprès des chercheurs et universitaires, ainsi que de ses partenaires industriels, comme Cray dont on parlait plus haut. Elle continue en outre à participer à l'amélioration de GCC.
Pour peu que Microsoft ne fasse pas preuve de la même clairvoyance, voilà qui devrait constituer un avantage de taille pour Mac OS X, à plate-forme matérielle égale.
Pour en savoir plus sur les technologies de Snow Leopard :
- Snow Leopard : meilleure prise en charge de ZFS
- Apple à l'assaut de Flash
- Safari 4 : premiers tests de vitesse
- Steve Jobs au sujet de Snow Leopard
- Snow Leopard : fin de partie pour les PowerPC ?
Il faut dire que dans les débuts de ce qu'on appelait alors la micro-informatique, les développeurs devaient déployer des trésors d'ingéniosité pour que tout fonctionne. Imaginez-vous que les premiers Macs faisaient tenir un système et un logiciel dans 128 Ko de RAM, le tout chargé à partir d'une disquette de 400 Ko, de quoi faire rire la moindre clé USB… Il fallait donc optimiser à tout crin, écrire le code en assembleur pour gagner en vitesse, en compacité, et en efficacité, et racler tous les fonds de tiroir, pour réaliser l'impossible. C'était éreintant, et restreint à une élite. La montée en puissance des processeurs a permis de réaliser les mêmes choses, mais en se compliquant beaucoup moins la vie, ce qui a également mis la programmation à la portée de beaucoup plus de monde. Moralité, les logiciels modernes n'exploitent pas les processeurs modernes dans leurs moindres retranchements.
Qui plus est, la progression des logiciels souffre de beaucoup plus d'inertie que le matériel : ainsi au fil de leurs versions, les logiciels doivent-ils subir le poids de leur propre héritage, pour finir en véritables "bloatwares" (inflatuiciels). Certes, du côté d'Apple, les lourdes remises en question constituées par le passage du processeur 68000 au PowerPC, puis de MacOS 9 à MacOS X, et enfin au processeurs Intel, ont permis d'épurer quelque peu la ligne des applications et de moins reposer sur les acquis que dans le clan Windows, mais le constat demeure néanmoins.
Avec l'arrivée des processeurs gravés à 45 nanomètres (tout juste de quoi faire tenir 450 atomes…), on touche aux limites physiques de la course à l'augmentation pure et simple de la fréquence d'horloge des processeurs. Pour ne pas faire mentir la fameuse loi de Moore, les fabricants se sont repliés sur l'augmentation du nombre de processeurs, et de cœurs dans ces derniers. L'inconvénient, c'est que l'utilisation de cette augmentation transversale de la puissance ne peut plus se faire à l'aveugle, et qu'il faut désormais créer du code capable d'exploiter cette nouvelle donne dans l'architecture informatique : vous aurez beau augmenter le nombre de processeurs, vous n'en sentirez pas le moindre effet si les logiciels continuent à n'en exploiter qu'un seul. Apple l'a pris en compte dans ses plans avec Snow Leopard, qui intégrera des technologies comme OpenCL pour tirer parti des processeurs graphiques en tant qu'unités de calcul pures, et surtout Grand Central. Ce nom de gare n'est pas anodin, puisqu'il s'agit d'une véritable gare de triage pour les opérations "multithread" : au lieu d'une liste de courses que le processeur effectue une à une, on envoie des requêtes simultanées, et on cherche à effectuer le chemin le plus court pour chacune d'entre elle : gare à l'embouteillage!
En passant au processeur Intel, Apple vient se battre sur le même terrain que Windows, et ne peut plus guère compter sur une différence matérielle pour marquer la distance de puissance entre un Mac et un PC. Pour y remédier, il faut donc tirer le meilleur parti possible de la même architecture, ce qui est autrement plus accessible à Apple, qui a plus de maniabilité que l'ogre de Redmond. D'autant que Windows doit continuer à fonctionner sur des architectures matérielles fort hétéroclites. On mesure d'ailleurs le poids de ce handicap avec les soucis auxquels Microsoft doit actuellement faire face pour imposer Vista.
Pour mettre toutes les chances de son côté, Apple travaille également à l'efficacité structurelle de tous les logiciels créés pour le Mac, en investissant dans l'élaboration et le déploiement d'un nouveau compilateur. Comme on l'a évoqué plus haut, il est devenu quasi impossible à l'esprit humain d'écrire en langage machine, d'autant que chaque famille de processeurs dispose du sien propre. Pour y remédier, on a créé des langages intermédiaires, dits de haut-niveau, tel qu'Objective-C par exemple. Cependant il faut en passer par un compilateur pour transformer ce code en fichier binaire exécutable. Le compilateur va donc traduire le code C++ ou autres en assembleur, avec plus ou moins d'efficacité. C'est à ce niveau là qu'Apple s'investit, en aidant à la création d'un nouveau compilateur, répondant au doux nom de LLVM (pour Low-Level Virtual Machine, autrement dit machine virtuelle de bas niveau). Après SproutCore, AppleInsider s'arrête à nouveau sur une des sessions de la WWDC pour faire la lumière sur un autre projet open-source soutenu par la firme de Cupertino, et dévoiler sa stratégie.
Jusqu'ici le compilateur qui avait la bénédiction de la pomme, et qu'on retrouvait dans son outil de programmation Xcode, c'était GCC, vénérable compilateur open-source créé au milieu des années 80. LLVM quant à lui a été initié en 2000 en tant que projet de recherche à l'Université de l'Illinois par Chris Lattner, dont il diffusera la version 1.0 en 2003. Apple a commencé à participer au projet à partir de 2005, puis a embauché Lattner pour financer son travail. L'année dernière, le projet a abouti à la sortie de Clang, un compilateur autonome basé sur LLVM et mené par Apple, qui permet une compilation rapide tout en faisant une utilisation restreinte de la mémoire, en apportant des diagnostics explicites, une architecture modulaire basée sur des bibliothèques, et une intégration soignée à un environnement de développement tel que celui d'Xcode, le tout proposé sous la houlette de la licence open-source BSD. Apple proposera dorénavant LLVM au sein d'Xcode, parallèlement à GCC 4.2, laissant le choix aux programmeurs du compilateur qui conviendra le mieux à leur projet.
Dans le détail, LLVM maintient un semblant de compatibilité avec GCC tout en s'avérant bigrement plus efficace : le code compilé par LLVM ne requiert uniformément que deux tiers du temps nécessité par l'exécution du même code compilé par GCC. Un avantage de taille, donc, puisqu'une recompilation suffit à rendre tout logiciel 33% plus rapide! Pour cela LLVM tire parti des moindres optimisations pour le matériel moderne, à toutes les étapes de la compilation. Ainsi la gestion des architectures multi-processeurs et multi-cœurs, entre autres, en sera-t-elle grandement améliorée. Le compilateur introduit en outre une couche d'abstraction matérielle, qui lui vaut son titre de machine virtuelle, évitant aux développeurs de trop mettre les mains dans le cambouis. Ainsi, la version d'OpenGL implémentée dans Leopard a-t-elle été compilée à l'aide de LLVM-GCC, ce qui permet de faire fonctionner les API quelles que soient les capacités matérielles de la carte vidéo à laquelle les logiciels s'adressent. L'outil pourra également s'avérer précieux pour d'autres projets d'Apple, notamment concernant les processeurs de PA Semi qu'elle a fraîchement acquise, ainsi que pour l'iPhone de manière plus générale, étant donné que l'appareil, de moindre puissance, demande d'autant plus d'optimisation du code. En tant que principal contributeur, Apple s'emploie d'autre part à promouvoir ce compilateur auprès des chercheurs et universitaires, ainsi que de ses partenaires industriels, comme Cray dont on parlait plus haut. Elle continue en outre à participer à l'amélioration de GCC.
Pour peu que Microsoft ne fasse pas preuve de la même clairvoyance, voilà qui devrait constituer un avantage de taille pour Mac OS X, à plate-forme matérielle égale.
Pour en savoir plus sur les technologies de Snow Leopard :
- Snow Leopard : meilleure prise en charge de ZFS
- Apple à l'assaut de Flash
- Safari 4 : premiers tests de vitesse
- Steve Jobs au sujet de Snow Leopard
- Snow Leopard : fin de partie pour les PowerPC ?
