Nouveau PC Photo : 4 ou 6 coeurs ?

[Pixel-Z]

Bonjour Pixel-Z. Je parle de la vidéo que j'avais postée concernant le test de performance avec OpenCL d'activé ou non avec Photoshop CC, pas de benchmark de montage vidéo... Dans ce Benchmark, le gars dispose d'un CPU Intel Core i7-3770K.
https://youtu.be/86x7llTIWXc

Et puis avec un GPU Nvidia, il faut aussi être certains que tout soit bien configuré, pour être certains que le GPU soit utilisé.
Un tutoriel visible ici, pour valider et configurer tout cela :
https://youtu.be/OP9_AL8lcWw

Bonne journée.
Xavier

les tests Puget si tu regardes bien montrent que c'est avec smart-sharpen qu'il y a du gain GPU (donc à avoir une carte graphique  plus performante)  ,donc rien d'étonnant dans la vidéo que tu proposes



Pour Camera Raw, quasi aucune différence entre une carte basique et trés haut de gamme :

[xcomm]

les tests Puget si tu regardes bien montrent que c'est avec smart-sharpen qu'il y a du gain GPU (donc à avoir une carte graphique  plus performante)  ,donc rien d'étonnant dans la vidéo que tu proposes

Intéressant, mais SANS GPU, nous avons sur smart-sharpen :

Smart Sharpen    Ryzen 7 1700X : 4.4
Ryzen 7 1800X : 4.2 (valeur estimée)
Intel Core i7 7700K : 4.3
Intel Core i7 6850K : 4.6
Intel Core i7 6900K : 4.7

C'est claire que SANS GPU dans le tableau que j'ai recopié, on est à des années de lumières avec une carte GTX 1080 8Go. 4.3 ou 4.4 s avec un i7-7700k ou un Ryzen 1700X, et 4,1s avec le GPU 1080. Ça change tout alors. 

[kochka]

Tu héberges Paul Getty images ? 

Rien que les 6 dernières années de photos et de vidéos = 2x4T, x2 pour les sauvegardes.
Nef + JPG maxi, + réduction pour Ipad ou télé, cela commence à faire du volume.
Avant le numérique les volumes étaient moindre, mais j'ai commencé il y a 48 ans.
Les voyages déforment les valises et remplissent les DD.  Heureusement cela prends moins de place que les diapos. J'en ai un plein coffre (125x56x56).

[Otaku]

bof en définitive....: https://www.pugetsystems.com/labs/articles/Adobe-Photoshop-CC-2017-AMD-Ryzen-7-1700X-1800X-Performance-907/

"To make it short: Ryzen isn't all that great for Photoshop."

Je me suis amusé à traiter les données sous Excel, voilà ce que ça donne. La différence est uniquement sur "Adaptive Wide Angle". Je ne serais pas étonné qu'il y ait un biais dans la mesure.

[Otaku]

Performance comparée des processeurs Intel avec Photoshop CC 2017

[Otaku]

Sur les cartes graphiques :

From a budget standpoint, the NVIDIA Geforce GTX 650 1GB and AMD Radeon HD 7750 both did great for their price points, performing just a few seconds slower than the fastest cards we tested. If you have a bit more to spend, but cannot afford a NVIDIA GTX 680 2GB (which was the top performer), we recommend the NVIDIA Geforce GTX 660 2GB as it's performance was almost identical to the NVIDIA Geforce GTX 660 Ti and GTX 670, yet is much cheaper.

Une carte à moins de 100 euros

[Nicolas Meunier]

Sur les cartes graphiques :

From a budget standpoint, the NVIDIA Geforce GTX 650 1GB and AMD Radeon HD 7750 both did great for their price points, performing just a few seconds slower than the fastest cards we tested. If you have a bit more to spend, but cannot afford a NVIDIA GTX 680 2GB (which was the top performer), we recommend the NVIDIA Geforce GTX 660 2GB as it's performance was almost identical to the NVIDIA Geforce GTX 660 Ti and GTX 670, yet is much cheaper.

Une carte à moins de 100 euros

il date de combien de siécles ce test??? car là tu parles de cartes graphiques plus en ventes depuis 4 ou 5 ans minimum

[Otaku]

il date de combien de siécles ce test??? car là tu parles de cartes graphiques plus en ventes depuis 4 ou 5 ans minimum

C'était avec CS6, mais avec CC 2017, la conclusion est  :

