Quelles applications pour OpenCL ?

Arnaud de la Grandière |
S'il est une fonctionnalité de Snow Leopard qui aura beaucoup fait parler d'elle, c'est bien OpenCL. D'une part parce qu'elle alimente bien des convoitises, pour peu qu'elle remplisse les promesses mirobolantes de la puissance supposée des GPGPU en matière de calcul parallèle, et d'autre part parce qu'Apple a réussi le tour de force de l'imposer comme standard, alors que chaque constructeur y allait de son jeu d'API.

Or, pour que l'avantage soit immédiat pour les futurs achats de Snow Leopard, faut-il encore qu'ils puissent en tirer parti. Nul doute que les API intégrées au système exploiteront OpenCL autant que possible, à commencer par QuickTime, dont le codec H264 est très gourmand pour la décompression comme pour la compression. De même, Core Image devrait s'avérer nettement plus véloce, et par voie de conséquence tous les logiciels qui en tirent parti. On pourrait même retrouver OpenCL dans des couches insoupçonnées du système, par exemple dans Mail.app, le parallélisme étant particulièrement indiqué pour le filtre bayésien de son anti-spam.

Certes, tous les types de calculs ne se prêtent pas au parallélisme, et il ne faut pas s'attendre à une accélération généralisée de nos machines. Toutefois, dans les cas spécifiques concernés, la différence devrait se faire sentir de manière flagrante.

Il n'est d'ailleurs pas exclu qu'Apple livre une mise à jour de sa suite iLife une fois que Snow Leopard sera disponible à la vente. On imagine bien en effet que le stabilisateur d'image d'iMovie ou la reconnaissance faciale d'iPhoto, deux fonctions particulièrement gourmandes en calcul, connaissent un sérieux coup de booster à l'aide d'OpenCL. De même pour GarageBand, puisque les filtres audio devraient également s'en trouver grandement accélérés, le parallélisme étant particulièrement indiqué pour le DSP et la transformée de Fourier rapide. C'est en tout cas ce qu'envisage un article de Tom's Hardware, bien qu'Apple nous ait historiquement habitués à n'exploiter les fonctions exclusives de son dernier OS en date qu'avec des mises à jour majeures d'iLife.

L'idée n'est pourtant pas saugrenue, car en dehors des nouveaux éléments d'interface, qui resteront très sobres pour Snow Leopard, les nouvelles API ne sont visibles pour les utilisateurs que si les logiciels en tirent parti. Naturellement, les développeurs qui participent au beta-test de Snow Leopard travaillent à exploiter ces API, OpenCL et Grand Central en tête, pour pouvoir livrer des mises à jour de leurs logiciels dès la mise sur le marché du prochain félin d'Apple. Le champ d'application est à la fois vaste et restreint : raytracing, radiosité, modèles physiques et gestion des particules pour la 3D, traitement du signal de manière générale (compression vidéo, calculs de filtres bitmaps, filtres audio...), calcul scientifique et son cortège de simulations (prévisions météo, physique quantique, modélisation moléculaire, imagerie médicale...), gestion de bases de données, réseaux neuronaux, reconnaissance visuelle, cryptographie, bref, tout un tas d'applications qui jusqu'ici étaient hors de portée des ordinateurs du commun. Nous verrons donc des fonctions existantes gagner en rapidité, mais également de nouvelles fonctions qui jusqu'ici n'étaient tout simplement pas à la portée des seuls Core 2 Duo qui animent nos machines.

Néanmoins, nul n'est prophète en son pays, et il faudra qu'Apple soit la première à démontrer l'utilité et l'efficacité d'OpenCL en l'exploitant dans toute son offre logicielle. On imagine d'ailleurs sans mal le gain qu'une telle technologie apportera aux suites professionnelles comme Motion, Final Cut Pro, Shake, ou encore Aperture, des logiciels non seulement voraces en puissance de calcul, mais dont le champ d'application se prête très bien au calcul parallèle. On devrait donc voir des mises à jour particulièrement plus véloces pour ces logiciels, et on peut d'ores et déjà s'attendre à des tableaux comparatifs avant/après qui mettront en lumière les gains substantiels.

