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

OpenCL




OpenCL

OpenCL est associé au Core

Jusqu'à présent, nous avons vu quelques exemples consistant à faire plus avec plus : une infrastructure de compilateur plus moderne, qui supporte une nouvelle possibilité importante du langage et une API pour la simultanéité, puissante et pragmatique. Tout cela représente un gros effort pour aider les développeurs, et l'OS lui-même fait un maximum pour utiliser le matériel disponible.



Mais les CPUs ne sont pas les seuls composants qui fournissent une surabondance de transistors. Quand on parle de prolifération de moteurs de calcul indépendants, un autre morceau de silicium est un tenant du titre incontestable : le GPU.


Les chiffres racontent l'histoire. Alors que les CPUs des Macs contiennent quatre cœurs (qui peuvent monter à huit cœurs logiques grâce au multithreading symétrique) les GPUs de haut de gamme peuvent contenir bien plus de 200 cœurs. Alors que les CPUs dépassent tout juste les 100 GFLOPS, les meilleurs GPUs peuvent dépasser 1000 GFLOPS. C'est mille milliards d'opérations en virgule flottante par seconde. Et comme les CPUs, il y a maintenant plusieurs GPUs sur une carte.

Ecrire pour un GPU

Malheureusement, les cœurs des GPUs ne sont pas des processeurs à usage général (du moins, pas encore). Ce sont des engins de calcul plus simples, qui ont évolué, à partir des fonctions implantées dans le silicium de leurs ancêtres, qu'on ne pouvait pas du tout programmer. Ils ne fournissent pas le riche ensemble d'instructions des CPUs, la taille maximum des programmes qu'ils peuvent faire tourner est souvent limitée et très petite, et ils ne supportent pas toutes les possibilités du standard de calcul en virgule flottante IEEE.

Aujourd'hui, les GPUs peuvent être programmés, mais les possibilités les plus communes de programmation s'inscrivent dans le domaine graphique : calcul de vertex, de primitives géométriques, des attributs de pixels. La plupart des langages utilisés pour programmer les GPUs sont aussi orientés graphique : HLSL, GLSL, Cg.

Il y a cependant des tâches de calcul en dehors du graphisme qui peuvent tirer profit des GPUs en tant que matériel. Ce serait bien s'il y avait un langage non orienté graphique pour écrire des programmes pour elles. Mais créer une chose de ce genre est un vrai défi. Le matériel des GPUs varie de toutes les façons imaginables : nombre et type des unités d'exécution, jeu d'instructions, architecture de mémoire, et tout ce que vous pouvez imaginer. Les programmeurs ne veulent pas être confrontés à ces différences, mais il est difficile de contourner une absence complète d'une caractéristique, ou l'indisponibilité d'un type particulier de données.

Le vendeur de GPUs NVIDIA a cependant fait une tentative avec CUDA : un sous-ensemble du langage C avec des données de type vecteur, des identificateurs de stockage des données, qui reflètent la hiérarchie de mémoire typique des GPUs, et plusieurs bibliothèques de calcul associées. CUDA n'est qu'un entrant dans le champ bourgeonnant des GPGPU (General Purpose computing on Graphics Processing Units). Mais en tant que fabriquant de CPUs, il doit affronter une bataille difficile avec les développeurs qui veulent en fait une solution indépendante d'un vendeur.

Dans le domaine de la programmation 3G, OpenGL remplit ce rôle. Et comme vous l'avez sûrement deviné à présent, OpenCL a pour ambition de jouer le même rôle pour les calculs d'usage général. En fait, Open CL est encouragé par le même consortium que Open GL, le groupe Khronos, au nom inquiétant. Mais ne vous y trompez pas, OpenCL est le bébé d'Apple.

Apple a compris que la meilleure chance de succès d'OpenCL était de devenir un standard de l'industrie, pas seulement une technologie Apple. Et pour que ça arrive, Apple avait besoin de la collaboration des principaux vendeurs de GPUs, et en plus, d'un agrément avec un organisme de standardisation bien établi et largement reconnu. Cela a mis du temps, mais maintenant, tout est en place.

OpenCL est beaucoup comme CUDA. Il utilise un langage proche du C, avec les extensions de vecteurs, il a un modèle de hiérarchie de mémoire similaire, et ainsi de suite. Ce n'est pas une surprise, quand on considère qu'Apple a étroitement travaillé avec NVIDIA pendant le développement d'OpenCL. Il n'y a aussi aucune raison pour qu'un vendeur de GPUs bien établi modifie son matériel de façon radicale, jusqu'à adopter un standard qui n'est pas encore établi, si bien qu'OpenCL devait fonctionner parfaitement avec les GPUs conçus pour supporter CUDA, GLSL, et d'autre langages de programmation existants pour les GPUs.