If possible, however, we would still advise using at minimum a GTX 1060 6GB or possibly the GTX 1050 Ti 4GB. Even if you don't feel that you need the extra performance from one of these cards, the 4-6GB of VRAM can be very useful for your system as a whole. Photoshop itself won't need it unless you work with very large images - like the 360MP image we used in our testing - but it does allow you to comfortably use multiple monitors or a 4K monitor without any problems. If you want to use multiple 4K monitors, you might stick with the GTX 1070 8GB or above to ensure you have enough VRAM and raw power to drive those displays.

[xcomm]

[...]La différence est uniquement sur "Adaptive Wide Angle". Je ne serais pas étonné qu'il y ait un biais dans la mesure.

Merci. Je me suis posé la même question.

[Bob74]

Il reste à attendre le nouvelle génération de 6-8 cores qui suivra le 7700.

Oui, mais à quel tarif ?

Si les CPU Intel sur socket 1151 sont "abordables", tout comme les cartes mères, ceux sur socket 2011-3 sont beaucoup plus onéreux, tout comme les cartes mères et la mémoire sur 4 emplacements...
...sans parler des nouveaux sockets (un peu plus de 3000 et quelques pins) pour les i7 HdG (Pro) qui seront inaccessibles.

Si RyZen n'est pas au top, les CPU devraient s'améliorer au fur et à mesure, ne serait ce que par des mises à jour de Bios, de pilotes, et d'optimisation des logiciels.

Si Intel active pour cette année la sortie de nouveaux produits, sans modifier la finesse de gravure (14nm au lieu de 10 nm prévue), c'est qu'il prend bien au sérieux son concurrent.

[kochka]

Le tarif se mesure à l'aune de ce qu'il apporte en gain de temps.
S'il faut doubler le prix pour gagner 10%, je passe mon tour.
Si c'est 50%, la question mérite d'être posée.
Mon soucis est de pouvoir disposer d'un élément de mesure fiable.
DXo consulté répond, plus il y a de cœurs , mieux c'est.
Ok, mézencore?
En même temps une machine qui ne sera pas dépassé avant 4 ans, mérite un effort.
Mais jusqu'ou, cet effort?
Un de mes ami, prof en prépa, avait pris un huit cœurs hors de prix, il y a cinq ans. Mais il faisait les calcul de son doctorat d'état dessus, et le PC tournait des journées et des nuits entières pour modéliser des histoires de vagues scélérates. Dans son cas, aucun doute sur l'utilité et le temps gagné.

[baséli]

Le tarif se mesure à l'aune de ce qu'il apporte en gain de temps.
S'il faut doubler le prix pour gagner 10%, je passe mon tour.
Si c'est 50%, la question mérite d'être posée.
Mon soucis est de pouvoir disposer d'un élément de mesure fiable.
DXo consulté répond, plus il y a de cœurs , mieux c'est.
Ok, mézencore?

Ca dépend.

Satisfait?

Blague à part la réponse est difficile, on peut dans le meilleur des cas te sortir un calcul de complexité (au sens informatique) mais la vraie réponse pratique est dans un bench, qui ne sera valable que pour la machine en question.

[SeSy]

Ca dépend.

Satisfait?

Blague à part la réponse est difficile, on peut dans le meilleur des cas te sortir un calcul de complexité (au sens informatique) mais la vraie réponse pratique est dans un bench, qui ne sera valable que pour la machine en question.

+1 et pour le bench utilisé.
Par contre avec les multicoeurs virtualisés et la structure des pipelines, ceci associé aux différentes couches logiciels, je mets quiconque au défit d'établir une quelconque équation pertinente (hors la classe de complexité théorique de l'algorithme qui ne donne en rien au résultat quant à l'architecture).

Un test de perf teste uniquement lui-même sur la machine exacte sur lequel il est fait.
Tu remplis le disque, la réponse n'est pas la même, tu modifies la complexité de ton image, la réponse n'est pas la même... Cela donne une vision globale et une tendance, pas plus.

[Otaku]

.
Par contre avec les multicoeurs virtualisés et la structure des pipelines,

Késako ?

Tu parles des architectures cpu permettant de faire de la virtualisation au niveau hyperviseur ou d'une virtualisation des cœurs au niveau du proc ?

[kochka]

Ca dépend.

Satisfait?

Blague à part la réponse est difficile, on peut dans le meilleur des cas te sortir un calcul de complexité (au sens informatique) mais la vraie réponse pratique est dans un bench, qui ne sera valable que pour la machine en question.

C'est bien çà le problème
l ne s'agit pas de cal cul, mais de test sur une image type avec un traitement type, uniquement en changenat le proc.
Bien entendu, le résultat sera différent avec LR ou DXO.
Ci devrait se pencher sur la question et nous sortir quelques résultats.

