Photoshop CS5 : plus de cœurs, moins de performances

Anthony Nelzin-Santos |
Mac Performance Guide se penche sur un problème que nous avons déjà eu l'occasion d'évoquer : la multiplication des cœurs processeurs ne favorise pas Photoshop, bien au contraire.

La conclusion de leurs tests est simple : Photoshop CS5 est incapable d'utiliser correctement plus de 4 cœurs. Passé ce chiffre, les performances ne s'améliorent qu'à la marge, et finissent même par décliner ! Ainsi, passer d'un Mac Pro 4 cœurs à 3,33 GHz doté de 24 Go de RAM à un Mac Pro 8 cœurs à 3,33 GHz doté de la même quantité de mémoire n'améliore les performances que de 10 %. Et passer à un Mac Pro 12 cœurs à 3,33 GHz avec 48 Go de RAM ne sert à rien : les performances sont alors en baisse de 32 % !

C'est le cœur même de Photoshop qui serait en cause : son architecture aurait été conçue pour 2 à 4 cœurs, et les algorithmes ne tireraient pas parti de plus de cœurs. Pire : l'adressage des threads processeur serait un véritable défi quand ceux-ci se multiplient, au point de créer une sorte de goulot d'étranglement qui ralentit Photoshop dès que l'on passe à 12 cœurs.

skitched

