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 ?

[47 réactions]

La déclaration de guerre est cette fois consommée : après l'absence notoire de Flash sur iPhone, et les phrases assassines de Steve Jobs pour l'expliquer, Apple dévoile son jeu. En effet, la firme de Cupertino a tenu ce vendredi une session intitulée «Créer des applications web au "look and feel" natif avec SproutCore» lors de la WWDC.

Ce titre sibyllin révèle pourtant qu'Apple entend se positionner fortement sur le terrain des applications en ligne, pourtant déjà très concurrentiel. Entre Flash, Air, et Shockwave pour Adobe, Silverlight pour Microsoft, Ajax et consorts, il s'agit de bien choisir son cheval pour les développeurs.

Voilà donc qu'un nouveau concurrent entre sur le ring. Voici comment Apple définit SproutCore dans l'agenda public des conférences : «SproutCore est un environnement Javascript open-source, multi plate-forme, inspiré de Cocoa pour la création d'applications web qui ressemblent et se comportent comme des applications natives. Découvrez comment combiner SproutCore avec les technologies de stockage hors-ligne d'HTML5 pour livrer une expérience utilisateur de premier ordre et des performances exceptionnelles dans votre application web». Tout un programme.

Et on mesure subitement la manière dont toutes les pièces du puzzle s'assemblent : la course aux tests Acid, assurant la compatibilité transversale de standards, l'hostilité d'Apple à Flash sur iPhone, Safari 4 avec la possibilité de sauver une page web sous forme d'application indépendante et avec la vélocité du nouveau moteur JavaScript SquirrelFish, jusqu'au portage de Safari sur Windows : Apple a patiemment monté son plan de longue date.

La pomme californienne a mis tous les atouts de son côté : d'une part, elle s'affranchit du plus gros problème face à l'hégémonie de Flash, en supprimant de la donne le concept même de plugin. Ainsi, tout navigateur un tant soit peu moderne est capable de faire tourner des applications développées avec SproutCore. Ensuite, tout est fait pour attirer les développeurs : l'utilisation de JavaScript donne un vaste public potentiel pour SproutCore, y compris d'ailleurs chez les développeurs Flash puisque son langage, ActionScript, est basé sur JavaScript/ECMAscript. En outre, l'environnement de développement reprend l'architecture Model View Controller (MVC), qui au lieu du fourre-tout habituel de JavaScript, permet de lier les données à l'interface utilisateur à l'aide de contrôleurs logiques dédiés.

SproutCore permet également de construire son application avec un code remarquablement compact. D'autres fonctions, comme par exemple l'exécution automatique de commandes dès qu'une variable est modifiée, offrent aux développeurs une puissance et une souplesse appréciables et séduisantes. En outre, il ne s'agit pas simplement de présenter des pages dynamiques qui s'animent et réagissent agréablement, mais bel et bien de réaliser de véritables applicatifs capables d'effectuer un traitement de données digne de ce nom, comme par exemple le nouveau client mail intégré à Mobile.me en a fait la brillante démonstration.

Apple a donc réglé le problème du nombre d'utilisateurs finaux, du nombre de développeurs potentiels, et fait tout pour les séduire. Si en outre, SproutCore devenait le seul moyen de faire tourner des applications web dignes de ce nom sur iPhone, à l'inverse de Flash, voilà qui devrait en motiver plus d'un à se pencher sur le nouvel environnement de développement. Peut-être faut-il voir le plantage du site web de SproutCore à l'heure où nous publions ces lignes comme un signe de l'intérêt que suscite l'annonce.

Un nouveau secteur de concurrence entre Apple et Adobe est donc né. Cette dernière, qui s'est arrogé Flash au prix d'une coûteuse fusion avec Macromedia, n'entend probablement pas se laisser faire à si bon compte.