Nous avons reçu un message intéressant de l'administrateur du site monappstore.com:
Je gère le site monappstore.com et surveille donc régulièrement les nouvelles applications qui sont disponibles sur l'AppStore.
Je pense que quelque chose d'important se prépare au niveau de l'AppStore, sûrement en liaison avec le special event de demain car il n'y a eu quasiment aucune nouvelle application publiée depuis le 4 septembre.
C'est rare de voir une telle pause (4 jours) dans le flot continu des sorties. J'ai noté seulement 7 applications avec une date de sortie après le 4/9 alors que les jours précédents on était à une moyenne de plus de 400 par jour...
Il est difficile d'imaginer les raisons qui ont poussé Apple à faire une telle pause. Elle est trop abrupte pour être mise au crédit de quelconques congés. Il y a fort à parier que quelque chose va changer...
Nous donnons la parole à Gérôme.
Je t'écris pour te faire part d'un bug que j'ai résolu sur SL, qui a planté plusieurs machines avec les applis Apple Mail et Carnet d'Adresses. Certains des lecteurs de MacBidouille se sont surement arraché les cheveux avec, voici donc comment résoudre le problème.
Symptômes : Roue multicolore au lancement de Mail et de Carnet d'Adresses, sans possibilité de reprendre la main sur l'une ou l'autre appli.
Solution :
1) il faut retirer les fichiers AddressBook-v22~.abcddb et AddressBook-v22.abcddb du dossier ~/library/Application Support/AddressBook.
2) Retirer tous les "groupes intelligents" de carnet d'adresse dans ~/library/Application Support/AddressBook/Metadata. Ces groupes sont facilement identifiables grâce à leur appellation "...ABSmartGroup.abcdg" en fin de fichier.
Une fois que cela est fait, miracle ! Mail et Carnet d'Adresses fonctionnent à nouveau parfaitement. Le seul hic est qu'il faudra recréer les groupes d'adresses intelligents, mais c'est un moindre mal face à l'impossibilité qu'il y avait d'utiliser ces deux applications.
Une étude réalisée par un cabinet danois de consulting, Strand Consult, risque de faire beaucoup parler d'elle.
Il en ressort que l'iPhone ne serait pas un bon moyen de gagner de l'argent pour les opérateurs mobiles qui l'ont adopté. Cette conclusion est motivées par plusieurs facteurs:
- Apple exigerait un subventionnement trop important de son appareil vendu très cher aux opérateurs.
- Apple demanderait un partage de certains revenus. (On soupçonne Apple d'avoir exigé de l'argent en échange des applications TV aux opérateurs).
- La gestion de l'appareil et de ses possesseurs seraient très coûteux en temps.
Afin d'illustrer leurs propos, ils indiquent que certains opérateurs auraient averti leurs actionnaires que les gains générés par l'iPhone seraient moins conséquents que prévu. Ces actionnaires sont vu par la société de consulting comme les grands perdants de l'adoption de l'iPhone.
On peut également abonder dans leur sens en sachant qu'Apple prive avec son iPhone les opérateurs de la manne financière liée à la vente de musique de sonneries et également d'applications.
Pourtant, comme on en a eu la preuve en France, les opérateurs ont été prêts à s'étriper pour pouvoir vendre l'iPhone. Il semble donc bien qu'ils préfèrent encore gagner peu d'argent avec plutôt que de voir leurs clients intéressés par l'appareil passer chez un de leurs concurrents.
Dans ses derniers pilotes destinés à Windows, NVidia a fait une bourde en citant avec anticipation le nom de produits pas encore au catalogue. Il s'agit de nouvelles puces mobiles qui sont au nombre de 7:
- NVIDIA GeForce GT 330M
- NVIDIA GeForce 310
- NVIDIA GeForce 305M
- NVIDIA GeForce 310M
- NVIDIA GeForce GT 335M
- NVIDIA GeForce GTS 350M
- NVIDIA GeForce GTS 360M
Difficile de dire si l'on verra l'une de ces cartes à côté d'un 9400M dans un Macbook Pro. Il y a en revanche plus de chances qu'Apple propose l'un de ces modèles dans un iMac si la gamme devait évoluer encore une fois avant l'arrivée des machines à base de CPU Nehalem.
Au passage on appréciera continuera à déplorer le manque de clarté dans ces appellations qui rendent difficiles les comparaisons entre les différents produits.
Nous avons demandé à Christophe Ducommun qui développe le logiciel MovieGate et qui est toujours à la recherche des moyens de le rendre plus véloce son opinion sur les deux technologies phares de Snow Leopard, Open CL et Grand Central.
Actuellement je travaille sur les optimisations possible du décodeur vidéo de MovieGate. Le décodeur de MovieGate se charge de fournir des images au format YCbCr 4:2:2 aux deux encodeurs MPEG-2 possible (mpeg2enc et ffmpeg). Au niveau performances, le but est de fournir un maximum d'images/seconde à l'encodeur vidéo avec un minimum de temps processeur utilisé. La solution est d'utiliser le processeur de la carte graphique (GPU) pour décharger le processeur central, cela à aussi comme impact de laisser plus de CPU libre à l'encodeur.
Grand Central Dispatch
Cette technologie permet de faire du multi-threading "sans synchronisation". Il faut savoir que lorsqu'on développe une application multi-thread, il faut protéger l'accès aux variables communes entre les différents thread (lock, semaphores etc...). Ces opérations demandent au kernel l'accès aux variables, et si un autre thread y accède, le thread en question est mis en attente. Ces accès sont couteux et empêchent les threads de pouvoir dans tous les cas travailler en parallèle. C'est une des raisons pour laquelle la gain en vitesse par exemple sur une machine à 8 coeurs n'est pas deux fois plus rapide que sur une machine à 4 coeurs. Quand un traitement sur n données doit être effectué, les coeurs vont se partager le travail, plus il y a de coeurs, moins important sera le temps de traitement par coeur. Mais les temps de latence induit par la synchronisation reste identique. Ce qui fait que les threads passent leur temps (façon de parler) à attendre l'accès aux variables. Plus il y a de coeurs plus ce problème s'intensifie.
Grand Central Dispatch propose des threads déjà prêt à exécuter le travail au niveau du kernel. Ce qui signifie que les applications n'ont plus besoin de créer des threads et n'ont plus besoins de synchroniser l'accès aux variables. C'est Grand Central qui s'en charge et comme il travaille à un niveau plus bas les temps de latence sont nettement moins importants.
De plus Grand Central Dispatch gère lui-même le nombre de threads actifs suivant la charge de la machine, de cette manière le traitement est bien plus efficace qu'avec une programmation traditionnelle via des threads et de la synchronisation.
Il y a beaucoup de choses à dire sur cette technologie, mais en voici le principe.
Concernant le décodeur vidéo de MovieGate, une version BETA exploite déjà Grand Central, le gain en vitesse n'est pas important, mais la charge processeur est diminuée ce qui est un bon point.
OpenCL
Cette technologie est très prometteuse mais pas forcément facile à prendre en main. Le principe est d'exécuter des opérations sur le GPU à la place du CPU.
Pour commencer, un GPU possède un nombre important d'unité de calculs (112 sur une 8800GT), par comparaison un Xeon Quad Core en possède... quatre. Alors il est aisément compréhensible que si on peut paralléliser des calculs, un GPU exécutera ce traitement de manière bien plus rapide qu'un processeur.
Voilà pour la théorie, mais dans la pratique il y a certains facteurs dont il faut faire très attention.
Voici le principe de fonctionnement.
(Host) < BUS PCI-Express > (Device)
Host, c'est l'application qui travaille sur le CPU avec la RAM qui lui est allouée. Device, c'est la carte graphique avec sa propre mémoire (GPU et VRAM).
Lorsqu'une application veut exécuter un certains nombre de calculs sur le GPU, il doit tout d'abord transférer les données de la RAM vers la VRAM de la carte graphique. Cette opération est couteuse en temps et doit être réduite au maximum. Le temps de traitement des données par le GPU, dépend de sa puissance. Lorsque le GPU a terminé ses calculs, il faut transférer à nouveau les résultats de la VRAM vers la RAM via le bus PCI-Express ce qui est à nouveau couteux en temps. On comprend donc, que pour limiter l'impact du transfert mémoire, il faut que le temps de traitement sur le GPU soit important. Donc si il faut faire quelques calculs simples, OpenCL sera plus lent qu'un traitement sur le CPU de manière traditionnelle. Evidemment on peut travailler de manière asynchrone, c'est-à-dire faire quelque chose d'autre pendant que les données sont transférées, mais cela ne supprime pas le fait que le transfert mémoire est couteux.
Le principe d'OpenCL est d'écrire des kernel qui exécutent le traitement spécifique à l'application. Ces kernels sont compilé à la volée par l'application pour le GPU détecté, le compilateur va fournir un code compilé spécifique au GPU détecté et peut donc faire certaines optimisations.
Cependant on ne peut pas écrire un kernel de n'importe quelle manière, car suivant le code écrit les performances suivant le GPU peuvent chuter drastiquement. nVidia fournit un guide pour les développeurs expliquant comment optimiser le code d'un kernel afin que le GPU l'exécute de la manière la plus efficace. Il faut donc bien connaître l'architecture d'un GPU pour en tirer tout son potentiel, ce qui n'est pas chose aisée.
Concernant OpenCL, le but est d'offrir une API indépendante des constructeurs de cartes graphique. Mais il faut savoir qu'OpenCL est en fait bâtit comme CUDA. En effet nVidia à développé une passerelle OpenCL -> CUDA, d'ailleurs OpenCL ressemble très fortement à CUDA et utilise les mêmes principes. NVidia à donc eu peu de travail car ils avaient déjà fournit un SDK CUDA pour Mac OS X bien avant Snow Leopard.
On comprend aussi facilement qu'OpenCL fonctionne mieux sur cartes nVidia que des cartes ATI pour ces raisons.
Concernant ATI (ceci n'engage que moi), ils ont eu un travail bien plus important et c'est sans doute la raison pour laquelle peu de cartes ATI sont finalement supportées par OpenCL.
OpenCL est très prometteur, cependant ce n'est pas une technologie que l'on prend en main facilement contrairement à ce que disait Steve Jobs. N'importe quelle application ne tirera pas forcément profit d'OpenCL, et la qualité du code des kernels écrits impactera fortement sur les performances. Ce qui veut dire que les développeurs utilisant cette technologie devront vraiment savoir l'exploiter de manière correct pour en tirer tous les avantages.
Pour terminer OpenCL offre une passerelle vers OpenGL, c'est-à-dire que l'on peut travailler directement avec des données provenant d'OpenGL donc de la VRAM mais aussi fournir des résultats calculé par OpenCL vers OpenGL sans avoir besoin de transfert via le bus PCI-Express.
Ce sont à mon avis les applications utilisant OpenGL qui tireront le mieux profit d'OpenCL car les transfert mémoire sont réduits.
Si nous devions résumer ses propos, nous dirions que le potentiel est indubitablement énorme, mais que contrairement à ce qu'Apple laissait penser, il ne suffira pas de modifications légères pour accélérer des logiciels. Il faudra non seulement avoir les bonnes données, celles que l'on peut paralléliser, mais aussi optimiser au mieux le code fourni pour que tout soit optimal. C'est certainement ce qui explique que personne n'ait été prêt à lancer un logiciel ultra optimisé à la sortie de Snow Leopard.
