1. John Siracusa
    1. Mountain Lion
      1. Introduction
      2. Achat et installation
      3. Changements d'interface (1)
      4. Changements d'interface (2)
      5. Changements d'interface (3)
      6. Applications (1)
      7. Applications (2)
      8. Applications (3)
      9. Applications (4)
      10. Applications (5)
      11. iCloud(1)
      12. iCloud(2)
      13. iCloud(3)
      14. Gatekeeper(1)
      15. Gatekeeper(2)
      16. Retina et HiDPI
      17. Fourre-tout (1)
      18. Fourre-tout (2)
      19. Fourre-tout (3)
      20. Fourre-tout (4)
      21. Fourre-tout (5)
      22. Fourre-tout (6)
      23. Recommandations
      24. Deux pères, un fils
    2. Lion
      1. Introduction
      2. Installation
      3. Revoir les fondamentaux
      4. Redimensionnement des fenêtres
      5. Et voici pour les cinglés
      6. La gestion des fenêtres
      7. Le modèle de document
      8. le modèle des processus
      9. Les éléments internes (1)
      10. Les éléments internes (2)
      11. ARC
      12. Le système de fichiers
      13. Ses modifications dans Lion
      14. Documents, résolution
      15. Le Finder
      16. Mail, Safari
      17. Fourre tout (1)
      18. Fourre tout (2)
      19. Recommendations
    3. Snow Leopard
      1. Introduction
      2. Le ticket d'entrée
      3. L'installation
      4. Nouvel aspect
      5. Détails internes
      6. Quick Time X
      7. Système de fichiers
      8. Faire plus avec plus
      9. LLVM et Clang
      10. Les blocs
      11. Concurrence
      12. Grand Central Dispatch
      13. Asynchronicité
      14. Open CL
      15. La différence...
      16. Quick Time Player
      17. Le Dock
      18. Le Finder
      19. Exchange
      20. Performances
      21. Fourre tout (1)
      22. Fourre tout (2)
      23. Le futur
    4. Leopard
      1. Introduction
      2. L'héritage
      3. Nouvel aspect 1
      4. Nouvel aspect 2
      5. Le noyau
      6. 64 bits
      7. FS Events
      8. Core animation
      9. Quartz GL
      10. Core UI
      11. Détails internes
      12. Le Finder
      13. Le Dock
      14. Time Machine
      15. Performances
      16. Pot pourri
      17. Demain
    5. Tiger
      1. Introduction
      2. Retour sur le passé
      3. Nouvel aspect de Tiger
      4. Mises à jour du noyau
      5. Le lancement
      6. Les méta-données
      7. Attributs étendus
      8. Listes de contrôle d'accès
      9. Spotlight 1
      10. Spotlight 2 : analyse et potentiel
      11. Types de fichiers
      12. Méta-données : la fin
      13. Quartz
      14. Quartz 2D Extreme
      15. Core Image
      16. La vidéo sous Tiger
      17. Dashboard
      18. Le Finder
      19. Les performances
      20. Pot pourri
      21. Conclusion
    6. Panther
      1. Introduction
      2. Les précédents
      3. L'installation
      4. Nouvel aspect
      5. Performances
      6. Changement rapide d'utilisateur
      7. Gestion des fenêtres
      8. Exposé
      9. Le Finder
      10. Performance du Finder
      11. Toujours le même
      12. Safari
      13. XCode
      14. Conclusion
    7. Jaguar
      1. Introduction
      2. Le nom
      3. L'installation
      4. Modifications d'Unix
      5. Dévelopeurs...
      6. Quoi de neuf
      7. Rendezvous
      8. Quartz Extrême
      9. Performance
      10. Compositions
      11. Le Finder
      12. Applications
      13. Sherlock
      14. Le portrait
    8. Puma
      1. Prelude
      2. Introduction
      3. Installation
      4. Réglages système
      5. Performance
      6. Redimensionnement des fenêtres
      7. Utilisation de la mémoire
      8. Diagnostics de mémoire
      9. L'environnement Classique
      10. L'interface Utilisateur
      11. Le Finder
      12. Extensions de fichiers
      13. Divers, conclusion
    9. Cheeta (Mac OS X 10.0)
      1. Qu'est ce que Mac OS X
      2. Installation
      3. Le démarrage
      4. Utilisation de la RAM
      5. Performance
      6. Performance des applications
      7. Stabilité
      8. L'interface utilisateur
      9. Le Finder
      10. Le navigateur du Finder
      11. Le Finder (divers)
      12. L'interface utilisateur
      13. Os X Classique
      14. Système de fichiers
      15. Unix
      16. Applications
      17. Conclusion
    10. Les débuts de MacOsX
      1. 1999 : OSX DP2
      2. 2000 : Quartz et Aqua/a>
      3. Fin de la lune de miel
      4. la première bêta publique
      5. 2001 : Mac OS X 10.0
      6. Un investissement
    11. Finder Spatial
      1. Introduction
      2. Interfaces spatiales
      3. Le Finder spatial
      4. Le concierge
      5. Un nouveau Finder
      6. Le browser
      7. Le browser spatial
      8. Finder et méta-données
      9. Les modèles
      10. Pensées finales

