Lexique : si vous avez raté le début…

Arnaud de la Grandière |
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.
avatar Moonwalker | 
Bonne idée que cet article.
avatar raoultcool | 
Excellent article !!!!!
avatar Anonyme (non vérifié) | 
Extrêmement intéressant, bonne idée!
avatar laurent_iMac | 
J'ai l'impression que depuis quelques semaines/mois MacGé se"bonifie" vraiment : des labos, des bidouilles, des analyses ainsi que des articles très pointus mais en même temps compréhensible à foison. Vous avez mangé quoi au p'tit déj. ? Du Snow Léopard à la louche ou tout autres lignes de codes qui fait "pétiller" à ce point vos neurones ? :-) En tout cas .... bravo, continuez comme cela à vous faire plaisir et par là même à nous lecteurs/lectrices de ce site.
avatar leonzeur | 
bravo !! hyper bien expliqué même pour des ignares comme moi dans tout ce domaine !! on les savoure les derniers articles de mac gé !! vive la qualité
avatar jibe356 | 
Excellent article!
avatar lord danone | 
C'est cette fois confirmé, macgeneration est passé de simple site de news, à un magazine mac en ligne. Bravo à tous les rédacteurs, continuez ainsi :)
avatar ericalvarez | 
Vraiment très intéressant! Merci : ))
avatar ispeed | 
Moi qui suis très critique je dis bravo à Arnauld de La Grandière enfin un article très bien fait et sans flagornerie Continuez comme ça, Bravo
avatar Jean Claude Dusse | 
Glop ! Glop !
avatar Le docteur | 
Génial cet article. Merci pour la cession de rattrapage !!
avatar docdoc18 | 
Bonne initiative, l'article est très complet et permet un bon tour d'horizon sur la question. A noter que l'essentiel des applications que nous utilisons aujourd'hui ne sont pas taillée pour l'utilisation de plusieurs coeurs et que l'apparition de SL ne va rien changer pour nous pendant plusieurs mois, voir 1 à 2 ans selon les applications. A moins que Apple se décide de mettre à jour tous ses logiciels dans ce sens. Ca se serait top!
avatar ricochet | 
Bravo MacGe ! Décidément incontournable ... Merci pour cet éclairage du soft et du hard.
avatar OuiOui | 
Je rejoins les autres, l'article est très bien construit et pertinent, merci macGé ^^ Continuez comme ça = )
avatar coincoin13 | 
Quand on voit que ne nombreuses applications, notamment certains mastodontes, sont encore en Carbon pour leur plus grande partie (Photoshop par exemple) en 2009, j'ai quelques inquiétudes avoir voir mes programmes utiliser les nouvelles API Apple avant quelques années. Le gros fantasme est que beaucoup pense que SL, à court terme, va tout de suite enfin pouvoir donner tout son sens à l'osmose hardware/software, et booster leur machine instantanément. Au niveau de l'Os en lui même, je pense que l'on peut faire confiance à Apple, mais niveau appli, "Grand Central" risque de ne pas avoir beaucoup de trafic, ni ne voyageurs pendant un certain laps de temps. D'ailleurs on ne sait pas vraiment avec l'article si GC et OCL exigent que l'application soit exclusivement écrite en cocoa ou non... Mais c'est une restructuration sur le long terme, qui va mettre quelques années à porter ses fruits chez les éditeurs, en espérant que les plus petits entrent dans le jeu plus rapidement. Dans l'idéal, après PPC, ils devraient virer carbon de SL, ou faire un mode de compatibilité à la Classic. Faire table rase du passé quoi...
avatar iDanny | 
Sympa l'article, ça m'a au moins appris ce qu'est Cocoa par exemple :) Par contre cette phrase est incompréhensible, et en plus elle est mal construite: [i]"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."[/i] Si on développe la 2ème partie votre phrase, ça donne [i]"un code qui va tirer parti en s'adressant aux API"[/i] : ça ne veut rien dire ! ^_o Je suppose que vous vouliez dire [i]"tirer parti du matériel, d'une part en lançant des ordres au processeur de manière autonome, et d'autre part en s'adressant aux API."[/i] ? Ce qui est déjà mieux :) Sinon en page 2, vous écrivez : [i]"multi-core, c'est à dire qu'un processeur pouvait également contenir plusieurs cœurs logiques, en d'autre termes des processeurs 'virtuels'."[/i] Pourtant j'ai toujours pensé qu'il s'agissait de cœurs [u]physiquements séparés[/u]... ce que confirme l'article de Wikipedia dès la 1ère ligne ! : [b][url]http://fr.wikipedia.org/wiki/Microprocesseur_multi_c%C5%93ur[/url][/b]
avatar Anonyme (non vérifié) | 
Merci macGé pour ces précisions plus qu'interéssantes continuez comme ça pour notre plaisir à tous!!
avatar Anonyme (non vérifié) | 
Pffff trop facile j'savais déjà tout :-)
avatar Hasgarn | 
Très bonne initiative. Les derniers articles permettent vraiment de se rendre compte des avancés et innovations qu'Apple tente de mettre en place. Même s'il est clair que beaucoup d'applications (Adobe) ne saisiront les bénéfices de ces changement, ça laisse les coudés franches à de petits éditeurs à qui j'ai commencé à accorder ma confiance (Lineform, MovieGate, Pixelmator, iCalamus…) ou des développeurs qui font du gratuiciels (Drawberry, LiteIcon et j'espère vraiment un jour des Gimp, Inkscape natif) de ruer un peu dans les brancards. qu'ils fournissent des petites perles super efficaces et véloces qui feront, je l'espère vraiment même si c'est du rêve éveillé, frémir les grands qui ne pense qu'à leur hégémonie. J'aimerai qu'Adobe, dont la toute puissance, l'attitude pécuniaire, la lourdeur des applications, qui m'ont carrément débecté, trouve un concurrent digne de ce nom sur le marché. Très clairement, je voudrai qu'Apple leur face un grand croche patte avec une suite graphique, puisque qu'ils ont déjà commencé avec Aperture et Final Cut. Mais ça va être très dur…
avatar tomystyle | 
comment fait ton pour signaler une news ????? regarde ce que annonce lci !!!!!! INFO LCI RADIO : Apple se lance dans les téléviseurs LCI RADIO - Apple et LG ont signé un accord pour produire ensemble des téléviseurs. Avec quel design ? Réponse, au troisième trimestre 2009. Cédric INGRAND
avatar Dr_cube | 
Notez qu'Apple utilise plutôt le terme "Framework" au lieu d'"API", même si ça reste sensiblement la même chose. L'article est très bon, mais je trouve que la première partie n'est pas très claire. En effet, il aurait peut-être fallut expliquer plus précisément ce qu'est avant tout un système d'exploitation : un gestionnaire de ressources matérielles, une machine virtuelle. Mac OS X n'est rien de plus qu'une machine virtuelle qui permet de s'abstraire des difficultés de la machine physique, et qui donne l'illusion aux logiciels (aux processus) qu'ils s'exécutent sur une autre machine que la machine physique. En particulier, cette machine virtuelle donne l'illusion à chaque processus qu'il est seul à s'exécuter et qu'il dispose de toutes les ressources, alors que c'est faux. Il est alors nécessaire de gérer l'accès concurrent aux ressources, et c'est le rôle du système de protéger efficacement les ressources. Les systèmes utilisent généralement deux modes : un mode utilisateur, et un mode superviseur, qui permet d'atteindre le noyau (kernel) du système d'exploitation. Pour faire simple, dans le mode utilisateur on est seul et on a des droits limités, mais le noyau est partagé par tous les processus et donne tous les droits, et un simple bug pendant qu'on est dans le noyau conduit à l'écran bleu (ou au Kernel Panic sur Mac). Mac OS X est un système très particulier, dans la mesure où il utilise un micro-noyau, c'est à dire un noyau minimal. A l'inverse, Windows utilise une architecture monolithique et le noyau est énorme. En particulier, dans Mac OS X les drivers sont en dehors du noyau, alors qu'ils sont à l'intérieur du noyau sur Windows. Ainsi, un simple bug dans un driver conduit un écran bleu sur Windows, alors qu'il n'a aucune gravité sur Mac. On pense actuellement que 85% des écrans bleus sur Windows sont dus à des bugs de drivers. C'est en grande partie grace à son micro-noyau que Mac OS X est considéré comme fiable.
avatar Christophe Laporte | 
tu parles d'une exclu : https://www.macg.co/news/voir/133690/ou-l-on-reparle-d-un-televiseur-apple mais on est plus dans le domaine de la spéculation que de la rumeur
avatar Philactere | 
très bon article en effet, et intéressant. J'ai enfin appris ce que sont OpenCL et Grand Central et également la raison du nom de ce dernier :-) Je tire la conclusion suivante de cet article en mettant en perspective OpenCL et Grand Central : Si par le passé le hardware était souvent limitant face à la gourmandise des logiciels cela semble avoir changé. J'ai l'impression que les avancées technologiques en matière de processeurs mettent à disposition du logiciel une puissance que celui-ci a du mal a exploiter, d'où OpenCL et Grand Central. Bref là où par le passé le matériel courait derrière le logiciel pour tenter de lui offrir ce qu'il demandait aujourd'hui on s'efforce de trouver des solutions pour faire quelque chose de cette puissance sous le capot ! Un spécialiste dans la salle pour confirmer ou infirmer cette conclusion ?
avatar Dr_cube | 
@ Philactere : Avant les processeurs multi-core d'Intel (Core Duo...), nos Mac/PC étaient équipés de processeurs à une seule unité d'exécution. Cela signifie qu'une seule instruction à la fois pouvait être exécutée. (Ce n'est pas tout à fait vrai car le pipelinage permet depuis longtemps d'exécuter plusieurs instructions en même temps, mais je simplifie ^^). Tu n'es pas sans savoir que plusieurs processus s'exécutent en parallèle (ouvre le Moniteur d'activités pour t'en convaincre). Mais avec un processeur à une seule unité d'exécution, un seul processus à la fois est réellement en train de s'exécuter à chaque instant, pendant que les autres sont en attente. Le temps est alors découpé en tranches, et un ordonnanceur se charge de donner un peu de temps à chaque processus, de manière équitable. C'est ainsi que tu pouvais lancer plusieurs logiciels, et les voir s'exécuter en parallèle, mais c'était une illusion. Le passage d'un processus à un autre (i.e. le "changement de contexte") est coûteux en temps, et il faut donc trouver de bons compromis. Avec de tels processeurs à une seule unité d'exécution, l'une des manières d'améliorer les performances d'un logiciel est d'attendre que les processeurs deviennent plus rapides. Avec un processeur à 2Ghz, l'horloge du processeur est beaucoup plus rapide qu'avec un processeur à 700Mhz, et il est donc possible d'exécuter plus d'instructions pendant la même durée, et donc d'accélérer l'exécution des processus. Le problème est qu'il devenait trop coûteux en énergie d'accélérer l'horloge des processeurs, et on a atteint la limite raisonnable.
avatar Dr_cube | 
D'après Intel, augmenter la vitesse d'un processeur requiert beaucoup d'énergie. Mais baisser la vitesse d'un processeur implique de fait une diminution conséquente de la consommation d'énergie. Considérons un processeur dont la performance est de 1.0, et dont la consommation d'énergie est de 1.0. Over-clocker un tel processeur de 20% donne une performance de 1.10 et une consommation de 1.70. Under-clocker un tel processeur de 20% donne une performance de 0.85 et une consommation de 0.50. Ainsi, en utilisant deux processeurs under-clockés de 20%, on obtient une performance de 1.70, et une consommation de 1.0 ! On consomme autant qu'avec un seul processeur à vitesse normale, mais on a une bien meilleure performance ! Ces chiffres donnés par Intel (je peux mettre le PDF en ligne si vous voulez) montrent l'intérêt d'utiliser plusieurs processeurs, aussi bien pour la performance que pour la consommation d'énergie. C'est pour cela que les processeurs à plusieurs unités d'exécution (multi-core) se sont tant développés dans nos Mac/PC. Mais ce n'est pas si simple, et de nombreux problèmes interviennent. Il faut par exemple gérer l'accès concurrent aux ressources (mémoire...), et il faut s'assurer que le processeur est toujours utilisé. Il faut donc choisir le niveau de parallélisation (la granularité) qu'on veut. Dans un programme séquentiel traditionnel, de nombreuses instructions peuvent être exécutées en parallèle (si elles ne font pas appelle aux même données par exemple), et la technique la plus simple est alors de donner tous les coeurs à un seul processus pendant un certain temps, puis de passer au processus suivant. C'est peu efficace, et on est limité par le parallélisme intrinsèque de chaque programme...

Pages

CONNEXION UTILISATEUR