[Samoreen]

Quel interêt à repartir sur 6 coeurs

http://www.chassimages.com/forum/index.php/topic,263000.msg6200124.html#msg6200124

...et la suite.

[Nicolas Meunier]

Avant tout il faut être capable d'exprimer son besoin, car un gain de temps en % sans préciser le type de tâche est inutile.

Prenons un exemple dans LR :
Rapidité d'exportation d'un batch de 100%... tous les coeurs sont utilisés donc ca prend bien en charge l'utilisation d'un coeur... mais i on exporte que une photo à la fois, un processeur avec peu de coeur aura en général une fréquence plus grande et le traitement sera plus court...

Réactivité lors des retouches, là c'est plus les accès mémoire, disques, etc... qui vont jouer et la carte graphique... et on se rend compte que c'est très difficile d'avoir un gain important dans ce département.

Sous photoshop, est-ce u'on veut accélérer l'execution d'un filtre en particulier, lequel? (certains sont optimisés GPU, d'autres CPU, certains son monotache, d'autre multi...)

...etc...etc...

Ainsi à chaque tâche, chaque action, chaque logiciel, la réponse sur ce qu'estla machine ultime est différent.

Il faut donc une bonne machine équilibré correspondant a son budget.

Le plus gros compromis a faire est nombre de coeurs vs fréquence. Un Core i7 pas Extreme mais en version K et bien refroidit permettra un très bon rapport qualité prix dans la plupart des tâches... par contre celui qui génère des batchs enormes souvent... ira plutôt vers un Core i7E 8 coeurs avec du Watercooling et overclocking pour garder des fréquences importantes.

MAIS MAIS MAIS

...c'est fini le temps où on changeait de génération de processeur et que les temps de traitements des photos étaient divisés par 2, 3 voir 4...
...depuis 5 ans ca bouge très peu.

Je suis passé d'un Core i7 3770k, une carte graphique moyenne gamme 16Go de ram à un Core i7E 5830k watercoolé, 32Go Ram, 3 carte graphique haut de gamme... avec un gain peut être de 50%, parfois 100% mais pour un surcout vraiment important.

Enfin un logiciel comme LR est fait pour qu'on puisse continuer a faire tourner ton ordi pendant un batch... donc il n'utilise jamais 100% des ressources.
A l'inverse dans les softs de 3D pro... on peut observer des gains ENORMES d'une config à l'autre et on peut voir un gain pour chaque Euros et quand on lance un rendu.. la machine puise tellement de ressources qu'il est impossible de regarder un film et on sent bien la température de la péice qui monte. Ce type de soft manque un peu en photo... j'aimerais un mode comme ca sour LR.

[SeSy]

Késako ?

Tu parles des architectures cpu permettant de faire de la virtualisation au niveau hyperviseur ou d'une virtualisation des cœurs au niveau du proc ?

Je parle de l'HyperThreading qui créé des "coeurs virtuels" permettant la parallélisation de l'utilisation des ALU... dans certains cas.

[Samoreen]

http://www.chassimages.com/forum/index.php/topic,263000.msg6200124.html#msg6200124

...et la suite.

J'insiste et je vais jouer les Cassandre... L'amélioration du hardware et de ses performances est une bonne chose, encore faut-il être en mesure de l'exploiter. On peut considérer que les développeurs de l'OS ont un niveau de qualification tel qu'ils ont cette possibilité. Par contre, et je parle d'expérience, le niveau des développeurs d'applications n'a pas évolué dans le bon sens ces dernières années, pour de multiples raisons.

Quand on voit les difficultés et le temps nécessaire à corriger des bugs dont la solution apparaît comme évidente à un développeur moyennement doué, on peut s'interroger sur la capacité des équipes de développement qui sont à l'œuvre dans la production des logiciels grand public à maîtriser en particulier les mécanismes de synchronisation qui doivent être mis en œuvre afin de permettre un multi threading qui soit non seulement efficace mais qui ne dégrade pas les performances de l'application.

J'ai eu récemment des échanges avec un développeur de l'équipe Photoshop qui a démontré en quelques lignes qu'il n'avait absolument pas compris ce qu'était un mutex ou un sémaphore. Comment voulez-vous dans ces conditions qu'il sache mettre en œuvre des mécanismes de synchronisation de threads efficaces ? C'est d'ailleurs pour ça que beaucoup renoncent à s'aventurer sur ce terrain.