Comme toujours, il faudra donc mettre nos logithèques à jour pour tirer pleinement parti de Mac OS X 10.6, ce qui entraînera un coût supplémentaire dans certains cas. Mais tel est le prix à payer pour voir nos machines transformées en foudres de guerre, ce qui se paye autrement plus cher quand on passe par la voie matérielle.

Sur le même sujet :
- OpenCL accéléré pour Snow Leopard
- Apple met les pieds dans la guerre du GPGPU
- Apple tire le jus des processeurs

avatar pwetpwet | 
"Comme toujours, il faudra donc mettre nos logithèques à jour pour tirer pleinement parti de Mac OS X 10.6, ce qui entraînera un coût supplémentaire dans certains cas. Mais tel est le prix à payer pour voir nos machines transformées en foudres de guerre, ce qui se paye autrement plus cher quand on passe par la voie matérielle." Je ne serais pas aussi catégorique. Les licences des logiciels les plus aptes à profiter de ce genre de bond sont quand même très chères en général. A mon précédent job, les graphistes bossaient avec la Creative Suite sur des iMacs par exemple.
avatar biglittledragoon | 
Encore un bon article de fond, qui permet de voir un peu mieux où on va. Je me pose aussi la question de savoir si cette nouvelle possibilité va bien être exploitée. Quand on voit comment le Cocoa a été adopté ou encore le paquet de Carbon qui reste… Si les développeurs en vue (Adobe et Cie) n'investissent pas en ce sens (quelqu'un a parlé de "Crise?"), ce ne sera qu'une demi-avancée.
avatar YAZombie | 
Je me demandais ce qu'il en était de Safari? Une chance de le voir gagner en rapidité? Avec la course actuelle à celui qui a la plus grosse… machine javascript, ça pourrait être un nouveau moyen de gagner du terrain, non?
avatar macbob (non vérifié) | 
Et bien ces màj là, je les ferai volontiers si le résultat est là... sans parler du fait que j'attends Snow et une màj des MacPros pour une acquisition matérielle...
avatar macbob (non vérifié) | 
@pwetpwet Je vois pas le rapport ???
avatar DrFatalis | 
Nul doute que les soft apple exploitent ces nouvelles possibilités. mais je doute très fortement que les adobes et autres microsoft utilisent quoi que ce soit des nouveautés, sauf à avoir un pistolet sur la tempe (du genre OPA sauvage aapl rachéte adobe...). Maintenant, écrire "Comme toujours, il faudra donc mettre nos logithèques à jour pour tirer pleinement parti de Mac OS X 10.6, ce qui entraînera un coût supplémentaire dans certains cas. ", c'est d'une délicatesse byzantine, car on ne peut ignorer que de nombreuses machines actuellement utilisées (G4,G5, premiers intels) ne pourront pas utiliser SL. Un éventuel changement hard + soft est a prévoir, et ça va coûter ! Et si Apple en venait à louer ses logiciels pros ?
avatar Atlante | 
Bien quand on voit le retard accumulé par les G4 au moment du passage à Intel, les voir disparaitre est plutôt une bonne chose. Le G5 par contre, il est encore jeune, mais va subir les conséquences des faiblesses des G4... :(
avatar shirm | 
[quote= Dr. Fatalis: je doute très fortement que les adobes et autres microsoft utilisent quoi que ce soit des nouveautés, sauf à avoir un pistolet sur la tempe] Le pistolet sur la tempe peut tout simplement prendre la forme d'un traitement d'image ou vidéo mettant deux à trois fois moins de temps (si ce n'est 10), ce qui les rendrait complètement hors compétition sur le marché pro, assez friand de tout ce qui peut faire gagner en productivité. Pour avoir joué un peu avec Cuda, on peut attendre pas mal de cette techno, mais il faut aussi avoir en tête que ça consomme sec une carte graphique, et ça se ressent pas mal sur l'autonomie d'un laptop par exemple.
avatar nicogala | 
@Fatalis : certes le parc de PPC et de Yonah est encore important, mais lors de la sortie de SL ces machines auront au minimum 3 ans (MacPro) à 3 ans et demi (les autres) , un pro ne se rue pas sur une 10.6.0 et attendra bien qques mois/MAJ pour investir (donc ses anciennes machines auront au minimum 4 ans) et s'il a vraiment besoin de puissance, il n'hésitera pas à changer de machine (sinon c'est qu'il n'en a pas vraiment besoin, car comparer un G4 @ 1,5Ghz ou même un bi-G5 @ 2,5Ghz 4 core qui se fait laminer par un iMac C2D @ 2,66Ghz ... avec un MacPro 2,7fois plus puissant : c'est pas sérieux...) C'est exactement comme le pro qui aurait acheté en 2006 (pas de bol) un PM G5 2x2,5Ghz pour remplacer un PM G4 2x1,25Ghz sorti 4ans plus tôt... : même différence de puissance facteur 3 , même investissement. Là personne n'aurait râlé ou trouvé ça abusé ou insensé... Bref, le Pro qui en a besoin pourra changer ses machines qui auront plus de 4 ans de vétusté sans trop de remords , c'est une durée de vie/renouvellement "standard" communément admise pour qui veut rester "dans le bain" . Pour en revenir à ta citation : bien évidement l'article parle implicite des configurations qui pourront en tirer partie, on va pas parler de ceux qui sont pas concernés par la news (non, il n'y aura pas de QuickTime X pour les Performas, c'est officiel...) Ceci dit ton "aigreur" est compréhensible... mais c'est Apple, c'est comme ça depuis tjrs et c'est pour ça qu'elle fait avancer l'info et rêver tt le monde
avatar bendder | 
Petite question par hasard pour un mac pro sous SL il est mieux d'avoir 2 carte ATI HD 2600 ou une 8800 de NVIDIA?
avatar MacexpertFrance | 
Moi perso je trouve idi.t cette histoire d'open. Déjà il faudrait qu'apple exploite complètement le multi coeur avant de vouloir exploiter autre chose. Et surtout je vois pas l'intérêt du parallélisme d'application sauf un faire bien chauffer le GPU afin d'avoir plein de problème graphique et plein de retour SAV. Tous le monde sait qu'apple n'a jamais été au top sur la fiabilité de leur puce (rappelez vous du G3-G4....)
avatar YAZombie | 
Il a dit "expert"???
avatar kubernan | 
Je reste dubitatif quant à l'usage d'OpenCL sur le filtrage bayesien des e-mails. Un tel filtre est peu gourmand en ressource, les calculs ne sont pas si intenses que cela (c'est une des forces de ce type de traitement). Bref, le gain pourrait-être négligeable . Enfin... je verrai ça sur mes propres soft... Si et SEULEMENT SI une couche cocoa existe.
avatar Archaon59 | 
Je pense qui si Apple préfère OpenCL à une optimisation multicore, c'est que les cartes graphiques représentent des capacités phénoménales dans certains types de calculs, alors que développer pour du multicore requiert apparemment plus de boulot, et n'est pas adapté aux choses qui sont demandées, les applications lourdes sont surtout graphiques (Toshop, Aperture, iMovie ...) . De même, on pourra avoir une impressionnante réactivité de l'interface (mon MBP début 2008 n'est pas entièrement fluide, dés que j'ai un effet de transparence avec du blur, ou dés que j'active le zoom sur le dock 3D, on voit bien qu'on atteint pas du 40 IPS ...) . Par contre je suis assez étonné d'entendre parler de MAO dans cette histoire, ça serait une bonne nouvelle, même s'il est largement utilisable, un petit coup de speed sur GarageBand le rendrait plus agréable :) ! Je rêve de voir toutes mes actions se faire (presque) instantanément, autant en retouche qu'en MAO ou en éditions vidéo, j'espère que Snow Leopard me rapprochera de ce rêve ^^ . PS : Pour ceux qui ne sont pas convaincus de la contribution que peux avoir un GPU sur l'interface, suffit d'aller voir côté Ubuntu avec Compiz Fusion : avec des effets de blur, de reflets et 30 fenêtres d'ouvertes, je ne ramais pas du tout avec ma Geforce 6800LE ...
avatar pecos | 
ce que je trouve sidérant, c'est qu'il y ait tant de gens (de plus en plus), pour croire que l'amélioration des performances d'un soft passe obligatoirement par des machines plus puissantes, plus parallelles, plus de plus de plus... N'importe quel programmeur honnête (en reste-t-il ?) sait au contraire qu'un soft peut être accéléré beaucoup plus en optimisant le code. les exemple ne manquent pas ! (soit en bien, soit en mal...) La seule conséquence de l'adoption de cette technologie sera, comme d'habitude, que dans 5 ans on fera la même chose que sur les machines actuelles, mais en ayant besoin de 10x plus de puissance, parce qu'on aura pas optimisé les softs. Et pourquoi le ferait-on, puisque la puissance sera là ? je sais bien que certaines tâches requièrent des puissance brutes énormes (encodage video...) mais cela a-t-il bien sa place dans des ordinateurs "personnels" ? On traitait déjà de la video il y a 15 ans avec des bousins d'une puissance à peine supérieure à une calculatrice... mais avec des DSPs ! Pourquoi imposer ça dans tous les ordis ? Pour qu'au final, tous les softs, y compris un bête traitement de texte, en aient besoin ? BEUARKK. scusez moi c'est le cuda qui passe mal... indigeste ce truc...
avatar oomu | 
@ MacexpertFrance vous avez tort. surtout que justement il s'agit d'exploiter ce que vous dites. et les chiffres et études sur les retours et pannes dans l'industrie contredisent votre affirmation sur le "tout le monde sait". Et les études sur le classement que les gens font des constructeurs d'ordinateurs disent le contraire aussi de ce que vous pensez que "tout le monde" sait.
avatar oomu | 
@yazombie "Je me demandais ce qu'il en était de Safari? Une chance de le voir gagner en rapidité? Avec la course actuelle à celui qui a la plus grosse… machine javascript, ça pourrait être un nouveau moyen de gagner du terrain, non? " le système aura encore plus de facilité pour répartir les éventuels traitement javascript de vos site favoris (gmail etc, ) , la gestion de l'interface graphique, et le décodage de cette excellent épisode de House regardé sur youtube en flash. Bref, oui. sans compter le très important gain de performance et souplesse du nouveau moteur javascript de safari 4. (et firefox 3.1 et opera 11 et google chrome)
avatar oomu | 
vous êtes concentrés sur "opencl" je vous rappelle qu'il y a aussi ce qu'apple nomme "grandcentral" ca va de paire avec opencl, pour répandre les calculs sur tout ce que la machine peut fournir. Bref, snow leopard n'est pas censé se contenter de chauffer que le GPU.
avatar Michel Poulain | 
Euh... Une question : une date de sortie pour Snow Leopard, depuis qu'on en parle ?
avatar misterbrown | 
La honte c est que sur Leopard, Quartz Extreme, ou Quartz 2D, comme vous voulez n'est toujours pas activé. Et dire que c etait un truc qu'on avait sous Panther.......... :(
avatar Hindifarai | 
@ pecos Vous ne semblez pas au fait des réalités actuelles du marché. Comparez pour une entreprise qu'elle soit moyenne ou petite le coût d'une optimisation d'un logiciel au coût d'un upgrade materiel...vous comprendrez pourquoi les optimisations sont si rares. Il en va de même pour les produits grands publics qui auraient un prix bien plus élevé s'ils étaient optimisés. J'ai eu à me pencher sur une optimisation de code, j'ai travaillé bien entendu au niveau hexa et assembleur. La conclusion que j'ai pu en faire et qui a été confirmée par mes collègues errudis dans le domaine est que les procs x86 sont une totale abberation. L'architecture x86 a évolué par ajout de couches successives pour aboutir à quelque chose d'immonde (ISA au départ 16 bits, ensuite étendu à 32, et encore à 64). Le nombre de registres disponibles (8 en 16/32, et encore avec 6 concrètement utilisables) est risible. C'est à peine mieux en x86_64, puisque pour utiliser les 8 registres supplémentaires (total de 16 donc), il faut utiliser un préfixe... Alors c'est sûr, ce n'est pas spécifique au SMP, ça prouve que c'est juste une architecture de merde. Si on ajoute à ça les problèmes du passages multi-proc au multicore on a la cerise sur le gâteau. Apple au lieu de bosser sur valgrind ou une aternative à acumum va bosser sur openCL, ce qui démontre une nouvelle fois leur belle vision à long terme(sic).
avatar pickwick | 
@MacexpertFrance e monde sait qu'apple n'a jamais été au top sur la fiabilité de leur puce (rappelez vous du G3-G4....)" les puces des G3 et g4 pas fiables ???? du grand n'importe quoi quand on voit encore les imac G3 DV400 tourner avec Tiger sans souci et pas si lentement que cela si on a de la mémoire...
avatar cparm | 
ce n'est pas sur du tout que les éditeurs, fassent des mises a jour payantes, car a ma connaissance il suffira de recompiler les sources avec le xcode de snow pour que l'application soit opencl et grand central ready, il n'y aura rien a ajouté ni a enlevé, tout est fait par le compileur dans ces conditions, il est possible que les m-a-j des logiciels tiers soit gratuite
avatar pecos | 
@ Hindifarai : Très intéressant, ce que vous dites. Je comprends d'ailleurs très bien que quelquefois le coût d'une optimisation soit jugé prohibitif. Cependant il y a des limites : - lorsqu'on utilise un simple traitement de texte comme openOffice.org 3 et que la première lettre tapée met 3 secondes à arriver à l'écran, dans chaque document ouvert, n'y a-t-il pas quand même nécessité d'optimisation ? - de même, lorsqu'on constate qu'entre la version 9.0 de Newtek Lightwave 3D et sa version 9.6, certaines fonctions ont été accélérées d'un facteur 5, ou 10, voire 20 et plus ? Ne faut-il pas saluer le travail des développeurs et arrêter de parler de fatalisme ? Alors je veux bien que X86 soit une architecture horrible, mais les résultats, pour les même fonctions, sont si disparates suivant les programmes qu'à mon avis, on peut mieux faire dans bien des domaines, même avec cette architecture horrible. ;-) En tous cas, l'arrivée d'une puissance de calcul supplémentaire ne va pas, à mon avis, pousser les développeurs à plus d'optimisation... au contraire...
avatar Hindifarai | 
@ cparm C'est partiellement faux(et donc partiellement vrai). Les applications tirant parties d'API du systèmes qui elles-même(que l'on connaisse le code ou non) appelle des methodes du systèmes réécrites pour OpenCL verront leurs performances améliorées sans réécriture de code. Mais les applications ayant une série de fourrier rapide codée en dur(pour reprendre l'exemple) devront réécrire leur code pour passer par OpenCL et améliorer les perfs, pour illustrer mes propos regardez le code ici http://en.wikipedia.org/wiki/OpenCL .
avatar Hindifarai | 
@ pecos L'optimisation est un sujet vaste. Les problèmes de performances peuvent venir du compilateur/interprete, du langage, de la machine, des algorithmes. Mes remarques concernant l'architecture x86 reprend les deux premiers points, les compilateurs n'étant pas encore optimisés pour les nouvelles architectures multi-coeurs et ces mêmes multi-coeurs n'étant pas optimisés quoi qu'en dise la parfaite propagande d'AMD et Intel. Pour ce qui est des langages c'est un débat sans fin, certains ont des librairies adaptées au multi-threading et permettant d'optimiser le code pour les nouvelles architectures. Ensuite il faut des développeurs connaissant ces technologies, ce n'est pas la majorité des développeurs loin de là. Comme je l'ai dit en environnement industriel ce sera aux DSI de choisir comment résoudre les problèmes de performances, ils axeront vers le matériel car c'est la voie la moins coûteuse à court-terme(pour une écrasante majorité mais je ne fais pas ici de généralité bien sur). Pour le reste et les applications grands public il y a de tout, des applications optimisées(tel VLC cité avant, ormis leur couche IHM avec un code Qt qui me parait lourd), des applications lentes(tout le monde en connait). L'optimisation des algorithmes est une chose très souvent faite dans le monde du libre du fait de l'accès au code source et du fait que ces mêmes logiciels doivent être largement meilleur que le concurrent commercial pour sembler simplement compétitif aux yeux du public. L'optimisation d'un progiciel faite par une SSII en code fermé est une chose qui n'arrive jamais(mais vraiment jamais pour le coup). L'optimisation d'un logiciel propriétaire et grand public n'est fait que si les performances ne sont vraiment pas à la hauteur, à partir d'une barre franchie cette phase est stoppée pour ne pas alourdir la lisibilité du code en interne et permettre que le code reste évolutif.
avatar Hindifarai | 
(suite) [quote]de même, lorsqu'on constate qu'entre la version 9.0 de Newtek Lightwave 3D et sa version 9.6, certaines fonctions ont été accélérées d'un facteur 5, ou 10, voire 20 et plus ? Ne faut-il pas saluer le travail des développeurs et arrêter de parler de fatalisme ?[/quote] Bien sûr que si. Je ne suis pas fataliste à long terme, je le suis à court terme. Lorsque les architectures multi-coeurs auront plus d'inconvénients que d'avantages la donne changera. D'autant que les grands industriels n'investissent pas dans les projets de recherches académiques qui les aideraient grandement. [quote]En tous cas, l'arrivée d'une puissance de calcul supplémentaire ne va pas, à mon avis, pousser les développeurs à plus d'optimisation... au contraire...[/quote] Non ça n'arrangera pas la bien connue vision du développeur "c'est pas grave...ça marche".
avatar cparm | 
@ Hindifarai en effet, a la lumière, de ton lien les algorithmes devront être ré-ecrite , mais j'ai plus envie de dire convertie, ( moi qui croyait que c'était un module "on the fly" , je suis un peu decu), quand est t'il de grand central ??
avatar Hindifarai | 
Pour grandcentral je n'ai pas trouvé assez d'informations pour juger, je peux parler des travaux académiques sur le sujet(un français actuel sur la problématique d'un proc à 256 coeurs) et des différentes vision du problème sous-jacent. Mais je ne connais rien du projet, je ne sais même pas si une API sera dispo pour permettre aux devs de controler le parallelisme ou si ça sera totalement opaque(ça peut être bien aussi, voir meilleur). Ca semble être un projet complètement proprio ce que je comprends, bien que j'aurais préféré que sur ce point Apple investisse dans un projet libre. Si un OS qui ne se destine plus au marché pro devient plus performant sur des archis multi-coeurs que des bsd ou gnu/linux je pense que la boucle de l'incongru sera bouclée. A voir également si grandcentral sera réellement performant sur toutes les machines multi-coeurs, les problématiques entre un quad-core et un dual-core sont différentes. Il y aura des tonnes de benchs effectués à la sorties de l'os c'est certain. Tout aussi certain qu'ils seront un peu moins gratifiants que ceux que présentera ipappy à la cérémonie de snow leopard mais j'ai tout de même hâte de voir les gains réels que celà apportera.
avatar hooola | 
Pour ceux qui veulent essayer sous windows : badaboom, mpchc , c'est impressionant .
avatar Gabone | 
@MacexpertFrance, Tous le monde sait qu'apple n'a jamais été au top sur la fiabilité de leur puce (rappelez vous du G3-G4....) encore un qui ce dit expert et qui ni comprend rien
avatar Anonyme (non vérifié) | 
Mon vieux powerbook G4 & son Tiger font pâlir de jalousie les performences de mon tout nouvel Imac intel 3,06GHz.
avatar Gabone | 
la fiabilité du PPC est incontestablement trait bonne même une des meilleure
avatar Newton Pippin | 
@rafbeyonddriven euh, c'est ironique j'éspère ? parce que du temps de mon G4 quicksilver dual 1.25, quand je lançais un encodage handbrake ou quand je faisais des projets MAO sur Logic, ça mettait des plombes et dans Logic au bout de quelques plugs ins gourmants d'ouvert, le mac était à genoux...rien à voir avec un Quad Core d'aujourd'hui qui (heureusement) l'explose en terme de performance.

CONNEXION UTILISATEUR