Nouveau PC Photo : 4 ou 6 coeurs ?

[kochka]

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.

C'est clair mais est-ce que le gain vient du proc ou des trois cartes Gr?
DXO pousse au nombre de coeurs, davantage qu'à la CG

[Otaku]

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.

Ok comme ça. 

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.

50.000jh, cela compte ?

Si tu as travaillé sur ce genre de projet, tu dois savoir que ce n'est pas la compétence des développeurs qui est importante, mais tout ce qui se passe avant, de l'expression de besoins à la conception générale, voir détaillée. La phase de développement ne fera que répondre à ce qui a été défini avant. Ensuite, tu auras des phases de tests techniques et fonctionnels qui auront pour but de vérifier que ce qui a été développé correspond à ce qui a été demandé. Donc, même si en général dans une équipe tu essayes d'avoir des gens pointus dans leurs domaines, ils ne sont jamais seuls à décider de la manière de faire les choses. Surtout, dans le cas d'un produit comme Adobe, ils ne repartent jamais de zéro pour refaire le produit, sauf en cas de refonte totale du produit, ce qui est assez rare au vu des coûts que cela représente.

D'autre part, si Adobe essayait d'exploiter l'hyper-threading, sans couche logicielle intermédiaire, il est probable qu'ils seraient trop liés au hardware et obligés de faire des modifications trop importantes à chaque changement plus ou moins significatif de technologie de processeur.

[kochka]

On pourrait également plus simplement regarder si tous les cœurs sont utilisés en permanence.
Sur mon vieux 3770K, c'est bien la situation lorsque je lance un lot de conversions JPG maxi, par ex.

[SeSy]

Si tu as travaillé sur ce genre de projet, tu dois savoir que ce n'est pas la compétence des développeurs qui est importante, mais tout ce qui se passe avant, de l'expression de besoins à la conception générale, voir détaillée. La phase de développement ne fera que répondre à ce qui a été défini avant. Ensuite, tu auras des phases de tests techniques et fonctionnels qui auront pour but de vérifier que ce qui a été développé correspond à ce qui a été demandé. Donc, même si en général dans une équipe tu essayes d'avoir des gens pointus dans leurs domaines, ils ne sont jamais seuls à décider de la manière de faire les choses. Surtout, dans le cas d'un produit comme Adobe, ils ne repartent jamais de zéro pour refaire le produit, sauf en cas de refonte totale du produit, ce qui est assez rare au vu des coûts que cela représente.

Ça c'est la théorie. Après, chaque projet est un cas spécifique et chaque gestion d'exigence a sa spécificité. Ce que je veux dire c'est que globalement, je vois une diminution de la technicité algorithmique des développeurs pour une augmentation de la capacité à traiter des sujets "non compris". Je m'explique car je ne dois pas être clair : je trouve que l'on est passé d'un état ou le développeur avait la maîtrise des conséquences de chacune de ses instructions et réfléchissait sur ce point à un état de développement par recopie, par assemblage et par "singeage" où l'objectif est la construction uniquement et la finalité d'arriver enfin à ce que tout arrive à cohabiter tant bien que mal. Je ne blâme personne et je pense que la demande et les technologies amènent à ce fait, fait qui pour le moment est contrebalancé par les progrès du matériel mais qui, je pense, va atteindre ses limites.
(Je ne parle pas ici de projet ultra-spécifique, notamment ce qui est éditeur car le sujet et les contraintes ne sont pas les mêmes.)

D'autre part, si Adobe essayait d'exploiter l'hyper-threading, sans couche logicielle intermédiaire, il est probable qu'ils seraient trop liés au hardware et obligés de faire des modifications trop importantes à chaque changement plus ou moins significatif de technologie de processeur.

C'est extrêmement évident, l'"universalité" a un coût. D'autre part, je ne me suis pas penché sur le sujet mais de manière instinctive un algo matriciel d'imagerie doit utiliser de manière assez directe quasiment toujours les mêmes types ALU et donc l'hyperthreading ne peut apporter du gain que sur les calculs d'instruction ou d'adressage, et en ce sens à vitesse égale le gain peut être plus important grâce à un bon pipeline sur des coeurs réels que sur de l'hyperthreading. Tout dépend du code généré.

[Bob74]

C'est clair mais est-ce que le gain vient du proc ou des trois cartes Gr?
DXO pousse au nombre de cœurs, davantage qu'à la CG