La différence OpenCL




Tout ça c'est bien beau, mais pour avoir un impact sur la vie de tous les jours des utilisateurs de Macs, les développeurs doivent effectivement utiliser OpenCL dans leurs applications. Historiquement, les langages de programmation GPGPU n'ont pas été beaucoup utilisés dans les applications traditionnelles sur les PCs. Il y a à cela plusieurs raisons.

Tout d'abord, écrire des programmes pour un GPU obligeait souvent à utiliser des langages en assembleur spécifiques au vendeur qui étaient très éloignés de l'expérience d'écriture d'une application typique pour PC, utilisant une API GUI (Graphic User Interface) contemporaine. La plupart des langages de type C qui sont venus après restaient très centrés sur le graphisme, ou propres à un vendeur, ou les deux. A moins que faire tourner du code sur un GPU n'accélère une composante essentielle d'une application d'un ordre de grandeur, la plupart des développeurs ne pouvaient pas s'embêter à naviguer dans ce genre de monde étranger.

Et même si le GPU apportait une énorme amélioration de vitesse, s'appuyer sur un matériel graphique pour un calcul à usage général était de nature à rétrécir la portée de l'application. Beaucoup des plus anciens GPUs, notamment ceux des ordinateurs portables, ne peuvent pas du tout utiliser un langage comme CUDA.

La décision majeure d'Apple dans la conception de OpenCL a été de permettre aux programmes OpenCL de tourner non pas seulement sur des GPUs, mais aussi sur des CPUs. Un programme OpenCL peut interroger le matériel sur lequel il tourne et identifier tous les composants éligibles à OpenCL, que ce soit des CPUs, des GPUs, ou des accélerateurs pour OpenCL (le serveur Cell Blade d'IBM, oui, ce processeur cellulaire en fait apparemment partie). Le programme peut alors distribuer ses tâches OpenCL à tout composant disponible. On peut aussi créer un seul composant logique, qui consiste en n'importe quelle combinaison de ressources éligibles : deux GPUs, un autre GPU, et deux CPUs, etc...

Les avantages d'être capable de faire tourner des programmes OpenCL sur des GPUs et des CPUs sont évidents. Tout Mac qui tourne sous Léopard des neiges, pas seulement ceux équipés des plus récents modèles de GPUs peut exécuter des programmes qui incorporent du code OpenCL. Mais il y a plus.

Certaines formes d'algorithmes tournent effectivement plus vite sur des CPUs multi-cœurs de haut de gamme que sur des GPUs, fussent-ils les plus rapides disponibles. A la WWDC 2009, un ingénieur de Electronic Arts a fait la démonstration d'une version OpenCL d'un moteur d'habillage d'un de ses jeux qui tournait plus de quatre fois plus vite sur un mac Pro à quatre cœurs que sur une carte NVIDIA GeForce GT285. La réorganisation de l'algorithme, et beaucoup d'autres modifications pour s'adapter aux limitations (et aux avantages) des GPUs, ont réorienté vers les CPU dans une large mesure, mais parfois vous désirez seulement que le système dont vous disposez fonctionne bien tel qu'il est. Etre capable de définir le CPU comme cible est très utile dans ces cas là.

En plus, l'écriture de code vectoriel pour des CPUs Intel "à la manière ancienne", peut être une vraie difficulté. Il faut prendre en compte MMX, SSE, SSE2, SSE3 et SSE4, tous avec des possibilités légèrement différentes, et chacune oblige le programmeur à écrire du code du genre : listing
Le support natif d'OpenCL pour les types vecteur démêle le code de façon considérable. listing

Semblablement, le support d'OpenCL pour un parallélisme implicite fait qu'il est beaucoup plus facile de tirer avantage de nombreux cœurs de CPU. Plutôt que d'écrire tout la logique nécessaire pour scinder les données en morceaux et les distribuer au matériel disponible pour le parallélisme, OpenCL vous permet de n'écrire que le code pour un seul morceau de données, puis de l'envoyer avec son bloc complet de données, et le niveau désiré de parallélisme au composant de calcul voulu.

Cette disposition est considérée comme normale dans les programmes graphiques traditionnels où le code fonctionne implicitement sur tous les pixels d'une texture ou sur tous les sommets d'un polygone ; le programmeur n'a besoin que d'écrire le code qui doit être dans la boucle intérieure, pour ainsi dire. Une API avec ce genre de parallélisme, qui fonctionne sur des CPUs aussi bien que sur des GPUs rempli un vide important.

Ecrire pour OpenCL est aussi une assurance sur le futur pour le code concernant les tâches ou les données en parallèle. Tout comme un même code OpenGL sera de plus en plus rapide à mesure que des GPUs plus puissants sont disponibles, le code OpenCL est appelé à se comporter mieux quand les CPUs et les GPUs iront plus vite. Le niveau supplémentaire d'abstraction que fournit OpenCL rend cela possible. Par exemple, bien qu'un code vectoriel écrit il y a plusieurs années en utilisant MMX aille plus vite à mesure que les vitesses d'horloge du CPU augmentent, une amélioration de performance plus significative requiert probablement le portage du code vers l'un des nouveaux jeux d'instructions SSE.

