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

LLVM et Clang




Apple a fait un investissement stratégique dans le projet open source LLVM il y a plusieurs années déjà. J'ai abordé les fondamentaux de LLVM dans mon compte-rendu de Léopard. (Si vous n'êtes pas au courant, mettez vous à la page avant de continuer). J'y ai montré comment Léopard utilisait LLVM pour fournir une implémentation logicielle compilée à la volée (JIT), des fonctions OpenCL en les rendant considérablement plus efficaces.

Ne soyez pas abusé(e) par son usage limité sous Léopard ; Apple a des plans ambitieux pour LLVM. Jusqu'où ? Pourquoi ne pas remplacer les boyaux du compilateur gcc que Mac OS X utilise actuellement, par ceux équivalents de LLVM ? Ce projet est bien lancé. Pas assez ambitieux ? Pourquoi ne pas s'affranchir entièrement de gcc et le remplacer par un nouveau compilateur, basé sur LLVM (mais compatible avec gcc) ? Ce projet s'appelle Clang et il déjà fourni quelques résultats de performance impressionnante.

Avec l'introduction de Léopard des neiges, c'est officiel : Clang et LLVM représentent la stratégie adoptée par Apple. LLVM a un nouveau logo stylé, un hommage appuyé à un manuel bien connu de conception des compilateurs.

Le dragon

LLVM! Clang!

Apple fournit maintenant pas moins de 4 compilateurs pour Mac OS X : GCC 4.0, GCC 4.2, LLVM-GCC 4.2 (GCC 4.2 en accès direct, et LLVM dans les coulisses), et Clang, pour améliorer la migration vers LLVM. En voici un croquis :

Compilateurs

Les compilateurs Mac OS X

Tous ces compilateurs ont un binaire compatible sous Mac OS X, si bien que vous pouvez par exemple, construire une bibliothèque avec un compilateur, et la lier à un exécutable construit avec un autre compilateur. Ils sont aussi -en théorie au moins- tous compatibles pour les sources et les commandes. Clang ne supporte pas encore quelques caractéristiques ésotériques de GCC, et il ne supporte aussi que C, Objective C, un peu de C++ (Clang(age) ; vous avez compris ?), alors que GCC en supporte beaucoup plus. Apple se consacre au support complet de C++ pour Clang, et espère éliminer les incompatibilités qui subsistent avec GCC pendant la durée de vie de Léopard des neiges.

Clang apporte deux attributs importants que vous êtes en droit d'attendre d'un nouveau compilateur au goût du jour : des délais de compilation plus courts, et des exécutables plus rapides. Selon les tests d'Apple avec ses propres applications, comme iCal, Address Book ou même XCode, et des applications tierces comme Adium ou Growl, Clang compile à peu près trois fois plus vite que GCC 4.2. Quant à la vitesse du produit fini, LLVM en arrière plan, que ce soit dans Clang ou dans LLVM_GCC, produit des exécutables qui sont 5 à 25 % plus rapides que ceux créés par GCC 4.2.

Clang est aussi plus facile pour les développeurs que ses prédécesseurs GCC. J'admet que cela n'a pas grand chose à voir avec l'avantage d'utiliser des CPU à plusieurs cœurs, ou des choses de ce genre, mais il est sûr que c'est une des premières choses qu'un développeur remarque effectivement. Permettez-moi de m'en réjouir.

Pour les débutants, Clang est encapsulable, si bien que XCode peut utiliser la même infrastructure de compilateur pour les possibilités de l'IDE (recherche par symbole, complétion de code) que celle qu'il utilise pour compiler le code final exécutable. Clang crée et conserve aussi des méta-data beaucoup plus étendues pendant la compilation, ce qui permet un bien meilleur rapport d'erreur. Par exemple, quand GCC vous dit ceci : Clang
Ce n'est pas très clair de savoir où est le problème, particulièrement si vous débutez en C. Bien sûr, vous les experts, vous savez déjà où il est (et notamment si vous avez déjà vu ces exemple à la WWDC) mais je crois que tout le monde sera d'accord pour admettre que ce message d'erreur généré par Clang et bien plus utile : Clang
Peut-être qu'un novice ne saura pas encore quoi faire, mais au moins on sait clairement où est le problème. Imaginer pourquoi le compilateur ne connaît pas NSString est une tâche bien plus ciblée que ce que le message d'erreur obscur de GCC permet de déduire.

Même quand le message est clair, le contexte peut ne pas l'être. Voyez cette erreur de GCC : Clang
Il y a bien quatre opérateurs "+" sur cette ligne. Lequel a des opérandes qui posent problème ? Grâce à ses méta-data plus détaillées, Clang peut mieux le localiser : Clang

Parfois, l'erreur est parfaitement claire, mais elle semble seulement un peu décalée, comme dans cette situation où GCC positionne le message d'erreur à la ligne en-dessous celle où vous devez rajouter le ; manquant. Clang
Ces petites chose là comptent, vous savez ? Clang fait mieux : Clang

Que vous le croyiez ou non, ces petites choses ont beaucoup d'importance pour les développeurs. Et puis, il y a ces choses pas si petites, qui comptent encore plus, comme l'analyseur statique fourni par LLVM. L'image qui suit montre comment il affiche sa découverte comme une bogue possible. Clang

Au delà de la fantaisie des petites flèches (qui, admettez-le, sont adorables) la bogue qu'elles soulignent est quelque chose que tout programmeur peut arriver à faire (pour peu qu'il écrive un peu vite). L'analyseur statique est arrivé à la conclusion qu'il y a au moins un chemin par lequel on ne passe pas dans ces conditions imbriquées, et qui laisse la variable myName non initialisée, ce qui rend potentiellement dangereuse la tentative de lui envoyer le message mutableCopy, sur la dernière ligne.

Je suis sûr qu'Apple doit être très friand de l'analyseur statique pour toutes ses applications, et le système d'exploitation lui-même. La recherche d'une méthode automatique pour découvrir les bogues qui peuvent exister depuis des années dans les entrailles d'une base de code gigantesque est presque un sujet pornographique pour les développeurs - en particulier ceux qui proposent des systèmes d'exploitation. Dans la mesure où Mac OS X 10.6 a moins de bogues que les versions précédentes (10.x.0), LLVM y a sûrement une part significative.

Le maître du logis

En s'engageant dans la voie du couple puissant Clang-LLVM, Apple a finalement pris le contrôle complet de son système de développement. L'expérience de Code Warrior a finalement convaincu Apple qu'il n'était pas avisé de s'appuyer sur un tiers pour les outils de sa plate-forme de développement. Bien que cela ait pris de nombreuses années, je pense que le plus inconditionnel des fans de Metrowerks devrait admettre que XCode, dans Léopard des neiges est un IDE sacrément bon.

Après des années de bataille à cause de la différence entre les objectifs du projet GCC et ses propres besoins en compilateur, Apple a finalement coupé le cordon. Bien sûr, c'est vrai, GCC 4.2 est encore le compilateur par défaut dans Léopard des neiges, Mais c'est une phase de transition. Clang est le compilateur recommandé, et le point de mire de tous les efforts futurs d'Apple.

Je sais ce que vous pensez. C'est de l'enflure, et tout... Comment ces compilateurs peuvent-ils aider les développeurs à démultiplier la puissance des myriades de transistors mise à leur disposition ? Comme vous allez le voir dans les sections qui suivent, la tête écailleuse et métallique de LLVM se pointe à quelques endroits clé.