L'amélioration du hardware par augmentation du nombre de threads qu'il est possible de lancer simultanément peut donc bénéficier aux performances de l'OS. Quant aux applications, je suis extrêmement dubitatif.

[jdm]

  Dans les tests de rapidité de LR la dernière version est plus rapide dans le traitement des images, ce qui laisse quand même une vision positive du développement 

Ceci-dit ils s'étaient endormi depuis pas mal de versions...

https://photographylife.com/lightroom-2-3-4-5-6-and-cc-performance-comparison/

[SeSy]

J'insiste et je vais jouer les Cassandre... L'amélioration du hardware et de ses performances est une bonne chose, encore faut-il être en mesure de l'exploiter. On peut considérer que les développeurs de l'OS ont un niveau de qualification tel qu'ils ont cette possibilité. Par contre, et je parle d'expérience, le niveau des développeurs d'applications n'a pas évolué dans le bon sens ces dernières années, pour de multiples raisons.

Quand on voit les difficultés et le temps nécessaire à corriger des bugs dont la solution apparaît comme évidente à un développeur moyennement doué, on peut s'interroger sur la capacité des équipes de développement qui sont à l'œuvre dans la production des logiciels grand public à maîtriser en particulier les mécanismes de synchronisation qui doivent être mis en œuvre afin de permettre un multi threading qui soit non seulement efficace mais qui ne dégrade pas les performances de l'application.

J'ai eu récemment des échanges avec un développeur de l'équipe Photoshop qui a démontré en quelques lignes qu'il n'avait absolument pas compris ce qu'était un mutex ou un sémaphore. Comment voulez-vous dans ces conditions qu'il sache mettre en œuvre des mécanismes de synchronisation de threads efficaces ? C'est d'ailleurs pour ça que beaucoup renoncent à s'aventurer sur ce terrain.

L'amélioration du hardware par augmentation du nombre de threads qu'il est possible de lancer simultanément peut donc bénéficier aux performances de l'OS. Quant aux applications, je suis extrêmement dubitatif.

En accord avec ce point, le développement devient l'agglomération de couches et de surcouches et la compréhension (et par conséquent l'optimisation) n'est plus un problème fondamental du développement. Les développeurs ont déjà beaucoup à faire pour combler leurs manques théoriques et pour arriver à avoir une image mentale compréhensible de ce qu'il font avec cet empilage, qu'il en devient même difficile de les blâmer.
Nous sommes passé dans l'ère du shoot & go, quel intérêt d'optimiser le matériel et le système sont là pour cela.

Si l'on revient à l'algorithmie du "parallélisme", c'est même pire que ce que tu présentes car l'hyperthreading et le threading au niveau système n'ont "quasiment" pas de lien en eux. D'un côté on autorise le CPU à utiliser en parallèle ses ALU en fonction du pipeline d'arrivée des instructions. De l'autre on joue au niveau global sur la gestion du temps d'attente des "interruptions" pour saucissonner les traitements et gagner sur les temps d'attente. L'exécution au final en devient non prédictive, ce qui pose un vrai problème sur les systèmes "temps réél" au sens strict du terme.

[Nicolas Meunier]

J'insiste et je vais jouer les Cassandre... L'amélioration du hardware et de ses performances est une bonne chose, encore faut-il être en mesure de l'exploiter. On peut considérer que les développeurs de l'OS ont un niveau de qualification tel qu'ils ont cette possibilité. Par contre, et je parle d'expérience, le niveau des développeurs d'applications n'a pas évolué dans le bon sens ces dernières années, pour de multiples raisons.

Quand on voit les difficultés et le temps nécessaire à corriger des bugs dont la solution apparaît comme évidente à un développeur moyennement doué, on peut s'interroger sur la capacité des équipes de développement qui sont à l'œuvre dans la production des logiciels grand public à maîtriser en particulier les mécanismes de synchronisation qui doivent être mis en œuvre afin de permettre un multi threading qui soit non seulement efficace mais qui ne dégrade pas les performances de l'application.

J'ai eu récemment des échanges avec un développeur de l'équipe Photoshop qui a démontré en quelques lignes qu'il n'avait absolument pas compris ce qu'était un mutex ou un sémaphore. Comment voulez-vous dans ces conditions qu'il sache mettre en œuvre des mécanismes de synchronisation de threads efficaces ? C'est d'ailleurs pour ça que beaucoup renoncent à s'aventurer sur ce terrain.

L'amélioration du hardware par augmentation du nombre de threads qu'il est possible de lancer simultanément peut donc bénéficier aux performances de l'OS. Quant aux applications, je suis extrêmement dubitatif.

