Snow Leopard : l'avis des développeurs

Florian Innocente |
Mac OS X Snow Leopard est lancé, et avec lui plusieurs technologies dont les premiers clients seront les développeurs avec, on l'espère, de sérieux bénéfices pour nous les utilisateurs. OpenCL qui permettra d'utiliser le processeur des cartes graphiques pour des calculs débordant du cadre de la 3D, le 64 bits pour que les applications utilisent davantage de mémoire (et aillent un plus vite au passage) ou encore Grand Central Dispatch qui entend simplifier la distribution des tâches entre les différents coeurs du (ou des) processeurs de l'ordinateur (voir aussi l'article Lexique : si vous avez raté le début…).

AppleMacOSXNewtechnologies


Snow Leopard maintenant finalisé, nous avons posé deux questions très simples à plusieurs développeurs : allez-vous utiliser ces technologies et quels en seront les avantages pour l'utilisateur ? Car la dernière conférence des développeurs Apple a été aride en démonstrations de performances. On espérait quelques chronomètres avec un iMovie ou un Aperture mis au régime de ces technologies. Nada. On est reparti avec quelques diapositives de chiffres pour Mail ou Safari et la promesse de voir un peu partout dans le système et dans ses applications des accélérations sur telle ou telle action. Des petits mieux qui, cumulés, donneraient au final un système plus vif et agréable.

A lire les réponses de ces développeurs, on a le sentiment qu'Apple a effectivement doté Snow Leopard de capacités très prometteuses. Mais leur mise en oeuvre ne paraît pas aussi simple. Cela va exiger du temps et de la patience. Comme si après le passage au PowerPC, aux G4 Altivec, à Mac OS X et aux puces Intel… une nouvelle période de transition s'ouvrait.

On peut supposer que dans les prochaines semaines des freewares et sharewares vont arriver, qui utiliseront ces mécanismes. Certains à titre purement démonstratif, d'autres pour accélérer telle ou telle fonction qui aura pu être modifiée assez aisément. Reste la question des grandes applications. OpenCL et consorts peuvent donner à Mac OS X un avantage sur Windows. Mais est-ce qu'un Adobe qui, quoiqu'il se passe chez Apple ou chez Microsoft, vendra toujours ses solutions pour les deux OS, aura un quelconque intérêt à réaliser un travail de tuning (autre que l'incontournable passage au 64-bits) ? Question identique pour un Quark ou un Microsoft, même si la division Mac de ce dernier a une vraie liberté pour utiliser des technologies spécifiquement Mac.

Mais plus que de ces gros éditeurs, c'est d'Apple que l'on attend des initiatives concrètes. Son catalogue est rempli de logiciels audio et vidéo qui peuvent tirer parti des nouveautés de Snow Leopard. Mais est-ce qu'il faudra patienter jusqu'à la sortie de révisions majeures d'iLife, d'Aperture ou de Final Cut Studio (tout juste remis à neuf) ? Après tout, vu le prix de Snow Leopard, il pourrait être tentant pour Apple de se rattraper par la vente au prix fort de versions "optimisées Snow Leopard" de ses applications. On espère un scénario moins coûteux, l'arrivée ces prochaines semaines, de petites mises à jour améliorant telle ou telle fonction, en attendant plus lors des grandes refontes de 2010.

INTERVIEW
(Seconde partie de ces interview)

Matthieu Kopp : co-fondateur d'Aquafadas
Editeur de solutions audio et vidéo, professionnelles et grand public.

MK : "Snow Leopard introduit des avancées remarquables : OpenCL, Grand Central Dispatch, beaucoup de nouveautés dans Quartz Composer aussi. En ce qui concerne les outils de développement, Snow Leopard apporte de tout nouveaux outils et c'est un vrai bonheur.

Je suis personnellement un peu partagé sur les gains de performance. Ils sont réels, mais pour bénéficier de certaines fonctionnalités, il faut investir beaucoup de temps à revoir certains blocs fonctionnels de nos codes. C'est un choix difficile quand on a investi du temps pour développer des fonctions de traitement s'appuyant par exemple sur du QuickTime bas niveau. Ces traitements sont à revoir, car ils ne passent pas la barrière du 64 bits. Idem pour Grand Central Dispatch. Certaines améliorations sont visibles à la recompilation, mais pour en bénéficier au mieux, il faut se plonger dans les entrailles du code et pas mal chambouler certaines choses.