A mesure que de nouveaux jeux d'instructions vectoriels et des matériels de calcul parallèles deviennent disponibles, Apple va mettre à jour les implémentations OpenCL pour en tirer avantage, tout comme les fabricants de cartes vidéo ou les vendeurs d'OS mettront à jour leurs pilotes OpenGL, pour profiter de GPUs plus rapides. Pendant ce temps, le code de l'application demeure inchangé pour les développeurs. Il n'est même pas besoin de recompiler.

Qu'il y ait ici des dragons (et des trains)

Vous vous demandez peut-être comment le même code compilé peut en arriver à utiliser SS2 sur une machine, et SS4 sur une autre, ou un GPU NVIDIA sur une machine, et un GPU ATI sur une autre ? Pour le faire, vous devez traduire le code OpenCL indépendant du composant dans le jeu d'instructions du composant cible, à l'exécution. Quand il tourne sur un GPU, OpenCL doit aussi envoyer les données et le nouveau code résultant de la traduction à la carte vidéo, et récupérer les résultats à la fin. S'il tourne sur un CPU, OpenCL doit s'organiser pour un niveau requis de parallélisme en créant et en répartissant les threads convenablement aux cœurs disponibles.

Et bien, le croiriez-vous ? Apple dispose justement de deux technologies qui résolvent exactement ces problèmes.

Vous voulez compiler du code "à la volée" et l'envoyer au composant de calcul ? C'est ce pour quoi LLVM a été fait, et bien sûr ce qu'Apple a fait avec, dans Léopard, bien que à une échelle plus limitée. OpenCL est une extension naturelle de ce travail. LLVM permet à Apple d'écrire un seul générateur de code pour chaque jeu d'instructions cible, et concentre tous ses efforts sur un seul optimiseur de code indépendant du composant. Il n'y a plus aucun besoin de dupliquer ces tâches, en utilisant un compilateur pour créer une application statique exécutable, et en improviser un autre pour la compilation à la volée.

Oh, et par la même occasion, vous vous rappelez Core Image ? Voilà une autre API qui a besoin de se compiler à la volée, et être envoyée pour l'exécution sur les matériels en parallèle comme des GPUs et des CPUs multi-cœurs. Dans Léopard des neiges Core Image a été réécrit en utilisant OpenCL, et cela fournit une confortable amélioration de performances de 25 % au total.

Pour gérer le parallélisme des tâches et fournir des threads, OpenCL est construit au dessus de Grand Central Dispatch. C'est un chose si normale, qu'il semble un peu surprenant que l'API OpenCL n'utilise pas les blocs. Je pense qu'Apple a décidé qu'il ne fallait pas forcer la chance quand il s'agit de voir ses technologies maison adoptées pas d'autres vendeurs. Cette décision semble se révéler payante, puisque AMD a sa propre implantation de OpenCL en développement.

Le sommet de la pyramide

Bien que les technologies sous-jacentes, Clang, les blocs, et Grand Central Dispatch seront sans aucun doute plus largement utilisées par les développeurs, OpenCL représente le point culminant de cet ensemble technologique dans Léopard des neiges. C'est une médaille d'or dans la conception du logiciel : créer une nouvelle API publique, en la construisant au sommet d'autres APIs publiques de bas niveau, tout aussi bien conçues et implémentées.

Une abstraction unifiée pour une accumulation hétérogène et toujours plus importante de silicium destiné au calcul parallèle dans les PCs était une impérieuse nécessité. On a observé une population croissante de cœurs de CPUs puissants, mais en nombre, ils sont plusieurs ordres de grandeur plus faibles que les centaines d'unités de calcul des GPUs modernes. D'un autre côté, les GPUs ont encore du travail à faire pour rivaliser avec la puissance et la flexibilité des cœurs de CPU à maturité. Mais même compte tenu de ces différences, écrire du code exclusivement pour l'un ou l'autre de ces mondes équivaut à laisser de l'argent sur la table.

Avec OpenCL sous la main, il n'est plus besoin de mettre tous ses œufs dans le même panier de silicium. Et avec l'arrivée des hybrides CPU/GPUs comme le Larabee d'Intel qui utilise des moteurs de calcul du calibre des CPUs, mais en nombre beaucoup plus élevé, OpenCL peut se révéler encore plus important dans les années qui viennent.

La moisson de transistors

Toutes ensemble, les techniques de simultanéité introduites dans Léopard des neiges représentent le plus important progrès dans le développement du logiciel asynchrone et parallèle de toutes les livraisons de Mac OS X, et peut-être de tous les systèmes d'exploitation jamais délivrés. Il est sans doute difficile, pour les utilisateurs finaux, d'être enthousiasmé par des technologies fondamentales comme Grand Central Dispatch, OpenCL, sans parler des compilateurs, et des propriétés des langages de programmation, Mais c'est sur ces fondations que les développeurs vont pouvoir créer des ensembles logiciels toujours plus impressionnants. Et si ces applications surpassent leurs prédécesseurs synchrones et sériels, ce sera parce qu'elles s'appuient sur les épaules de géants.