Dans ce cas là, je dirais de l'ensemble des composants (CPU - RAM - CG).
Pour de la photo, le PC doit avoir un bon CPU (de i3 à i7), pas mal de mémoire (de 4 à XX Go) et au minimum une carte graphique basique.
Pour de la vidéo, selon les logiciels utilisés, c'est idem jusqu'à de très grosses machines comme celle de Nicolas Meunier.
En fait, tout dépend ce que l'on fait.

[Otaku]

Ça c'est la théorie.

Non, c'est la pratique. En tout cas dans les projets importants qui réussissent.

Après, chaque projet est un cas spécifique et chaque gestion d'exigence a sa spécificité.

C'est effectivement défini dès le départ.

Ce que je veux dire c'est que globalement, je vois une diminution de la technicité algorithmique des développeurs pour une augmentation de la capacité à traiter des sujets "non compris". Je m'explique car je ne dois pas être clair : je trouve que l'on est passé d'un état ou le développeur avait la maîtrise des conséquences de chacune de ses instructions et réfléchissait sur ce point à un état de développement par recopie, par assemblage et par "singeage" où l'objectif est la construction uniquement et la finalité d'arriver enfin à ce que tout arrive à cohabiter tant bien que mal. Je ne blâme personne et je pense que la demande et les technologies amènent à ce fait, fait qui pour le moment est contrebalancé par les progrès du matériel mais qui, je pense, va atteindre ses limites.
(Je ne parle pas ici de projet ultra-spécifique, notamment ce qui est éditeur car le sujet et les contraintes ne sont pas les mêmes.)

Encore une fois, ça dépend des cadres que tu mets en place, Si tu comptes uniquement sur la capacité des développeurs en espérant qu'ils seront tous au même niveau et feront le meilleur travail, c'est clair que tu vas partir dans les choux.

Quand tu fais du développement sur des gros projets, tu définis des normes de développement et tu mets généralement en place des frameworks, pour éviter d'avoir n'importe quoi au final.

C'est clair que sur des petits développements de quelques centaines de jours homme ou moins, ce sera beaucoup moins rigoureux.

C'est extrêmement évident, l'"universalité" a un coût. D'autre part, je ne me suis pas penché sur le sujet mais de manière instinctive un algo matriciel d'imagerie doit utiliser de manière assez directe quasiment toujours les mêmes types ALU et donc l'hyperthreading ne peut apporter du gain que sur les calculs d'instruction ou d'adressage, et en ce sens à vitesse égale le gain peut être plus important grâce à un bon pipeline sur des coeurs réels que sur de l'hyperthreading. Tout dépend du code généré.