Et comme souvent lors de telles transitions, il faut gérer le système précédent. Faut-il faire des applications Snow Leopard seulement ou garder la compatibilité avec Leopard ? Il est vrai que le prix de la mise à jour est très bas, mais il faut savoir que la plupart de nos applications sont encore compatibles avec Tiger. Nous allons progressivement en revoir quelques-unes pour y intégrer spécifiquement certaines technologies, notamment Grand Central Dispatch.

OpenCL est une technologie très intéressante et nous l'avons prise en main ces derniers mois. Le problème c'est que pour de nombreuses machines, le gain en performance n'est pas forcément très visible, car il dépend des cartes graphiques. Même certains iMac 24" assez récents n'en tirent pas parti. Nos applications sont avant tout utilisées par des pros et des particuliers qui ont des Mac de milieu de gamme (deux coeurs et une carte graphique d'entrée de gamme) pas forcément capables d'exploiter ces technologies (*). En conclusion : nous ne sommes pas pressés, mais testons avec intérêt ces avancées."

(*) OpenCL a besoin de ces cartes au minimum : NVIDIA GeForce 8600M GT, 8800 GT, 8800 GTS, 9400M, 9600M GT, GT 120, GT 130. ATI Radeon 4850 et 4870.


Nick Fletcher : Realmac Software
Éditeur de logiciels de création de sites web et de gestion d'images.

NF : "D'ici à la sortie de Snow Leopard on aura mis à disposition des révisions de LittleSnapper et de RapidWeaver. Elles ont pour unique but de s'assurer qu'elles fonctionnent avec le nouveau système. On a compilé LittleSnapper en 64 bits, mais pas Rapidweaver 4.3 et ce ne sera probablement pas le cas avant un certain temps. Mis à part les différentes technologies de Snow Leopard que l'on compte utiliser, on a relevé des gains en performances surprenants dans LittleSnapper 1.5.1 par le seul fait d'utiliser la version pour le 10.6 d'Xcode et de son nouveau compilateur. Pour ce qui est de l'avenir, il y a beaucoup de choses excitantes à attendre, tant du point de vue du développeur que de l'utilisateur, cependant on ne fait aucune annonce dans l'immédiat."


Antoine Rosset : OsiriX
Editeur d'un logiciel d'imagerie médicale.

AR : "Mac OS X 10.6 est une avancée intéressante pour l'utilisateur : à court terme avec le passage au 64 bits de nombreux logiciels et composants livrés avec l'OS. Le gain en performance peut aller jusqu'à 30% pour certaines fonctions. À long terme (plusieurs années ?), l'utilisateur peut espérer que les développeurs s'intéresseront à la programmation OpenCL et à Grand Central Dispatch. On voit donc ici le problème majeur, quel développeur va réécrire son code pour tirer profit de ces nouvelles technologies ? Les promesses d'OpenCL et de Grand Central Dispatch sont grandes. Mais pour l'instant, à part quelques applications de démonstrations, il n'y pas vraiment de garanties de leur utilité dans des logiciels "fonctionnels".

Qui va réécrire un moteur de rendu 3D avec l'espoir d'un gain hypothétique en performances ? Ce genre de moteur a déjà pris plusieurs années de mise au point en simple C++, alors le refaire dans un langage différent (OpenCL) ou introduire le concept de blocs (Grand Central Dispatch) c'est définitivement beaucoup d'investissement en temps.

Pour OsiriX, je ne me vois actuellement pas me lancer sans être sûr que le gain sera d'au moins 50% à 100% au final. Je vais attendre quelques mois (années ?) pour voir les gains réels de ces technologies dans d'autres logiciels : mon temps est malheureusement trop limité pour me tromper sur ce genre d'investissements colossaux."

Picture7


MacGeneration : À vous écouter, on se rend compte que c'est toute une réécriture, que c'est très lourd. Est-ce qu'Apple, dans son discours, n'a pas beaucoup simplifié les choses ?

"Ce n'est pas faux. Par exemple, dans OsiriX, au moins 60% du code concerne l'interface. Celui-là on le changerait pas… mais les 40% sont vraiment compliqués à réécrire. Pour OpenCL, en effet, les démonstrations sont plutôt basiques, du genre convolution 2D, transformation de Fourrier ou calcul fractal. Intéressant… mais un moteur de lancer de rayons ou une librairie JPEG2000 m'auraient plus impressionné. Ça me rappelle un peu Altivec, le concept SIMD - Single Instruction Multiple Data - est d'ailleurs quasiment identique… L'unité Altivec des PowerPC n'a pas souvent fonctionné et Apple n'a pas vraiment donné l'exemple. Pour OpenCL, j'espérais une librairie de "haut niveau" (ndr : aisément utilisable par les développeurs), mais quand on regarde les spécifications, c'est vraiment du "bas niveau"… Tout est à inventer ! Le seul espoir de voir un jour ces technologies vraiment utilisées par les développeurs serait l'adoption sur Windows (j'ai comme un doute), afin de rationaliser l'investissement du développement. Et enfin, une dernière remarque sur OpenCL : pour bénéficier de l'accélération, il faut un GPU (ndr, processeur de la carte graphique), mais de l'autre côté, on voit bien qu'Intel fait tout pour se passer des GPU de nVidia et ATI, avec des processeurs graphiques intégrés. Est-ce qu'Intel va jouer le jeu d'OpenCL ? (ndr : Intel compte toutefois parmi les supporters d'OpenCL).

À part ça, je me réjouis de passer à un API QuickTime 100% Cocoa et 64-bit : ça va faciliter grandement l'utilisation de cette technologie dans OsiriX. Il faut dire que l'interface de programmation (API) de QuickTime était extrêmement vieille (elle date de la belle époque du système 6.0). Elle n'était pas orientée objet, elle était incompatible avec le multi-threading (on ne pouvait pas lancer deux compressions dans le même logiciel, par exemple) et elle était incompatible avec une application 64-bit. On a donc été obligés d'écrire une application fille en 32-bit, pilotée par OsiriX, ce qui rendait la programmation difficile et l'exécution peut performante.

Et enfin, on va éviter durant ces deux prochaines années au moins de faire une version d'OsiriX nécessitant obligatoirement Mac OS 10.6 pour fonctionner. Je pense en effet que beaucoup d'utilisateurs resteront à Mac OS 10.5, étant donné l'absence de réels changements immédiats à leur niveau. On ne veut pas perdre ces utilisateurs !"


Glen Aspeslagh : Ecamm
Editeur de pilotes de webcam et de petits utilitaires audio/vidéo

GA : "On n'a pas particulièrement prévu de grosses optimisations de nos applications pour Snow Leopard. En revanche on a beaucoup de travail à faire pour rendre compatible notre webcam Bluetooth et notre utilitaire pour iChat, car le framework 64 bits de Snow Leopard laisse de côté beaucoup d'ancien code de QuickTime. Je pense que dans un premier temps Snow Leopard va apporter quelques améliorations de performance visibles et sympathiques. Toutefois, du fait des changements intervenus dans les fondations, je suis prêt à parier que beaucoup de gens parmi ceux qui vont faire la mise à jour vont tomber sur au moins une application ou un plug-in qui ne fonctionnera plus. S'ils en ont un besoin vital, ils risquent d'être déçus. Ceci mis à part, je pense que les utilisateurs vont être assez satisfaits."


Mark Pearson : Plasq
Éditeur de logiciels de création graphique

MK : "Tout en vérifiant que nos applications fonctionnent avec Snow Leopard, on ne fait rien de particulier, du fait de notre volonté de rester compatible avec les précédentes versions de système. On est impatients d'exploiter les étonnantes nouvelles possibilités de Snow Leopard dans de futurs produits."

plasqcomComicLifeMagiq

avatar Nihondjin | 
Bah... ça intéresse personne ? Pourtant ça c'est du réactif, article bien passionnant qui remet les pieds sur terre. En même temps je me dis que c'est comme les nécrologies à la télé, c'est un peu préparé à l'avance.
avatar Bassman | 
Mouais. En gros, ils disent tous : "Wahou c'est GÉ-NIAL !" Mais ne s'y mettrons pas de suite dessus, "pour voir"…
avatar Gimli fils de Gloin | 
C'est surtout qu'il faut du temps pour maitriser Cuda ou sa généralisation OpenCL :o
avatar simno073 | 
article intéressant! plus qu'à le mettre en parallèle avec le test :) w&s
avatar bigmac2 | 
Attendre c'est prendre le risque que des brevets soient déposé sur une idée quasi identique mais n'utilisant pas les mêmes technologies (nouvelles et incontournables avec le temps) et donc, devenir un suiveur au lieu d'être celui qui mène. Au fait, vous pouvez tous être rassurés car, tous ces messieurs qui ont daigné à nous raconter des C*** dans cet interview, sont entrain de se donner comme des fous pour optimiser leurs softs pour justement éviter de se faire dépasser... En tout cas je l'espère pour eux.
avatar biniou | 
Est-ce qu'il y a toujours le support the SMIL avec QuicktimeX ?
avatar Arsenal Gear | 
Hé ben, j'espère que je ne vais pas regretter mon achat...
avatar Nihondjin | 
Pour Aperture, Apple doit montrer l'exemple, non de non !
avatar YAZombie | 
Et pendant ce temps-là l'équipe d'Agile Software a mis la main à la pâte et propose déjà une version 64 bits qui fonctionne (sans problème jusqu'ici) avec Safari 64 bits. De même, Transmission propose une beta 64 bits qui ne pose aucun problème… Je ne comprends pas très bien, parfois… Il y a ceux qui parlent et ceux qui font, c'est ça?
avatar Hasgarn | 
@ Bigmac 2: y'a intéret qu'ils mettent le paquet. Parce que si SL se vend et s'installe beaucoup dans les prochain mois, c'est les éditeurs qui vont de faire hurler dessus par des hordes d'utilisateurs qui se demande à quoi ça sert qu'Apple ait pris le risque de faire un OS avec des technologies de fond aux grandes capacités. Maintenant, il est vrai qu'on attend bien sur de la part d'Apple des Aperture et consort cleané pour SL. Pour ma part, j'attendrai Noël pour installer SL, histoire de voir la réactivité des éditeurs.
avatar FloMo | 
Je pense que Snow Leopard intègre de lui-même les optimisations et qu'une simple re-compilation améliore déjà les performances. Cela est sans doute dû à Grand Central Dispatcher, qui répartie la charge au niveau du système d'exploitation et non pas au niveau de l'application en elle-même. C'est d'ailleurs ce qui semble être dit par Nick Fletcher, qui a lui testé réellement le nouveau système. Pour ce qui est d'OpenCL et autres, c'est clair que les seuls qui auront vraiment un intérêt sont ceux qui font beaucoup de petits traitements simultanés, comme par exemple Adobe. Dans le même ordre d'idée, je pense qu'OpenCL est utilisée par les API Apple par exemple lorsque l'on modifie une image, que l'on exécute plusieurs calculs simultanés ou je ne sais quoi. Du coup, le développeur ne le voit pas mais pourtant il l'utilise. En clair, ça a l'air quand même pas mal !
avatar albinoz | 
Une démonstration de OpenCL pour encoder un film, ça nous aurait parlé… Pourtant à l'époque du VelocityEngine dit Altivec, FinalCut Pro avait été l'un des premiers produits à bénéficier de ce coup de fouet. Il faut que Apple se retire les doigts du c#*. :p
avatar gutiero | 
A quand l'update Adobe à 29€ ??
avatar oomu | 
"Grand Central Dispatcher" il faut que l'application l'utilise explicitement pour profiter de la gestion automatisée par le système. Il s'agit d'une rationalisation des ressources par le système : le système décide à la place du concepteur s'il faut ou non parralléliser les calculs mais encore faut il que le concepteur du logiciel ait utilisé Grand Central pour dire à os X quoi est parrallélisable. Il faut que le logiciel soit réécrit pour en tirer partie. Ce sont de nouveaux outils donnés aux développeurs. - Opencl est un langage proche de C pour écrire du code parrallélisable, qui peut être mis en oeuvre par des gpu nvidia/amd mais tout autant à l'avenir des processeurs intel multi-coeurs que ibm cell ou autre. Combien même si intel construit ses "gpu" à base de ses processeurs généralistes (larrabee), intel peut fournir le compilateur openCL pour tirer parti de ses processeurs. C'est tellement de bas niveau que des éditeurs proposeront sûrement des bibliothèques de fonctions prêtes à l'emploi pour os x/windows/linux mais encore une fois, il faut laisser le temps à l'industrie de s'y mettre. Ce n'est pas une solution immédiate pour Osirix qui n'a pas attendu l'arrivée de cuda ou opencl pour être efficace. Concrètement, OpenCL est une normalisation de ce que CUDA est à nvidia : un seul langage porté sur de multiples architectures (nvidia, amd, intel etc). - Larrabee, article Ars Technica de Août 2008 http://arstechnica.com/hardware/news/2008/08/larrabee-intels-biggest-leap-ahead-since-the-pentium-pro.ars (au final en avril 2009 il a été annoncé un produit larrabee pour fin 2009/2010. peu crédible)
avatar oomu | 
un Aperture profondément accéléré grâce à tout ça ? voilà qui impressionnerait les professionnels.
avatar Artanis | 
D'après ma (courte) expérience de développeur de codes en CUDA et en parallèle, on verra surtout la différence avec les nouvelles applications qui vont sortir et qui auront été conçues /dès le départ/ dans l'optique d'utiliser OpenCL ou GrandCentral. Il faut compter sur la diffusion des GPU compatibles au fil du temps vers le bas de la gamme pour que les devs commencent à se faire plaisir, et d'ici un an on devrait voir des choses très intéressantes. Ca ressemble un peu à l'introduction de CoreAnimation en fait: beaucoup de potentiel, y a plus qu'à laisser jouer les développeurs. Par contre je plussoie le monsieur qui dit qu'il faut des bibliothèques de haut niveau. OpenCL en l'état actuel des choses est assez imbuvable.
avatar Jerry Khan | 
On remarquera tout de suite la différence nette de discours entre Rosset et Aquafadas sur OpenCL...Les lectures sont extrêmement différentes.
avatar Almux | 
Intéressant dixit de Glen Aspeslagh : -"... Toutefois, du fait des changements intervenus dans les fondations, je suis prêt à parier que beaucoup de gens parmi ceux qui vont faire la mise à jour vont tomber sur au moins une application ou un plug-in qui ne fonctionnera plus. S'ils en ont un besoin vital, ils risquent d'être déçus. ..." Raison pour laquelle il FAUT TOUJOURS garder son ancien système sur une autre partition (ou disque bootable) quand on fait une MàJ majeure! CQFD
avatar oomu | 
Exemple d'application à greffons : Mail.app si votre greffon n'est pas réadapté au nouveau Mail (ou encore 64b) = boum. pareil pour les "input managers" et autre simbl.
avatar Anonyme (non vérifié) | 
Une avancé peut être seul l'avenir le dira, mais cela deviendra intéressant quand Apple sortira un correctif pour la première génération de MacPro (1.1, 2x 2,66Ghz pour pouvoir profiter du 64 bits car le modèle que j'ai. Sauf erreur de ma part ne pourra tourner qu'en 32 bits. Je viens de le commander, super ????
avatar Gimli fils de Gloin | 
Non, c'est le noyau qui tournera en 32 bits, les applis elles tourneront en 64 bits donc pas de soucis à te faire
avatar Macleone | 
[quote]pareil pour les "input managers" et autre simbl.[/quote] Tu peux toujours courir pour les InputManager. Apple a comblé cette faille du système qui traine depuis 10 ans, et apparemment ils n'ont pas l'intention d'en ouvrir de nouvelles. Snow Leopard, c'est suppression des Contextual Menu Item, et de la plupart des composants partagées. Apple ne veut pas qu'on puisse installer des composants qui se chargent dans toutes les applications sans demander son avis et ils ont bien raison.
avatar Macleone | 
jeanmi44: Si tu arrêtais de croire les n'importe quoi qu'on lit partout sur le noyau 64 bit et que tu te penchais un peu sur la réalité tu t'apercevrais qu'il n'y a jamais eu besoin d'un noyau 64 bits pour faire tourner des applis 64 bit et profiter au mieux du processeur et de la RAM. Tu n'as qu'a lancer le jeux d'échec sur Leopard pour t'en rendre compte.
avatar quantik2 | 
Ne confondez pas Noyaux 64bit et System 64 bit, ni encore Programme 64 bits avec les vieux model, le noyaux ne pourra pas demaré en 64 bits, mais le System oui, avec du coup des envoie dans la RAM en 64 bits. Tout le monde n'as pas besoin d'un noyaux en 64bits... meme pour être franc quasiment personne !
avatar lukasmars | 
"Si tu arrêtais de croire les n'importe quoi qu'on lit partout sur le noyau 64 bit et que tu te penchais un peu sur la réalité tu t'apercevrais qu'il n'y a jamais eu besoin d'un noyau 64 bits pour faire tourner des applis 64 bit et profiter au mieux du processeur et de la RAM." Ben voyons ! Encore des limitations volontairement introduites par Apple et injustifiables. enfin un monstre comme le Macpro qui demarre en 32 bits , c'est stupide . Pourquoi ne pas faire l'inverse ? proposer le demarrage sur un kernel 64 avec possibilité en cas de problèmes avec les drivers, de booter en 32 bits ? Là c'est le nivellement vers le bas . De plus , on se souviens que l'argument d'Apple pour l'abandon de la prise en charge des PowerPC était le passage à un 64 bits total dans Snow Leopard...

Pages

CONNEXION UTILISATEUR