Snow Leopard : l'avis des développeurs (suite)
Suite de nos interviews de développeurs sur le sujet de Snow Leopard. Avec cette question principale, que vont-ils faire des nouvelles technologies que sont OpenCL, Grand Central Dispatch ou le 64 bits ? Comme dans le précédent tour d'horizon, ces concepteurs d'applications soulignent l'importance des changements effectués dans le moteur de Mac OS X, et y voient avant tout un investissement sur l'avenir. Pour le moment présent, les utilisateurs devront se contenter d'un apéritif.
Oliver Breidenbach : Boinx
Éditeur de logiciels de création audio, photo et vidéo
OB : "De façon globale, ces technologies offrent une fondation modernisée sur laquelle on va fabriquer nos applications avec plus de facilité. On est très contents de ces améliorations, et à 29€ c'est un bon investissement pour tout le monde. Grand Central va permettre à nos logiciels d'utiliser les cycles processeurs de façon plus efficace. Le 64 bits signifie que l'on va pouvoir utiliser plus de mémoire et OpenCL permettra d'exploiter plus facilement la puissance des processeurs graphiques pour des tâches qui ne sont pas liées à la 3D.
Le fait qu'Apple utilise ces choses-là signifie que l'OS en lui-même fonctionne de manière plus efficace et libère plus de ressources pour nos applications. Au vu de tout cela, on n'a pas eu besoin de faire beaucoup de changements dans nos produits. Enfin, les utilisateurs vont se trouver face à un système plus réactif et nos programmes iront plus vite. Mais il est vrai aussi que cette sensation de vitesse accrue est une chose à laquelle on s'habitue très vite et qui s'évanouit bout d'un moment.
William Shipley : fondateur de Delicious Monster
Éditeur du catalogueur Library 2 et ancien co-fondateur d'OmniGroup.
WS : "Je vais certainement optimiser Delicious Library pour Snow Leopard. Il y a beaucoup de choses très cool dans Snow Leopard pour les développeurs. C'est vraiment une version qui nous est destinée, ainsi qu'à Apple pour nettoyer et moderniser les couches basses de Mac OS X.
Grand Central est utilisé partout dans Snow Leopard, c'est donc difficile de ne pas s'en servir lorsque vous faites de nouveaux développements. De manière générale, Apple a observé que les processeurs ne pouvaient pas aller beaucoup plus vite - l'énergie qu'ils utilisent, les dégagements de chaleur qu'ils produisent sont démultipliés par chaque accélération de fréquence. On a donc touché le plafond avec une marge de progression très délicate. Pour pallier cette situation, Intel et les autres ont commencé à réunir plusieurs processeurs sur une seule puce - imaginez une cuisine avec plusieurs cuisiniers, au lieu d'un seul à qui vous auriez demandé de travailler de plus en plus vite.
Mais, à l'image d'une cuisine, si vous avez plusieurs personnes, vous devez les gérer comme il faut, ou bien la plupart vont se croiser les bras pendant que d'autres se disputeront le mixeur. Grand Central permet à de simples développeurs de tenir tous ces cuisiniers occupés. Les autres systèmes d'exploitation (Windows, Linux, etc) utilisent la notion de "processus multiples" mais ils laissent aux développeurs le soin de les utiliser manuellement. Et réussir à concevoir un programme multi-threadé est très, très difficile (OmniWeb 2.0 était l'un des premiers programmes commerciaux utilisant largement ce système, et croyez-moi, c'était monstrueux à coder).
Dans Delicious Library 2 par exemple, je distribue déjà quelques processus - lorsque vous scannez un code-barre avec la webcam, le travail d'interprétation est fait sur un processeur différent, et lorsque vous consultez vos enregistrements ou publiez votre base sur le web, la partie réseau du code est également exécutée par un second processeur.
Avec Grand Central, je peux aller plus loin tout en faisant beaucoup moins d'efforts. Par exemple, je pourrais faire en sorte que chaque image du code-barre capturée par la webcam soit analysée par un processeur différent (au lieu d'avoir un seul processeur pour traiter toutes les images). Cela permettrait donc de traiter beaucoup plus d'images par seconde sur une machine équipe de nombreux processeurs (actuellement je saute des images si le temps pris pour analyser la précédente dépasse une certaine limite).
Ceci nous offre pour l'avenir de très bonnes fondations vis-à-vis de Windows - au fur et à mesure que les machines vont passer de 2 à 4 puis 8 et 16 coeurs, les applications écrites pour Snow Leopard vont aller de plus en plus vite, sans qu'il soit besoin de les modifier, tandis que les développeurs Windows vont devoir ferrailler pour tout simplement faire fonctionner leurs logiciels.
Le 64 bits est génial parce que ça nécessite très peu de travail de mon côté pour des bénéfices très importants. Tout d'abord, il s'avère que les applications recompilées en 64 bits tournent environ 15% plus vite, comme ça, directement, grâce aux améliorations obtenues au niveau du processeur. J'ai réalisé un premier portage 64 bits de Delicious Library 2 en deux jours. Je dois encore le tester, mais c'est tout de même étonnant d'obtenir 15% d'accélération avec deux jours de travail.
Le truc amusant c'est que ce gain en vitesse est une sorte d'effet collatéral : l'impulsion à aller vers le 64 bits est venue de contraintes sur l'utilisation de la mémoire. Dans un programme 32 bits, la taille maximale de "mémoire virtuelle" que votre logiciel peut utiliser est théoriquement de 4 Go. À moins que le développeur ne fasse de sérieux efforts, l'utilisateur ne pourra pas travailler avec des fichiers dépassant les 4 Go, et ce, quelle que soit la quantité de RAM ou d'espace disque disponibles.
Et en fait, la véritable limite n'est pas de 4 Go - le framework système et la mémoire vidéo utilisée pour l'affichage sont déduits de ce total, du coup vous ne pouvez compter que sur 2,5 Go environ en 32 bits (en 64 bits, les valeurs de RAM et de mémoire virtuelle sont d'une certaine manière illimitées).
Par exemple, ouvrir une image de 3 Go, ou même 3 images de 1 Go est impossible (sauf à ajouter un gros morceau de code à votre logiciel), ce qui devenait gênant alors que les images sont de plus en plus lourdes.
Avec Delicious Library 2, on a des utilisateurs qui ont des dizaines de milliers d'éléments et qui ont associé à chacun d'entre eux un visuel de couverture en haute définition. Leurs bibliothèques ont pris des proportions qui vont aussi au-delà de cette barrière. Avec une version optimisée Snow Leopard de Library, la taille de ces bibliothèques ne sera limitée que par l'espace disque de l'utilisateur !
Dans le même style, même si vous avez 4 ou 8 Go de RAM sur votre machine, un seul programme ne peut utiliser plus de 2,5 Go à la fois en 32 bits (du fait que la RAM et la mémoire virtuelle sont limitées par cet adressage 32 bits). Du coup, si vous remplissez votre Mac avec 8 Go de RAM en vous disant "Ma grosse collection dans Delicious Library va tourner du feu de Dieu" vous allez être déçu. Mais en 64 bits vous allez sauter au plafond.
OpenCL va être plus difficile pour moi à utiliser, parce que c'est un nouveau langage que je ne connais pas, et qui implique de profondes réécritures. Mais avec les processeurs graphiques qui gagnent en puissance beaucoup plus rapidement que le processeur principal, c'est à nouveau un coup assez malin de la part d'Apple, qui veut en faire quelque chose de relativement aisé à utiliser pour des logiciels d'usage général.
Dans Delicious Library 2 on verra peut-être une version du scanner de code-barre qui sera encore plus sensible. Parce qu'il fonctionne avec le processeur de la carte graphique et qu'il a toute la puissance nécessaire pour réaliser plus d'opérations sur chacune des images afin de leur arracher une interprétation plus fine du code-barre.
MacGeneration : Est-ce qu'il ne risque pas d'y avoir une certaine frustration au départ chez les utilisateurs, quand on voit qu'il y a ce travail préalable d'optimisation à faire sur les applications ?
WS : Pour être honnête, à court terme la plupart des utilisateurs ne vont pas profiter de beaucoup de choses de Snow Leopard. C'est une sortie très importante qui revoie le système au niveau du coeur, mais qui, de façon tout à fait intentionnelle, n'ajoute pas beaucoup de nouvelles fonctions ni de changements d'interface.
C'est comme d'avoir un nouveau moteur dans une vieille voiture, ça la rend plus performante et c'est beaucoup plus facile pour les mécaniciens d'apporter des changements ultérieurement. Ça n'amène pas de grandes différences sur l'instant, mais dans les dix prochaines années le bénéfice sera inestimable.
Ou pour utiliser une autre analogie, je pense que cette version va ressembler au passage des ampoules incandescentes aux ampoules fluorescentes compactes et aux lampes LED. Demain, vous aurez toujours de la lumière, mais c'est une lumière qui est tournée vers l'avenir. Et chaque année qui passera, vous serez de plus en plus heureux d'avoir fait ce changement."
Oliver Breidenbach : Boinx
Éditeur de logiciels de création audio, photo et vidéo
OB : "De façon globale, ces technologies offrent une fondation modernisée sur laquelle on va fabriquer nos applications avec plus de facilité. On est très contents de ces améliorations, et à 29€ c'est un bon investissement pour tout le monde. Grand Central va permettre à nos logiciels d'utiliser les cycles processeurs de façon plus efficace. Le 64 bits signifie que l'on va pouvoir utiliser plus de mémoire et OpenCL permettra d'exploiter plus facilement la puissance des processeurs graphiques pour des tâches qui ne sont pas liées à la 3D.
Le fait qu'Apple utilise ces choses-là signifie que l'OS en lui-même fonctionne de manière plus efficace et libère plus de ressources pour nos applications. Au vu de tout cela, on n'a pas eu besoin de faire beaucoup de changements dans nos produits. Enfin, les utilisateurs vont se trouver face à un système plus réactif et nos programmes iront plus vite. Mais il est vrai aussi que cette sensation de vitesse accrue est une chose à laquelle on s'habitue très vite et qui s'évanouit bout d'un moment.
William Shipley : fondateur de Delicious Monster
Éditeur du catalogueur Library 2 et ancien co-fondateur d'OmniGroup.
WS : "Je vais certainement optimiser Delicious Library pour Snow Leopard. Il y a beaucoup de choses très cool dans Snow Leopard pour les développeurs. C'est vraiment une version qui nous est destinée, ainsi qu'à Apple pour nettoyer et moderniser les couches basses de Mac OS X.
Grand Central est utilisé partout dans Snow Leopard, c'est donc difficile de ne pas s'en servir lorsque vous faites de nouveaux développements. De manière générale, Apple a observé que les processeurs ne pouvaient pas aller beaucoup plus vite - l'énergie qu'ils utilisent, les dégagements de chaleur qu'ils produisent sont démultipliés par chaque accélération de fréquence. On a donc touché le plafond avec une marge de progression très délicate. Pour pallier cette situation, Intel et les autres ont commencé à réunir plusieurs processeurs sur une seule puce - imaginez une cuisine avec plusieurs cuisiniers, au lieu d'un seul à qui vous auriez demandé de travailler de plus en plus vite.
Mais, à l'image d'une cuisine, si vous avez plusieurs personnes, vous devez les gérer comme il faut, ou bien la plupart vont se croiser les bras pendant que d'autres se disputeront le mixeur. Grand Central permet à de simples développeurs de tenir tous ces cuisiniers occupés. Les autres systèmes d'exploitation (Windows, Linux, etc) utilisent la notion de "processus multiples" mais ils laissent aux développeurs le soin de les utiliser manuellement. Et réussir à concevoir un programme multi-threadé est très, très difficile (OmniWeb 2.0 était l'un des premiers programmes commerciaux utilisant largement ce système, et croyez-moi, c'était monstrueux à coder).
Dans Delicious Library 2 par exemple, je distribue déjà quelques processus - lorsque vous scannez un code-barre avec la webcam, le travail d'interprétation est fait sur un processeur différent, et lorsque vous consultez vos enregistrements ou publiez votre base sur le web, la partie réseau du code est également exécutée par un second processeur.
Avec Grand Central, je peux aller plus loin tout en faisant beaucoup moins d'efforts. Par exemple, je pourrais faire en sorte que chaque image du code-barre capturée par la webcam soit analysée par un processeur différent (au lieu d'avoir un seul processeur pour traiter toutes les images). Cela permettrait donc de traiter beaucoup plus d'images par seconde sur une machine équipe de nombreux processeurs (actuellement je saute des images si le temps pris pour analyser la précédente dépasse une certaine limite).
Ceci nous offre pour l'avenir de très bonnes fondations vis-à-vis de Windows - au fur et à mesure que les machines vont passer de 2 à 4 puis 8 et 16 coeurs, les applications écrites pour Snow Leopard vont aller de plus en plus vite, sans qu'il soit besoin de les modifier, tandis que les développeurs Windows vont devoir ferrailler pour tout simplement faire fonctionner leurs logiciels.
Le 64 bits est génial parce que ça nécessite très peu de travail de mon côté pour des bénéfices très importants. Tout d'abord, il s'avère que les applications recompilées en 64 bits tournent environ 15% plus vite, comme ça, directement, grâce aux améliorations obtenues au niveau du processeur. J'ai réalisé un premier portage 64 bits de Delicious Library 2 en deux jours. Je dois encore le tester, mais c'est tout de même étonnant d'obtenir 15% d'accélération avec deux jours de travail.
Le truc amusant c'est que ce gain en vitesse est une sorte d'effet collatéral : l'impulsion à aller vers le 64 bits est venue de contraintes sur l'utilisation de la mémoire. Dans un programme 32 bits, la taille maximale de "mémoire virtuelle" que votre logiciel peut utiliser est théoriquement de 4 Go. À moins que le développeur ne fasse de sérieux efforts, l'utilisateur ne pourra pas travailler avec des fichiers dépassant les 4 Go, et ce, quelle que soit la quantité de RAM ou d'espace disque disponibles.
Et en fait, la véritable limite n'est pas de 4 Go - le framework système et la mémoire vidéo utilisée pour l'affichage sont déduits de ce total, du coup vous ne pouvez compter que sur 2,5 Go environ en 32 bits (en 64 bits, les valeurs de RAM et de mémoire virtuelle sont d'une certaine manière illimitées).
Par exemple, ouvrir une image de 3 Go, ou même 3 images de 1 Go est impossible (sauf à ajouter un gros morceau de code à votre logiciel), ce qui devenait gênant alors que les images sont de plus en plus lourdes.
Avec Delicious Library 2, on a des utilisateurs qui ont des dizaines de milliers d'éléments et qui ont associé à chacun d'entre eux un visuel de couverture en haute définition. Leurs bibliothèques ont pris des proportions qui vont aussi au-delà de cette barrière. Avec une version optimisée Snow Leopard de Library, la taille de ces bibliothèques ne sera limitée que par l'espace disque de l'utilisateur !
Dans le même style, même si vous avez 4 ou 8 Go de RAM sur votre machine, un seul programme ne peut utiliser plus de 2,5 Go à la fois en 32 bits (du fait que la RAM et la mémoire virtuelle sont limitées par cet adressage 32 bits). Du coup, si vous remplissez votre Mac avec 8 Go de RAM en vous disant "Ma grosse collection dans Delicious Library va tourner du feu de Dieu" vous allez être déçu. Mais en 64 bits vous allez sauter au plafond.
OpenCL va être plus difficile pour moi à utiliser, parce que c'est un nouveau langage que je ne connais pas, et qui implique de profondes réécritures. Mais avec les processeurs graphiques qui gagnent en puissance beaucoup plus rapidement que le processeur principal, c'est à nouveau un coup assez malin de la part d'Apple, qui veut en faire quelque chose de relativement aisé à utiliser pour des logiciels d'usage général.
Dans Delicious Library 2 on verra peut-être une version du scanner de code-barre qui sera encore plus sensible. Parce qu'il fonctionne avec le processeur de la carte graphique et qu'il a toute la puissance nécessaire pour réaliser plus d'opérations sur chacune des images afin de leur arracher une interprétation plus fine du code-barre.
MacGeneration : Est-ce qu'il ne risque pas d'y avoir une certaine frustration au départ chez les utilisateurs, quand on voit qu'il y a ce travail préalable d'optimisation à faire sur les applications ?
WS : Pour être honnête, à court terme la plupart des utilisateurs ne vont pas profiter de beaucoup de choses de Snow Leopard. C'est une sortie très importante qui revoie le système au niveau du coeur, mais qui, de façon tout à fait intentionnelle, n'ajoute pas beaucoup de nouvelles fonctions ni de changements d'interface.
C'est comme d'avoir un nouveau moteur dans une vieille voiture, ça la rend plus performante et c'est beaucoup plus facile pour les mécaniciens d'apporter des changements ultérieurement. Ça n'amène pas de grandes différences sur l'instant, mais dans les dix prochaines années le bénéfice sera inestimable.
Ou pour utiliser une autre analogie, je pense que cette version va ressembler au passage des ampoules incandescentes aux ampoules fluorescentes compactes et aux lampes LED. Demain, vous aurez toujours de la lumière, mais c'est une lumière qui est tournée vers l'avenir. Et chaque année qui passera, vous serez de plus en plus heureux d'avoir fait ce changement."
Pages