Les langages actuels étant plutôt de haut niveau, ce qui permet justement de s'affranchir  plus facilement des contraintes matérielles et de faciliter la transportabilité du code d'une plateforme à une autre, je ne vois pas trop l'intérêt pour Adobe de se lancer dans le développement d'interfaces spécifiques au matériel. Il y a de fortes chances que le gain en performances soit minime, l'hyperthreading n'étant pas toujours optimal (mise en attente d'instructions par exemple) pour un coût qui lui serait plutôt exponentiel.

Tout ça pour dire qu'avant de miser sur les personnes et la compétence des programmeurs, il vaut mieux miser sur l'organisation du projet et sa gestion, c'est beaucoup moins aléatoire.

[SeSy]

Ite missa est.

[Nicolas Meunier]

C'est clair mais est-ce que le gain vient du proc ou des trois cartes Gr?
DXO pousse au nombre de coeurs, davantage qu'à la CG

Ca dépend de ce que fait avec DXO, si tu utilises le rendu le plus beau et le plus lourd c'est un traitement uniquement en CPU, sinon il est aussi en GPU et autant avoir des CG puissantes.

[kochka]

La réponse de DXO était un peu lapidaire, mais disait que prime n'utilisait pas la CG et que plus il y avait de cœurs et mieux c'était.

D'un autre coté C Métairie montrait qu(entre un CG à 150€ et une à 400, la différence était ultra minime sur DXO.

Je continue à empiler le peu d'infos  disponibles. Le choix ne se fera que lorsque les nouveautés seront dispo et les prix en baisse.

[Nicolas Meunier]

La réponse de DXO était un peu lapidaire, mais disait que prime n'utilisait pas la CG et que plus il y avait de cœurs et mieux c'était.

D'un autre coté C Métairie montrait qu(entre un CG à 150€ et une à 400, la différence était ultra minime sur DXO.

Je continue à empiler le peu d'infos  disponibles. Le choix ne se fera que lorsque les nouveautés seront dispo et les prix en baisse.

on est d'accord avec le rendu Prime et c'est justement la question a se poser : utilises-t-on tout le temps Prime... car Prime met a genoux ma machine pendant de longues secondes, donc au moindre batch il faut faire une pause... et si on doit faire un pause, peut être qu'on peut attendre encore un peu plus et que changer de proc n'est pas necessaire.

Perso (et j'insiste là dessus) je bataille plus sur ce qui améliorera la fluidité du travails, toutes les petites attentes de 1/2 secondes qui deviennent 1/10 par seconde.

[kochka]

Je n'aime pô attendre,
c'est là mon moindre défaut....

[Nicolas Meunier]

Je n'aime pô attendre,
c'est là mon moindre défaut....

Il y a un Youtubeur que j'aime bien : LinusTechTips
Il aime bien essayer la machine ULTIME pour une tâche, sans aucune considération de budget, juste pour véirifer si dans la vraie vie ca change quelque chose.
Par exemple en jeux... en fait ca donne une machine instable et des fois avec des contreperformances flagrantes.
En video il a pas mal bossé pour faire un ensemble Soft + Hard vraiment adéquat
Malheureusement il ne fait pas de photos.

[kochka]

Je ne joue jamais. Ce qui élimine d'office les supers configs de gamer, et la vidéo sera toujours marginale pour mon usage.
Ma question de base est plutôt simple, n'étant ni raciste, ni sectaire  : vaudra-t-il mieux, pour DXO,  employer disons 500 pistoles de plus dans 2 cœurs de plus, ou dans une CG plus haut de gamme?
Sachant que si c'est pour gagner 8% de temps, je me demande si cela vaut le coup?

[Nicolas Meunier]

Je ne joue jamais. Ce qui élimine d'office les supers configs de gamer, et la vidéo sera toujours marginale pour mon usage.
Ma question de base est plutôt simple, n'étant ni raciste, ni sectaire  : vaudra-t-il mieux, pour DXO,  employer disons 500 pistoles de plus dans 2 cœurs de plus, ou dans une CG plus haut de gamme?
Sachant que si c'est pour gagner 8% de temps, je me demande si cela vaut le coup?

En gros... si tu le met sur le processeur, ca ne changera que sur le rendu Prime, si tu mets une CG plus puissante ca se sentira partout ailleurs

[RolandH]

Je ne joue jamais. Ce qui élimine d'office les supers configs de gamer, et la vidéo sera toujours marginale pour mon usage.
Ma question de base est plutôt simple, n'étant ni raciste, ni sectaire  : vaudra-t-il mieux, pour DXO,  employer disons 500 pistoles de plus dans 2 cœurs de plus, ou dans une CG plus haut de gamme?
Sachant que si c'est pour gagner 8% de temps, je me demande si cela vaut le coup?

Bonsoir,

pour vous donner quelques éléments, avec un i7-5930K (6 coeurs), 32 GO de RAM, GPU Nvidia Quadro K2200, SSD  ...

Traitement avec DOP11 de 100 images, sortie TIF 16 bits, 12 photos traitées en simultané :
   - Accélération GPU/OpenCL activé:
        . 100 RAW de 5D MK3 : 5 mn 4 s -> 3 s/image
        . 100 RAW de 7D MK2 : 4 mn 21 s -> 2.6 s/image
   - Accélération GPU/OpenCL désactivé:
        . 100 RAW de 5D MK3 : 7 mn 40 s -> 4.6 s/image
        . 100 RAW de 7D MK2 : 7 mn 3 s -> 4.2 s/image

Extrait des logs de DXO:

      DxOOpticsPro version: 11.4.0.11979                   
      Platform: Win                                       
      OS name: Windows 10 Professional (10.0.14393)       
      OS architecture: 64-bit                             
      OS language: fr-FR                                   
      OS swap size: 32768 MB                               
      OS total virtual memory size (ram+swap): 65448 MB   
      OS supported physical memory: 32680 MB               
      MEMORY size: 32680 MB                               
      CPU model: Intel(R) Core(TM) i7-5930K CPU  [at]  3.50GHz 
      CPU frequency: 3.418945 GHz                         
      CPU count: 6                                         
      GPU count: 1                                         
      GPU model: NVIDIA Quadro K2200                       
      GPU memory: 4095 MB
     
      OpenCLDeviceCache Dump :
          cpu perf : 3308.21
          NVIDIACUDA-QuadroK2200-378.49 - PerfIndex = 5697.7 Status = OpenCL device is faster than the main CPU

[kochka]

Très intéressant sur l'utilité d'une CG.
EN 2015, C Metairie avait comparé deux types de cartes Graphiques, et montrait qu'une carte rapide Quadro K2200 apportait peu par rapport à une carte plus basique Quadro K620.
Serait-ce trop beau pour être vrai?

[baséli]

Très intéressant sur l'utilité d'une CG.
EN 2015, C Metairie avait comparé deux types de cartes Graphiques, et montrait qu'une carte rapide Quadro K2200 apportait peu par rapport à une carte plus basique Quadro K620.
Serait-ce trop beau pour être vrai?

M'en fous j'ai LR 5.7 

Le jour où j'ai besoin d'en changer, je vais regarder attentivement C1 dis donc. Mieux que LR sur Fuji à ce qu'on en dit, et plus rapide?

[Nicolas Meunier]

M'en fous j'ai LR 5.7 

Le jour où j'ai besoin d'en changer, je vais regarder attentivement C1 dis donc. Mieux que LR sur Fuji à ce qu'on en dit, et plus rapide?

En fait on disait ca il y a longtemps, depuis il y a eu beaucoup de boulot sur LR.

Perso je bosse sous LR tout en testant DXO et C1 une fois par an et pour l'instant pas eu envie de changer (et j'ai un Fuji en plus de mes Nikon)

[Nicolas Meunier]

Très intéressant sur l'utilité d'une CG.
EN 2015, C Metairie avait comparé deux types de cartes Graphiques, et montrait qu'une carte rapide Quadro K2200 apportait peu par rapport à une carte plus basique Quadro K620.
Serait-ce trop beau pour être vrai?

Une erreur est aussi de prendre des cartes pro Quadro, ajd la frontière entre carte de gamer et carte quadro n'existe plus comme avant, la seule vraie différence est la stabilité mais pour un surcout enorme. Ainsi une carte de gamer ENTERRE une carte Quadro en terme de performance surtout en OpenCL et Cuda.

[RolandH]

Une erreur est aussi de prendre des cartes pro Quadro, ajd la frontière entre carte de gamer et carte quadro n'existe plus comme avant, la seule vraie différence est la stabilité mais pour un surcout enorme. Ainsi une carte de gamer ENTERRE une carte Quadro en terme de performance surtout en OpenCL et Cuda.

Bonjour,

je suis bien de cet avis, avec une Quadro, le rapport prix/perfs n'est pas optimal; une GeForce, 4 fois moins chère, donne d'aussi bon résultats.
Et je ne conseillerai pas un CPU 6/8 coeurs pour la photo.

[baséli]

Je ne joue jamais. Ce qui élimine d'office les supers configs de gamer, et la vidéo sera toujours marginale pour mon usage.
Ma question de base est plutôt simple, n'étant ni raciste, ni sectaire  : vaudra-t-il mieux, pour DXO,  employer disons 500 pistoles de plus dans 2 cœurs de plus, ou dans une CG plus haut de gamme?
Sachant que si c'est pour gagner 8% de temps, je me demande si cela vaut le coup?

Quand je te disais que c'était compliqué et qu'il fallait voir directement sur la machine. Regarde ça: http://www.macg.co/mac/2017/03/un-mac-mini-peut-compiler-plus-vite-quun-mac-pro-97787

Marrant non?

EDIT: la phrase intéressante est: " le processus n'est pas accéléré en multipliant les cœurs, il est ralenti. " Mais pas sur toutes les machines...

[Nicolas Meunier]

Quand je te disais que c'était compliqué et qu'il fallait voir directement sur la machine. Regarde ça: http://www.macg.co/mac/2017/03/un-mac-mini-peut-compiler-plus-vite-quun-mac-pro-97787

Marrant non?

EDIT: la phrase intéressante est: " le processus n'est pas accéléré en multipliant les cœurs, il est ralenti. " Mais pas sur toutes les machines...

De la même manière le MAC le plus rapide pour LR était il y a 2 ans, le Macbookpro devant l'iMac et tous les MacPro trashcan

[kochka]

Donc plutôt partir sur un 6 cœurs et une CG costaud  compatible 4K,   dans les 5/800 pions?
Mais laquelle?

[Nicolas Meunier]

Donc plutôt partir sur un 6 cœurs et une CG costaud  compatible 4K,   dans les 5/800 pions?
Mais laquelle?

la carte la plus puissante sera sous exploité je pense mais par exemple une 1070 peut etre un très bon compromis

[Otaku]

4K or not 4K ? That is the question.