La prochaine mise à jour de Mac OS X va changer la donne sur des questions relativement pointues, et certains d'entre vous se sentent peut-être un peu perdus concernant ces domaines. Pour tous les switchers, et ceux qui se sentent un peu dépassés par certaines terminologies utilisées ici, MacGeneration vous propose une rapide séance de rattrapage didactique.
API, compilateur, kézako?
Commençons par la base : Mac OS X, comme tout système d'exploitation, est au logiciel ce que le processeur est au matériel. Il propose un certain nombre de fonctionnalités clé-en-main pour les développeurs. Par exemple, le système dispose de sa propre interface graphique, permettant aux programmeurs d'afficher simplement une fenêtre sans avoir à programmer eux-mêmes l'interface utilisateur. Au lieu de définir la façon dont les fenêtres sont censées s'afficher et fonctionner, ils n'ont qu'à faire appel à une simple commande, et le système se charge du reste. On appelle ces librairies de fonctions des API (pour Application Programming Interface). Mac OS X propose une kyrielle de fonctions, qui vont des plus basiques (gestionnaires de fichiers et de disques, interface graphique) à de plus élaborées (Core Image, Core Audio, OpenGL, Quicktime, etc). Il faut bien comprendre que le Finder n'est que la partie émergée de l'iceberg, l'essentiel de Mac OS X réside en fait dans ces fonctions qui se retrouvent utilisées dans toute la logithèque du Mac.
En matière de programmation, on écrit un code qui va tirer parti d'une part du matériel, en lançant des ordres au processeur de manière autonome, et d'autre part en s'adressant aux API. Pour fonctionner, un logiciel doit parler au processeur dans son langage, le langage machine, appelé également assembleur. L'inconvénient de l'assembleur, c'est qu'il est assez compliqué à utiliser, et surtout que chaque famille de processeur dispose de son propre langage : ainsi, pour créer un logiciel pour différent processeurs, il fallait tout réécrire. C'est pour cette raison qu'on a trouvé un moyen intermédiaire : un langage plus simple à mette en œuvre, et universel, qui fonctionne pour tous les processeurs. Mais pour que ce code fonctionne, il faut un traducteur, qui va convertir le langage universel en langage machine spécifique. C'est ce qu'on appelle un compilateur, qui va traduire le code en C par exemple en langage machine pour différents processeurs.
Charbon ou Cacao?
Jusqu'à Mac OS 9, les développeurs programmaient majoritairement en C++. Or suite au rachat de NeXT par Apple, il a fallu passer en Objective-C, le langage de prédilection du système de Steve Jobs, afin de pouvoir s'adresser à ses API. Voilà qui posait un véritable problème pour la transition : on se retrouvait condamné à tout reprogrammer et à avoir deux versions différentes d'un même logiciel pour Mac OS 9 et pour Mac OS X. Pour pallier ce problème, Apple a fourni aux développeurs un jeu d'API intermédiaire dans Mac OS X, appelé Carbon, qui était rétrocompatible avec Mac OS 9. Ainsi, selon que le logiciel fonctionnait sur Mac OS 9 ou Mac OS X, les programmeurs s'adressaient aux mêmes commandes, et pouvaient continuer à programmer en C++. Le jeu d'API destiné à l'Objective-C, quant à lui, a été appelé Cocoa. Sachant que Mac OS 9 était voué à disparaître, Carbon n'a été que peu mis à jour, Apple s'étant focalisé sur les fonctions plus avancées de Cocoa. En quelque sorte, Carbon a été le plus petit dénominateur commun entre Mac OS 9 et Mac OS X : seules les fonctions qui étaient communes ou avaient un équivalent dans les deux systèmes étaient concernées. Pour vraiment tirer parti des spécificités de Mac OS X, il fallait donc se résoudre à passer à Objective-C et à Cocoa, ce qui a été fait plus volontiers une fois que Mac OS 9 et Classic sont passés à la postérité. (A noter que Cocoa peut également être exploité à partir d'autres langages, comme Java, Ruby ou Python).
Chaque mise à jour du système apporte de nouvelles fonctions aux développeurs, et améliorent les anciennes : ainsi, si un logiciel fait appel à une API qui se voit améliorée, le logiciel en tire parti automatiquement sans la moindre modification. Si Apple change l'interface utilisateur, tous les logiciels s'afficheront automatiquement dans cette nouvelle interface, pour peu que les commandes soient identiques. De même, les librairies s'appellent les unes les autres, et par effet domino, profitent à toute l'offre logicielle de proche en proche.
L'ironie du sort, c'est que le Finder lui-même faisait jusqu'à maintenant appel à Carbon. Apple procède à la bascule vers Cocoa pour Snow Leopard, ce qui lui permettra d'exploiter les fonctions les plus moderne de Mac OS X. Il n'est d'ailleurs pas impossible qu'elle les mettre à profit dans de nouvelles fonctions du Finder. On peut d'ailleurs s'attendre à ce que Carbon soit abandonné à moyen terme, ce qui permettra à Apple de se focaliser entièrement sur Cocoa, et d'alléger le système de toute sa partie historique. Elle encourage d'ailleurs tous les développeurs à procéder à la bascule depuis quelques temps maintenant. Depuis l'introduction de la première version client de Mac OS X en 2001, on peut en effet considérer que la transition est consommée.
Multi-quoi?
Penchons-nous maintenant sur l'architecture matérielle : les fabricants de processeurs on longtemps fait la "course au mégahertz". C'était celui qui proposerait le plus grand nombre de cycles de calcul par seconde qui prendrait la tête du marché. Les contraintes matérielles ont fini par mettre un terme à cette course, et pour continuer à gagner en puissance, les constructeurs ont proposé des architectures multi-processeurs, et multi-core, c'est à dire qu'un processeur pouvait également contenir plusieurs cœurs logiques, en d'autre termes des processeurs "virtuels". Le problème, c'est que jusqu'ici l'augmentation de la puissance brute des processeurs était mise à profit automatiquement par les logiciels, alors que les architectures multiprocesseurs doivent être prises en compte spécifiquement par les logiciels pour être exploitées pleinement.
Ainsi, si un logiciel veut tirer tout le jus de nos machines, il faut qu'il divise ses tâches non seulement sur la totalité des processeurs disponibles, mais également sur tous leurs cores. Ajoutez à cela le fait que chaque core peut procéder à des opérations multi-thread, c'est à dire des listes de tâches exécutables simultanément, et on en vient vite à un casse tête pour le programmeur, d'autant que chaque tâche de chaque application est susceptible d'entrer en concurrence avec celles des autres, sans parler du fait que certaines tâches ont besoin du résultat d'une autre pour pouvoir être effectuées. Voilà qui rend la programmation bien délicate, et vous comprenez sans doute mieux pourquoi si peu de logiciels tirent parti de plus d'un processeur, ou s'ils le font, ça n'est restreint qu'à des fonctions bien délimitées. C'est notamment pour répondre à cette problématique qu'Apple a mis sur pied Grand Central, un jeu d'API de Snow Leopard qui sera la gare de triage de toutes ces opérations, permettant aux développeurs de mieux exploiter les architectures multi-processeurs plus simplement. On peut donc espérer de voir nos machines mieux exploitées par les logiciels qui feront usage de Grand Central sous Snow Leopard.
GPGPU… gné?
Mais il est une autre puissance de calcul qui reste peu exploitée, et la source se trouve sur les processeurs des cartes graphiques : ces processeurs hautement spécialisés sont conçus pour traiter très rapidement un flot conséquent de données. Initialement, leurs compétences en matière de 3D étaient entièrement dévolues à la résolution de tâches complexes, comme l'interpolation (permettant de lisser les textures des modèles 3D lorsque leur affichage dépasse leur résolution native), la trigonométrie (au cœur des calculs d'affichage en perspective et de géométrie dans l'espace), etc, chaque nouvelle génération étant capable d'afficher de plus en plus de polygones en simultané, leur attribution mémoire grandissant de pair permettant également de gérer des textures de plus grande résolution. Avec l'arrivée des pixels shaders et des vertex shaders, les cartes sont devenues à même d'effectuer des simulations extrêmement complexes, comme la réfraction de la lumière à travers l'eau ou un verre dépoli par exemple. Ce sont ces dernières fonctions qui ont complété le tableau pour faire de ces processeurs spécialisés des processeurs à usage général. En effet, en faisant "croire" à la carte que les données qu'on lui transmet sont des textures, on peut effectuer sur ces données des calculs à grande échelle de façon extrêmement véloce: le GPGPU était né (pour General Purpose Graphical Processing Unit, unité de calcul graphique à usage général). Mais on retombait dans les mêmes travers que pour les processeurs, chaque constructeur proposant son propre jeu d'API pour exploiter ses cartes graphiques. C'est ce à quoi Apple a cherché à mettre bon ordre avec OpenCL, un jeu d'API qu'elle a mis à disposition de toute l'industrie, en en faisant un standard ouvert, à même de fonctionner sur toutes les cartes. Il se retrouvera au cœur de Snow Leopard, permettant à tous les développeurs d'exploiter la puissance des cartes graphiques des Macs, sans se soucier de leur marque ou de leurs capacités.
Voilà, avec ces quelques éléments, vous avez toutes les bases requises pour comprendre en quoi consistent les évolutions majeures de Snow Leopard, et ce qu'elles pourront vous apporter au quotidien. En bref, nos machines seront susceptibles d'être mieux exploitées par les logiciels. Il reste à voir dans quelle mesure nous gagneront en vitesse, et on peut être certains qu'un flot de comparatifs et de tests seront effectués à la sortie du prochain système d'Apple, ainsi que des applications qui seront mises à jour pour en tirer parti, afin d'en mesurer les acquis.
API, compilateur, kézako?
Commençons par la base : Mac OS X, comme tout système d'exploitation, est au logiciel ce que le processeur est au matériel. Il propose un certain nombre de fonctionnalités clé-en-main pour les développeurs. Par exemple, le système dispose de sa propre interface graphique, permettant aux programmeurs d'afficher simplement une fenêtre sans avoir à programmer eux-mêmes l'interface utilisateur. Au lieu de définir la façon dont les fenêtres sont censées s'afficher et fonctionner, ils n'ont qu'à faire appel à une simple commande, et le système se charge du reste. On appelle ces librairies de fonctions des API (pour Application Programming Interface). Mac OS X propose une kyrielle de fonctions, qui vont des plus basiques (gestionnaires de fichiers et de disques, interface graphique) à de plus élaborées (Core Image, Core Audio, OpenGL, Quicktime, etc). Il faut bien comprendre que le Finder n'est que la partie émergée de l'iceberg, l'essentiel de Mac OS X réside en fait dans ces fonctions qui se retrouvent utilisées dans toute la logithèque du Mac.
Charbon ou Cacao?
Jusqu'à Mac OS 9, les développeurs programmaient majoritairement en C++. Or suite au rachat de NeXT par Apple, il a fallu passer en Objective-C, le langage de prédilection du système de Steve Jobs, afin de pouvoir s'adresser à ses API. Voilà qui posait un véritable problème pour la transition : on se retrouvait condamné à tout reprogrammer et à avoir deux versions différentes d'un même logiciel pour Mac OS 9 et pour Mac OS X. Pour pallier ce problème, Apple a fourni aux développeurs un jeu d'API intermédiaire dans Mac OS X, appelé Carbon, qui était rétrocompatible avec Mac OS 9. Ainsi, selon que le logiciel fonctionnait sur Mac OS 9 ou Mac OS X, les programmeurs s'adressaient aux mêmes commandes, et pouvaient continuer à programmer en C++. Le jeu d'API destiné à l'Objective-C, quant à lui, a été appelé Cocoa. Sachant que Mac OS 9 était voué à disparaître, Carbon n'a été que peu mis à jour, Apple s'étant focalisé sur les fonctions plus avancées de Cocoa. En quelque sorte, Carbon a été le plus petit dénominateur commun entre Mac OS 9 et Mac OS X : seules les fonctions qui étaient communes ou avaient un équivalent dans les deux systèmes étaient concernées. Pour vraiment tirer parti des spécificités de Mac OS X, il fallait donc se résoudre à passer à Objective-C et à Cocoa, ce qui a été fait plus volontiers une fois que Mac OS 9 et Classic sont passés à la postérité. (A noter que Cocoa peut également être exploité à partir d'autres langages, comme Java, Ruby ou Python).
Chaque mise à jour du système apporte de nouvelles fonctions aux développeurs, et améliorent les anciennes : ainsi, si un logiciel fait appel à une API qui se voit améliorée, le logiciel en tire parti automatiquement sans la moindre modification. Si Apple change l'interface utilisateur, tous les logiciels s'afficheront automatiquement dans cette nouvelle interface, pour peu que les commandes soient identiques. De même, les librairies s'appellent les unes les autres, et par effet domino, profitent à toute l'offre logicielle de proche en proche.
L'ironie du sort, c'est que le Finder lui-même faisait jusqu'à maintenant appel à Carbon. Apple procède à la bascule vers Cocoa pour Snow Leopard, ce qui lui permettra d'exploiter les fonctions les plus moderne de Mac OS X. Il n'est d'ailleurs pas impossible qu'elle les mettre à profit dans de nouvelles fonctions du Finder. On peut d'ailleurs s'attendre à ce que Carbon soit abandonné à moyen terme, ce qui permettra à Apple de se focaliser entièrement sur Cocoa, et d'alléger le système de toute sa partie historique. Elle encourage d'ailleurs tous les développeurs à procéder à la bascule depuis quelques temps maintenant. Depuis l'introduction de la première version client de Mac OS X en 2001, on peut en effet considérer que la transition est consommée.
Multi-quoi?
Penchons-nous maintenant sur l'architecture matérielle : les fabricants de processeurs on longtemps fait la "course au mégahertz". C'était celui qui proposerait le plus grand nombre de cycles de calcul par seconde qui prendrait la tête du marché. Les contraintes matérielles ont fini par mettre un terme à cette course, et pour continuer à gagner en puissance, les constructeurs ont proposé des architectures multi-processeurs, et multi-core, c'est à dire qu'un processeur pouvait également contenir plusieurs cœurs logiques, en d'autre termes des processeurs "virtuels". Le problème, c'est que jusqu'ici l'augmentation de la puissance brute des processeurs était mise à profit automatiquement par les logiciels, alors que les architectures multiprocesseurs doivent être prises en compte spécifiquement par les logiciels pour être exploitées pleinement.
Ainsi, si un logiciel veut tirer tout le jus de nos machines, il faut qu'il divise ses tâches non seulement sur la totalité des processeurs disponibles, mais également sur tous leurs cores. Ajoutez à cela le fait que chaque core peut procéder à des opérations multi-thread, c'est à dire des listes de tâches exécutables simultanément, et on en vient vite à un casse tête pour le programmeur, d'autant que chaque tâche de chaque application est susceptible d'entrer en concurrence avec celles des autres, sans parler du fait que certaines tâches ont besoin du résultat d'une autre pour pouvoir être effectuées. Voilà qui rend la programmation bien délicate, et vous comprenez sans doute mieux pourquoi si peu de logiciels tirent parti de plus d'un processeur, ou s'ils le font, ça n'est restreint qu'à des fonctions bien délimitées. C'est notamment pour répondre à cette problématique qu'Apple a mis sur pied Grand Central, un jeu d'API de Snow Leopard qui sera la gare de triage de toutes ces opérations, permettant aux développeurs de mieux exploiter les architectures multi-processeurs plus simplement. On peut donc espérer de voir nos machines mieux exploitées par les logiciels qui feront usage de Grand Central sous Snow Leopard.
GPGPU… gné?
Mais il est une autre puissance de calcul qui reste peu exploitée, et la source se trouve sur les processeurs des cartes graphiques : ces processeurs hautement spécialisés sont conçus pour traiter très rapidement un flot conséquent de données. Initialement, leurs compétences en matière de 3D étaient entièrement dévolues à la résolution de tâches complexes, comme l'interpolation (permettant de lisser les textures des modèles 3D lorsque leur affichage dépasse leur résolution native), la trigonométrie (au cœur des calculs d'affichage en perspective et de géométrie dans l'espace), etc, chaque nouvelle génération étant capable d'afficher de plus en plus de polygones en simultané, leur attribution mémoire grandissant de pair permettant également de gérer des textures de plus grande résolution. Avec l'arrivée des pixels shaders et des vertex shaders, les cartes sont devenues à même d'effectuer des simulations extrêmement complexes, comme la réfraction de la lumière à travers l'eau ou un verre dépoli par exemple. Ce sont ces dernières fonctions qui ont complété le tableau pour faire de ces processeurs spécialisés des processeurs à usage général. En effet, en faisant "croire" à la carte que les données qu'on lui transmet sont des textures, on peut effectuer sur ces données des calculs à grande échelle de façon extrêmement véloce: le GPGPU était né (pour General Purpose Graphical Processing Unit, unité de calcul graphique à usage général). Mais on retombait dans les mêmes travers que pour les processeurs, chaque constructeur proposant son propre jeu d'API pour exploiter ses cartes graphiques. C'est ce à quoi Apple a cherché à mettre bon ordre avec OpenCL, un jeu d'API qu'elle a mis à disposition de toute l'industrie, en en faisant un standard ouvert, à même de fonctionner sur toutes les cartes. Il se retrouvera au cœur de Snow Leopard, permettant à tous les développeurs d'exploiter la puissance des cartes graphiques des Macs, sans se soucier de leur marque ou de leurs capacités.
Voilà, avec ces quelques éléments, vous avez toutes les bases requises pour comprendre en quoi consistent les évolutions majeures de Snow Leopard, et ce qu'elles pourront vous apporter au quotidien. En bref, nos machines seront susceptibles d'être mieux exploitées par les logiciels. Il reste à voir dans quelle mesure nous gagneront en vitesse, et on peut être certains qu'un flot de comparatifs et de tests seront effectués à la sortie du prochain système d'Apple, ainsi que des applications qui seront mises à jour pour en tirer parti, afin d'en mesurer les acquis.