Une solution proposée par Mac Performance Guide est de désactiver l'HyperThreading lors de l'utilisation de Photoshop sur une machine à 12 cœurs. Pour ce faire, vous devez installer les outils développeurs, fournis sur le DVD d'installation de Mac OS X, et utiliser par exemple Onyx pour installer le panneau de préférences Processor.
avatar 2-fre | 
mort de rire... prem's !!
avatar parafsuo54000 | 
C'est pas a ça que grand central devait servir?
avatar Gr3gZZ | 
2-fre : Maintenant cite une application qui est capable de bien utiliser autant de coeur (programme de calcul pur exclu)
avatar caissonbulle | 
Très, très intéressant ! J'en profite pour poser une question sans réponse satisfaisante actuellement pour ma part : pourquoi PhotoShop plante-t-il quand je quitte l'application ? Merci de vos lumières et surtout bon week-end à tous...
avatar Zed-K | 
@ caissonbulle : Quelle machine / version d'OSX / version de Photoshop ? Pour ma part aucun plantage avec Photoshop CS5 sur mon Mac Pro 1st Gen sous Snow Leopard.
avatar Stalmicmac | 
C'est juste ridicule... à quoi bon avoir une "bête de course" si des softs comme "toshop" ne sont pas optimisés. Il serait intéressant de pousser l'investigation plus loin et de voir quels sont les softs actuellement vraiment optimisés pour cette débauche de puissance.
avatar Jouflu | 
Les programmes de 3D, genre maya et Cinema 4d tirent partie de l'ensemble des cœurs présents sur ta machine à 100% lors du rendu d'une image...
avatar - B'n - | 
Je trouve qu'on a de plus en plus un rapport disproportionné entre la puissance des machines et leur optimisations. Je me réjouissait du fait que Snow Leopard se penche exclusivement sur l'optimisation, mais c'est un flop, et apparemment les gros softs ne suivent pas non plus. Au final on a des mauvais pilotes, des softs mal optimisés et un OS et ses appli guère plus… :( Heureusement qu'on a de bonnes cartes grahiques ! Ah merde, ça non plus on y a pas le droit… :D
avatar DarkMoineau | 
Je voudrais pas troller mais bon, Photoshop c'est Adaube quoi ^^
avatar ErGo_404 | 
Tous les calculs ne se prêtent pas au multicoeur non plus, et je suis sûr que certains algos ont besoin d'un nombre de coeurs précis. Et puis il me semblait qu'une partie des traitements étaient effectués par la carte graphique, auquel cas le processeur importe vraiment peu. Enfin bref, c'est pas si étonnant. D'un autre coté, acheter 8 coeurs pour faire du toshop, vla l'intérêt.
avatar NicolasO | 
Il serait interessant de comparer suivant les taches. La question est la quantite de //-isme de la tache vs le nombre de proc. Pour du rendu 3D par exemple, on sait beaucoup //iser.
avatar Zed-K | 
Ca fait grand débat en ce moment. La course au Ghz a été mise en pause pour passer à la multiplication des coeurs. Le soucis étant la complexité que cela implique en terme de développement (à ce que j'ai compris, tous les calculs ne se prêtent pas à la parallélisation, et pour ceux où le gain serait intéressant, il serait difficile de parvenir à les utiliser d'une façon optimale). Intel en est conscient et a proposé récemment un SDK pour les développeurs C++ ([url=http://software.intel.com/en-us/articles/intel-cilk-plus/]Cilk[/url]) afin de simplifier l'utilisation des coeurs multiples. Apple propose GCD, qui a fait beaucoup de bruit lors de l'annonce de Snow Leopard (notamment car Apple avait choisi de diffuser librement les sources), et dont on a malheureusement plus trop entendu parler depuis. Toujours est-il que le multi-cœur semble être un véritable casse-tête, et j'imagine que sur un soft aussi énorme que Photoshop, la tâche ne doit vraiment pas être aisée. Libre à chacun de critiquer (vu le prix que coûte Photoshop et un Mac Pro 12 coeurs, l'agacement des clients victimes de ces baisses de performances est tout à fait compréhensible), mais il ne faut pas oublier qu'Adobe a fait un énorme effort en passant la version CS5 à Cocoa (alors qu'Apple ne juge toujours pas utile de faire de même pour iTunes, pourtant loin d'être aussi gros...), ce qui n'a pas été une mince affaire non plus et qui a dû prendre beaucoup de temps et de ressources. Photoshop (et le reste de la suite) CS6 sera peut-être celle du multi-cœur, on verra l'année prochaine ;) Si quelqu'un s'y connaît et peut corriger d'éventuelles erreurs dans mon message, et en profiter pour donner son avis sur la question de manière intelligible pour des néophytes/débutant, ça m'intéresserait beaucoup =)
avatar zeblaze | 
Il serait marrant de voir comment se comporte Photoshop CS5 sur Win7 via Bootcamp sur un Mac Pro 12 coeurs.
avatar Anthony Nelzin-Santos | 
@ Stalmicmac : ce sont des choses que nous regardons de très près en ce moment pour réviser nos procédures de test. Avec l'iMac Core i5, et encore plus avec les Mac Pro, nous nous sommes aperçus que nous avions de véritables problèmes avec des tests comme ceux utilisant Photoshop ou le Finder. A côté de ça, iMovie ou QuickTime X utilisent très bien le multicœur, pas mal de softs de 3D aussi, Handbrake ou XLD de même. Bref, il y a du boulot.
avatar Jerry Khan | 
Pas la peine de vociférer sur PS...je suis certain que: 1 - OS X pour lui-même ne gere pas mieux la puissance multi-core (seul un OS comme Be savait le faire dans les regles de l'art) 2 - qu'aucune application Apple (y compris dans les appli pro) ne sait tirer pleinement profit du multi-core. Bref, rien de nouveau sous le soleil.
avatar kubernan | 
@Zed-K : C'est à dire que GCD est pour les développeurs. Je vois mal un éditeur marquer en gros sur son produit : "utilise GCD !". Lors de la dernière conférence développeur, GCD a fait l'objet de sessions spécifiques. C'est vrai que c'est très simple à mettre en oeuvre. Maintenant de là à savoir qui l'utilise, c'est une autre histoire. Ici on tombe dans un schéma classique de la gestion des threads : au delà d'un certain point le système n'en peut plus et les performances s'effondrent. Ce n'est pas étonnant : c'est très compliqué.
avatar Armas | 
@ caissonbulle : j'ai meme pas envie de comprendre. tu peux toujours consulter les logs système pour voir si c'est un élément OS X ou un élément de la CS elle même qui fait planter l'application, mais le plus simple à mon gout resterai la réinstallation complète de Photoshop ou le reformatage. Même si la CS est un outil fantastique et très performant, concernant l'optimisation, c'est une vrai merde. La Creative Suite, c'est plus de 100 000 éléments installés partout sur le système. je me demande encore à l'heure actuelle ce qu'ils peuvent bien faire dans certains endroits. Parfois, je la compare même à un micro système à l'intérieur du Système. Elle est développé comme tel, en tout cas. Elle possède ses propres plugins, ses propres dossiers indépendants des dossiers standarts ou l'on regroupe les elements propres à certaines applications, ses archives, ses routines, elle ne daigne même pas utiliser le Finder, préférant le rajout d'une couche logiciel bien lourde appelée Bridge comme si les développeurs avaient eu peur de mélanger la CS à OS X au risque que ça la salisse. D'ailleurs, c'est plutôt marrant, mais je trouve qu'il y a un rapprochement entre la politique de développement de Flash et celle de la Creative Suit. Développer un produit accessible sur toutes les plateformes qui s'affranchisse de la plateforme. Certes c'est bien beau, mais au final, on y perd un max en optimisation. Petit détail hors sujet. Je suis passé d'un Macbook première génération core duo 2Hz avec shipset 64 Mo graphique qui ramait assez souvent lors de l'utilisation de Flash à un 27" Quad Core i7 avec CG ATI 4850 HD et certes, mon ordi ne rame plus, mais la Carte Graphique chauffe énormément avec l'affichage d'une simple video 320*480 dans Flash. Meme un jeu comme Mirror's Edge ou The witcher avec les graphisme au max ne la fait pas chauffer autant, même une video HD... On s'est peut être monté le bourrichon avec Flash, mais le problème est fondé.
avatar Hasgarn | 
C'est le casse tête le plus complet pour acheter son ordi, en ce moment… Soit on prend un bi cœur, ou un quad (graaaaaaand max), et on risque de se retrouver à la rue si les éditeurs décident de vraiment se pencher sur le multiprocessing ; soit on se prend une bête de course qui ne sera pas vraiment plus performante, et avec l'incertitude concernant la prise en charge du multiprocessing. Vive le papier, au moins, on sait que nos 2 hémisphères - cerveau fonctionnent bien…
avatar Anonyme (non vérifié) | 
Jerry Khan 1 : tu te bases sur quoi ? tu sais que les microprocesseurs ont bien changé depuis l'époque de BeOS ? 2 : genre Aperture, Logic... ? "Bref, rien de nouveau sous le soleil." je suis bien d'accord avec cette phrase mais sans doute pas pour la même raison.
avatar Armas | 
@ Zed-K : un commentaire pertinent. Je suis un sceptique de la multiplication des coeurs. Non pas que les gains ne soient pas intéressant, mais parce que les développements ont du mal à suivre.
avatar Nicky Larson | 
[quote]2-fre : Maintenant cite une application qui est capable de bien utiliser autant de coeur (programme de calcul pur exclu)[/quote] peut être que les autres non plus ne gèrent pas le multi core, mais au moins, elles ne coutent pas un bras comme photoshop ...
avatar BitNic | 
@caissonbulle Même chose depuis la Màj en 11.0.1 sur mon Mac Pro en 10.6.4. Je n'avais aucun problème avant cette Màj. J'ai fait ma réinstall annuelle de tout mon système. Mais toujours la même chose. Si je quitte Totoshop trop rapidement après un traitement = Plantage. Si j'attends un peu = RAS !!!
avatar Lonesome Boy | 
Pixelmator gère GCD par exemple. Mais bon, c'est sûr qu'il ne boxe pas dans la même catégorie que PS... Pour l'instant. Les "petits" ont adopté GCD bien plus rapidement que les "gros"... Le problème auquel font face les "gros", c'est que d'une part y'a énormément de boulot pour rendre tout leur code GCD friendly et d'autre part, adopter GCD signifie sortir un produit uniquement compatible Snow Leopard (et soit abandonner le support 10.5, soit sortir 2 versions). Tant que LEUR marché ne sera pas majoritairement sous Snow Leopard, ils ne feront rien pour supporter GCD. Sachant que le marché pro est plus lent à adopter les nouvelles versions de système... Bref, arrêtons de "taper" sur Snow Leopard: c'est un version dont les nouveautés ne concernent quasiment que les développeurs, et ses bénéfices ne se verront que petit à petit. Et SL est une fondation solide pour la suite. Par contre, y'a intérêt que les prochaines versions d'iLife, Logic Studio et Final Cut adoptent enfin GCD et/ou OpenCL, même si les éternels râleurs risquent de se plaindre parce-que ce ne sera pas compatible Mac OS 10.5...
avatar hok | 
C'est pas parce que l'hyper threading ajoute des avortons de coeurs qui sont lent en pratique ?
avatar Jerry Khan | 
sunjohn -> je me base sur le fait qu'un OS doit avoir une architecture optimisée des le départ pour le multi-processing (multi proc ou multi-core, peu importe). Ce qui n'est pas le cas d'OS X. Il ne sait pas répartir de maniere optimisée (et native) les différents besoins sur les différents cores (documente toi la dessus, je suis pas ton encyclopédie personnelle). Voila pour l'OS. Apple a mis a disposition une api (GrandCentral) pour les applications (que pour le moment, elle n'a pas utilisée elle meme) qui nécessite une réecriture quasi complete du code (donc on est pas prets de la voir utilisée dans des applicatifs existants). Autre chose ou ca ira ? Bonjour chez toi.
avatar kubernan | 
@Jerry Khan : "[i]Apple a mis a disposition une api (GrandCentral) pour les applications (que pour le moment, elle n'a pas utilisée elle meme) qui nécessite une réecriture quasi complete du code...[/i]" Je serai nettement moins catégorique sur cette réécriture [i]complète[/i] du code. À partir d'une appli. Cocoa par exemple, il est très aisé d'intégrer GCD sans avoir à réécrire entièrement l'appli. Par moment c'est même confondant tellement c simple. À noter que GCD n'est pas dédié aux applications de calculs purs. Il peut être tout simplement utilisé pour éviter de bloquer l'interface utilisateurs (quand par exemple on a besoin d'afficher plusieurs images ; chacune sera traitée dans un thread).
avatar amigafred91 | 
@Gr3gZZ : moi je dirais cinebench, il bench tres bien mes quad core et bi core ^^ Si photoshop aurait ete bien pense, il ne threaderais que sur 2 ou 4 core, il s'auto limiterais. l serait peut etre temps aussi qu'intel et qu'amd se disent, que les 4/8cores, c'est deja trop pour le commun des mortels, qu'ils se remettent a bosser pour l'augmentation des ghz :)
avatar Jerry Khan | 
kubernan -> tellement simple qu'aucune application Apple ne l'utilise (ni petite ni grosse)....
avatar Almux | 
Le multi-proc est bien géré par les applics 3D. Pour les autres, il est surtout question de pouvoir travailler sans gène, à l'instar de la ram, sur plusieurs applics gourmandes en même temps. Mais, n'y a-t-il pas un moyen d'attribuer le nombre de CPUs à l'une ou l'autre des applic? Il suffirait alors de "cocher" 2 ou 4 pour Adobe et le tour serait joué... PS Compressor de la suite FinalCut gère parfaitement le multi-CPUs... MAis il faut le configurer à la main.
avatar jlb_ | 
Je suis effaré par les sottises que peuvent écrire certaines personnes. Soit on sait de quoi on parle, soit on se tait. À lire Jerry Khan ci dessus on en viendrait presque à croire que BeOS faisait de la magie, qu'il découvrait de lui même le parallélisme des applications et distribuait tout ça entre les processeurs. Il ne faut malheureusement pas rêver. BeOS avait une architecture construite autour de threads avec une API classique et la gestion des sections critiques, des synchros et des inévitables deadlocks à la charge du programmeur. [b]Tout ce que Mac OS X a d'ailleurs puisqu'il dérive de Mach3[/b]. Sauf que c'est assez pénible à employer directement et c'est donc là que GCD intervient.
avatar ElMute | 
pour les applications de la serie PRO apple (Logic en l'occurence) en effet le multi processeur est géré ... mais c pas encore au top, et par exemple il est impossible d'utiliser les processeur a 100%. en effet a 50% d'utilisation de chaque coeur logic indique etre deja en surcharge proc. donc le multiproc amene quelque chose dans ces logiciels mais faut encore optimiser la chose pour tirer le meilleur de ces processeurs. et j'espere que ca va arriver prochainement parce que ca commence a faire un moment que les constructeurs de processeurs ont mis tous leurs oeufs dans la multiplication des coeurs .... allez les develloppeurs à vos code :))
avatar caissonbulle | 
@ Zed-K : MacPro 2.66 • 9 Go RAM • 4 DDs • CS5 Fr • Pas de gestionnaire de typos... Ce bug semble très erratique suivant les configurations... @ Armas : bonne idée de faire un tour sur les logs : pas sûr d'être compétent pour décrypter ce genre de listing. J'vais quand même y faire un tour. merci pour l'idée... @ BitNic : Damned !... De mon côté, j'ai l'impression que PS plante en quittant quand il a été longtemps mis en arrière-plan, donc ouvert mais pas utilisé... Quelques posts sur la toile font état d'un éventuel problème de droits des dossiers sensibles du compte et du système, PS n'ayant pas toutes les latitudes pour écrire dans ces fichiers. Un peu casse couilles mais pas rédhibitoire puisque la suite ne plante pas (pour l'instant) pendant un job ! Affaire à suivre...
avatar lennoyl | 
Au moins j'aurais appris un truc: l'existence de ce panneau processor. Pour Photoshop, on peut espérer qu'Adobe corrige le tir pour faire au moins en sorte que les performances ne se détériorent pas quand on a plus de processeurs.
avatar enka | 
@ Almux : je viens de découvrir à ma grande surprise que Compressor 3.5 (FCS 2009) gère nettement mieux le multicore. Sur un octo core, compressor sans quickcluster arrive à plus de 500% (soit plus de 5 cœurs sur 8 d'utilisés). Avant on était nettement moins bien loti... After Effect CS5 (le CS4 étant bridé par la RAM utilisable) gère très bien le multicore à condition d'avoir au moins 2 Go de RAM par cœur.
avatar Anonyme (non vérifié) | 
Jerry Khan : Logic peut utiliser jusqu'à 8 cores http://support.apple.com/kb/HT3161 2007 : http://www.barefeats.com/octopro5.html avec plusieurs applis dont la version précédente de Final Cut, l'auteur arrive à 764% de taux d'occupation processeur avec un mac pro 8 cores. Compressor 3 seul, sans bidouille, arrivait à 526% de taux d'occupation processeur. Aperture utilise coreimage qui utilise OpenCL http://www.apple.com/fr/pro/photo/coreimage.html on est quand même assez loin de la situation que tu décris
avatar kubernan | 
@ Jerry Khan : [i]kubernan -> tellement simple qu'aucune application Apple ne l'utilise (ni petite ni grosse)....[/i] Je répondais a ta phrase où tu disais sans ambiguité que dans tous les cas il fallait réécrire entièrement le code d'une appli pour utiliser GCD ("[i]Apple a mis a disposition une api (GrandCentral) pour les applications (que pour le moment, elle n'a pas utilisée elle meme) qui nécessite une réecriture quasi complete du code"[/i]). Ta phrase est trop généraliste à mon sens. Par exemple, sans même modifier la logique de mon code, j'ai pu sur l'iPhone utiliser GCD (en combinaison avec l'usage des Blocks). J'ai traité ainsi le chargement d'images en multithread en ajoutant [b]deux[/b] lignes de code (i.e. dispatch_async() pour être plus précis). GCD simplifie la gestion des threads (en fait on n'a même plus à gérer explicitement les threads). De plus en combinant les Blocks le code reste propre.
avatar kubernan | 
@ Jerry Khan : Quant à BeOS (je développais sur une BeBox et ensuite sur Mac) il faut en effet reconnaître que la gestion des threads étaient bien foutu (l'équipe Be a d'ailleurs dû réécrire cette partie plusieurs fois à cause de dead locks). En fait, le système entier était bien foutu. Malgré tout, pour un développeur, la gestion des threads restait tout à fait classique (sémaphores etc...) et ne mettait pas à l'abri une appli de sérieuses pertes de performances (me suis arraché les cheveux à l'époque sur un réseau de neurones formels multihreads).
avatar hawker | 
Sur du soft a ce prix (et quand on matte la longueur de la liste des dev qui bossent dessus) c'est quand meme abusé ce genre de truc. moi j'exige (meme si j'ai qu'un quad) que le moteur soit amélioré au sein de la version cs5
avatar Goldevil | 
D'un point de vue technique, la programmation parallèle est très très très compliquée. J'ai un peu d'expérience dedans et selon les cas on passe de "compliqué" à "casse-tête cosmique". Tout d'abord il faut savoir que certains algorithmes sont plus faciles à paralléliser que d'autres. Dans l'exemple de Photoshop, il faudra analyser chaque filtre indépendamment. Ensuite, l'architecture physique influence beaucoup. Comment les threads peuvent communiquer entre-eux ? Quelle est la bande passante de la RAM ? La bande passante du disque dur ? Quelle est la taille du cache de niveau 1 ? GDC va aider les développeurs mais cela reste de la haute voltige. Pour comprendre voici une petit analogie. Vous avez une salle de sport avec du carrelage et chaque dalle a sa propre couleur. Vous avez un ouvrier un peu stupide qui doit repeindre chaque dalle en faisant un mélange basé sur la couleur de la dalle et de ses voisines. Les consignes sont simple à définir. Il faut lui indiquer comment se déplacer et comment savoir quelle peinture choisir. Maintenant imaginez que vous avez 4 ouvriers tout aussi stupides. Vous allez devoir changer vos consignes de manière à être certains qu'ils ne se marchent pas sur les pieds, qu'ils ne se basent pas sur a nouvelle couleur d'une dalle mais juste de l'ancienne, etc. Quelle que soit la taille de la salle de sport il va arriver un moment ou même en rajoutant des ouvriers, cela n'ira pas plus vite car certains vont devoir attendre que d'autres ont terminé leur dalle pour continuer leur partie. De plus, le nombre de pots de peinture est limité et un ouvrier ne peut peindre qu'une seule dalle après avoir trempé son pinceau. Là aussi il y a un goulet d'étranglement. Dans le monde réels les ouvriers sont intelligent et savent optimiser leur travail. En informatique il ne faut oublier qu'un CPU est d'une imbécilité incroyable mais il le compense en calculant des dizaines de milliers de fois plus vite qu'un homme.
avatar Florian Innocente | 
@ goldevil : sors de ce corps Christopher Nolan.
avatar majipoor | 
Comme déjà mentionné, beaucoup de logiciels 3D exploitent à merveille tous les coeurs. Et je suis sûr que bien d'autres logiciels professionnels savent également quoi en faire. Et pour Mr Tout-le-monde qui aurait décidé de s'acheter une machine professionnelle au lieu d'un iMac, n'oublions tout de même pas que même si une application donnée n'exploite pas tous les coeurs, lorsque plusieurs applications tournent en même temps, elles se partagent les coeurs. Alors Photoshop utilise 4 coeurs pendant que l'on encode une vidéo sur 4 autres coeurs, ça en fait 8 pleinement utilisés avec 2 soft. Le compte est bon. Quand à GCD, encore faudrait-il que Photoshop l'utilise, ce qui me semble peu probable connaissant Adobe.
avatar HAL-9000 | 
@ Tous : Le multithread est géré à 100% (100% des cores utilisés en parallèle) sur des softs de cacul scientifique : MATLAB, Simulink et R maintenant. De plus, sous C/C++, etc. ça fait longtemps que l'on peut attribuer telle tache à tel core. Et oui, il existe des logiciels en C/C++ (en Banque/Finance) qui marche sous Excel - C++. En fait, les pros cela fait longtemps qu'on utilise les multicores ainsi que le cloud computing. Après niveau amateur les soft Toshop and Co ont un train de retard...
avatar rva1mac | 
Ce n'est pas seulement la faute à Adobe ! L'HyperThreading est une vraie daube.
avatar IPadFan333 | 
Ou les bêtes ces Mac!!!
avatar chapelle18 | 
C'est marrant parce que cela fiche en l'air le fameux adages qui peux le plus peux le moins, voilà un très bon contre exemple! Ce que je trouve pour la part assez déconcertant c'est qu'autant je peu comprendre une mauvaise optimisation sur un sot gratuit fais par un amateur, autant je trouve cela purement scandaleux d'un logiciel récent photoshop CS5 soit disant professionnel et qui coûte plus de 1000€. A ceux qui demande quel intérêt d'acheter un 12 coeurs pour toshop, je dirai que l'on acheté pas un Mac pro spécialement pour toshop mais peut être comme le disent certain pour des logiciels de traitement video qui eux sont pro et optimisés et que l'on est en droit d'en attendre la même chose de photoshop.
avatar mathiasr | 
Il ne faut pas perdre de vue la loi [url=http://fr.wikipedia.org/wiki/Loi_d%27Amdahl]d'Amdahl[/url] (bien qu'en théorie les traitements réalisés par Photoshop sont largement parallélisables), après c'est bien beau de multiplier les cœurs mais si la bande passante mémoire n'augmente pas beaucoup ça va bouchonner à ce niveau.
avatar chris1973 | 
Et avec LR3, y a-t-il le même phenomène ?
avatar Almux | 
@enka Oui, mais tu as vu que Compressor doit être sollicité manuellement pour activer sa fonction Cluster (même interne!). Ceci est dommage, mais, on peut espérer que la version réécrite de Final Cut Studio en 64bits va automatiser cette répartition en détectant automatiquement les processeurs existants. Blender le fait à merveille, bien qu'il soit gratuit.
avatar Jean-Jacques Cortes | 
Photoshop est un vieux logiciel dont les premières versions ont 20 ans, il n'a donc pas été conçu à l'origine pour des ordinateurs multi-coeurs et multi-processeurs. Là où Adobe n'assure pas, c'est que ses développeurs n'ont jamais remis à plat le code pour le moderniser. cela dit, rajouter des coeurs dans les processeurs et augmenter le nombre de processeurs, est ce la meilleure solution pour augmenter les performances d'un ordinateur ? Ne serait il pas plus judicieux de récrire les systèmes d'exploitation, en abandonnant le langage C et ses dérivés pour un langage moins verbeux et plus efficace ?
avatar Almux | 
@Jean-Jacques Cortes ... Mmh! "Moins verbeux et plus efficace"... Je ne sais pas si tu en connais aussi peu que moi en matière de code, mais, cela fait des années que les langages évoluent vers la "simplicité". Mais ce genre de "simplicité" implique des codes encore plus ésotériques que ceux déjà en fonction... Il pourrait donc bien s'agir d'une "simplicité" qui complique la vie des développeurs! ;)

Pages

CONNEXION UTILISATEUR