je suis tout à fait d'accord avec toi concernant l'equipe Adobe... heureusement ils y en a bien d'autres

Je vis un peu ce probléme dans l'automobile... car le temps réel embarqué voulait tout maitriser et donc était monotâche... mais tous les processeurs maintenant son multicoeur. On se rend compte que le plus dur est d'éduquer les developpeurs, casser leurs habitudes et leur shéma de penser pour refaire de nouvelles applications.

[Otaku]

Je parle de l'HyperThreading qui créé des "coeurs virtuels" permettant la parallélisation de l'utilisation des ALU... dans certains cas.

Hum, je ne dirais pas que c'est une virtualisation de cœurs, mais plutôt une technologie qui permet de paralléliser 2 flux de traitements dans un cœur.

Pour moi, ça n'a rien à voir avec la virtualisation telle qu'on l'entend généralement. 

[Otaku]

J'insiste et je vais jouer les Cassandre... L'amélioration du hardware et de ses performances est une bonne chose, encore faut-il être en mesure de l'exploiter. On peut considérer que les développeurs de l'OS ont un niveau de qualification tel qu'ils ont cette possibilité. Par contre, et je parle d'expérience, le niveau des développeurs d'applications n'a pas évolué dans le bon sens ces dernières années, pour de multiples raisons.

Quand on voit les difficultés et le temps nécessaire à corriger des bugs dont la solution apparaît comme évidente à un développeur moyennement doué, on peut s'interroger sur la capacité des équipes de développement qui sont à l'œuvre dans la production des logiciels grand public à maîtriser en particulier les mécanismes de synchronisation qui doivent être mis en œuvre afin de permettre un multi threading qui soit non seulement efficace mais qui ne dégrade pas les performances de l'application.

J'ai eu récemment des échanges avec un développeur de l'équipe Photoshop qui a démontré en quelques lignes qu'il n'avait absolument pas compris ce qu'était un mutex ou un sémaphore. Comment voulez-vous dans ces conditions qu'il sache mettre en œuvre des mécanismes de synchronisation de threads efficaces ? C'est d'ailleurs pour ça que beaucoup renoncent à s'aventurer sur ce terrain.

L'amélioration du hardware par augmentation du nombre de threads qu'il est possible de lancer simultanément peut donc bénéficier aux performances de l'OS. Quant aux applications, je suis extrêmement dubitatif.

En accord avec ce point, le développement devient l'agglomération de couches et de surcouches et la compréhension (et par conséquent l'optimisation) n'est plus un problème fondamental du développement. Les développeurs ont déjà beaucoup à faire pour combler leurs manques théoriques et pour arriver à avoir une image mentale compréhensible de ce qu'il font avec cet empilage, qu'il en devient même difficile de les blâmer.
Nous sommes passé dans l'ère du shoot & go, quel intérêt d'optimiser le matériel et le système sont là pour cela.

C'est globalement beaucoup plus compliqué que cela et cela ne dépend pas de la compétence directe des développeurs. Ceux qui ont déjà géré des projets informatiques importants peuvent avoir une idée de la complexité d'un tel sujet. L'équation dépend avant tout de la rentabilité du projet et des délais. S'il faut tout refaire de A à Z pour gagner quelques pouièmes dans les traitements, il est clair qu'Adobe ne va pas se lancer là-dedans en sachant que le bénéfice monétaire supplémentaire sera négligeable par rapport au coût. La loi de Moore étant toujours vraie, ils ont plutôt intérêt à miser là-dessus.

[SeSy]

Hum, je ne dirais pas que c'est une virtualisation de cœurs, mais plutôt une technologie qui permet de paralléliser 2 flux de traitements dans un cœur.

Pour moi, ça n'a rien à voir avec la virtualisation telle qu'on l'entend généralement. 

Oui, entièrement en accord de l'abus de langage, sauf que :
- pour le commun des personnes, l'hyperthreading est bien présenté comme un cœur physique et un cœur "virtuel" ou "logique"
- pour ces mêmes personnes la virtualisation, les racks, lames ou autres points liés ne sont pas parlant.

C'est globalement beaucoup plus compliqué que cela et cela ne dépend pas de la compétence directe des développeurs.

Pas seulement de... et encore... quand on voit des constantes de boucles créant plus de 90% temps CPU de traitement parce que l'on ne s'est même pas posé la question lorsque l'on a écrit la boucle, c'est un problème de compétence, pas de coût.

Ceux qui ont déjà géré des projets informatiques importants peuvent avoir une idée de la complexité d'un tel sujet.

50.000jh, cela compte ?