LR et ordi qui rame

[soctrang]

bonjour

j'ai une tour Dell qui date de 3 ans  dans les  premiers prix avec les composants qui vont avec donc   et ...ca rame  de plus en plus avec Lightroom 5

donc je compte booster ca et j'ai regarde ici et la  . je precis eque j'y connais pas grand chose

je compte donc garder la tour , la carcasse  , conserver le disque dur de 400 go environ pour le stockage ainsi que la carte graphique car il me semble avoir lu que ca n'avais guere d'importance pour la rapidite

MAIS y adjoindre

un processeur    i5

memoire ram 4 go  (voire plus ?)

disque dur ssd 120 pour y mettre windows et  LR . stockage sur l'ancien disque dur


carte mere asus p8 h61   

voila en gros

et dois je passer en windows 64 ? je parle pour gagner en rapidite

je me demande pas non plus un avion mais un truc qui permette de ''travailler''' relativement  relax

je vous remercie d'avance

[THG]

Oui, il faut un système 64 bits, pour gérer plus de 4 Go dr RAM (en prévoir au moins .

Il serait bon également de changer le DD de stockage car 400 Go c'est très peu, et il faudrait aussi qu'il soit rapide.

[kerbouta]

déjà faire un bon nettoyage machine, vider les caches etc...

[Labuzan]

En 64 Bits, met 8 Go de Ram tout de suite.

[THG]

Oui, il faut un système 64 bits, pour gérer plus de 4 Go dr RAM (en prévoir au moins .

Il serait bon également de changer le DD de stockage car 400 Go c'est très peu, et il faudrait aussi qu'il soit rapide.

Je voulais dire prévoir 8 Go de RAM.

Saisir un 8 suivi d'une parenthèse devient un émoticône.

[dede38120]

J'ai la config carte mère asus avec i5 3.3GHz ram 8 Go Win 7 64bit. 
Je trouve les perfs sur Lr assez moyennes, je conseillerais de faire un effort budgétaire et de passer sur i7.

[Labuzan]

J'ai la config carte mère asus avec i5 3.3GHz ram 8 Go Win 7 64bit. 
Je trouve les perfs sur Lr assez moyennes, je conseillerais de faire un effort budgétaire et de passer sur i7.

+1 et Moyen/haut de gamme si possible, type 4790K ou 5820K car les logiciels sont de plus en plus performants et gourmands.
Ca t'éviteras de rechanger dans 3 ans

[Gérard B.]

Au passage de changement de DD, prendre un SSD de 500go. Les accès sont très rapide et un i5 peux suffire. Attention, le SSD sera pour Windows et les programmes, pas pour le stockage permanent des photos. Pour cela 2 DD externes en copie miroir pour les sauvegardes.

[fred134]

Au passage de changement de DD, prendre un SSD de 500go.

Pourquoi 500 ? Pour Windows, les programmes et le catalogue, 120 GB suffisent très largement, non ?

[Gérard B.]

Sur un PC j'en ai un de 256 et sur un autre de 512. Celui de 256 est vite plein. J'ai un catalogue de + 150 000 photos et Lr avec celui-ci plus un Backup pèse plus de 60go.
Il est pratique de passer par le SSD pour le traitement des photos avant de les placer sur un disque externe de sauvegarde.
Le prix des SSD a fortement baissé. Les 500go sont à moins de 200€ sur A...Z ..N

[soctrang]

Pourquoi 500 ? Pour Windows, les programmes et le catalogue, 120 GB suffisent très largement, non ?

oui c'est ce que je pense aussi vu en plus que je suis vraiment un amateur

sinon merci a tous pour vos reponses et suggestions !!!

apres a moi de voir bien sur ....suivant mon budget bien sur 

[Nikojorj]

En 64 Bits, met 8 Go de Ram tout de suite.

Oui, ça c'est facile à faire tout de suite et ça sera déjà assez efficace.

+1 et Moyen/haut de gamme si possible, type 4790K ou 5820K car les logiciels sont de plus en plus performants et gourmands.

Pour Lightroom, ça n'est pas forcément le mieux : LR a du mal a paralléliser, et et un CPU avec moins de coeurs plus rapides (ie i5 rapide) sera sans doute plus efficace pour moins cher.
En l'état, le i5 de bureau existant n'est pas vraiment un frein pour LR je pense.

[Labuzan]

En l'état, le i5 de bureau existant n'est pas vraiment un frein pour LR je pense.

Oui, mais qui sait de quoi demain sera fait : PS, DXO, vidéo ... ?
il est toujours très difficile de revenir sur le hard d'une config installé.

J'ai une config HP i7 860 qui va avoir 5 ans, relativement chère à l'époque, mais qui ne souffre toujours pas de lenteur à ce jour (PS, LR, DXO). Je ne regrette pas d'avoir vu un peu grand car on s'y retrouve sur la durée.

[Nikojorj]

Oui, mais qui sait de quoi demain sera fait : PS, DXO, vidéo ... ?

Du coup, c'est souvent plus rentable d'attendre demain pour savoir de quoi on aura besoin, et de trouver alors plus efficace pour moins cher qu'aujourd'hui...

Et ce que je voulais souligner, c'est que LR a besoin d'un processeur cadencé rapide, mais pas forcément d'un i7 avec beaucoup de cœurs virtuels (hyperthreading).

[Dub]

Et ce que je voulais souligner, c'est que LR a besoin d'un processeur cadencé rapide, mais pas forcément d'un i7 avec beaucoup de cœurs virtuels (hyperthreading).

LR se sert des 8 cœurs du i7... du moins sur Mac ...

[Nikojorj]

Sous Win c'est moins évident : http://www.chassimages.com/forum/index.php/topic,227076.0.html

Et après, y'a aussi la question de savoir si on y gagne vraiment avec les cœurs virtuels (qui est en fait le principe d'occuper un seul cœur avec 2 processus).
Des fois, on y perd aussi : http://www.pugetsystems.com/blog/2014/07/02/Hyper-Threading-may-be-Killing-your-Parallel-Performance-578/

[Thoms]

Si ça peut t'aider, j'avais demandé un peu d'aide il y a peu sur le même sujet, sachant que j'avais les même besoins que toi (quasiment que LR en gros).

http://www.chassimages.com/forum/index.php/topic,222477.0.html

[dominos]

Sous Win c'est moins évident : http://www.chassimages.com/forum/index.php/topic,227076.0.html

Et après, y'a aussi la question de savoir si on y gagne vraiment avec les cœurs virtuels (qui est en fait le principe d'occuper un seul cœur avec 2 processus).
Des fois, on y perd aussi : http://www.pugetsystems.com/blog/2014/07/02/Hyper-Threading-may-be-Killing-your-Parallel-Performance-578/

+ 1000.

Sous Windows, le problème ne vient pas d'une config musclée, mais de LR au final. Pour MAC, je ne sais pas.

Que je charge LR seul ou pas avec plein d'autres programmes gourmands, dans ma config actuelle musclée ou passée cela ne change pas grand chose.

De ce fait et pour d'autres raisons, mon Workflow n'est pas complètement LR.

THG semble maintenant prendre en compte ce problème aujourd'hui sur le fait que le coeur de LR doit être revu.

Bien cordialement.

[fred134]

Sur un PC j'en ai un de 256 et sur un autre de 512. Celui de 256 est vite plein. J'ai un catalogue de + 150 000 photos et Lr avec celui-ci plus un Backup pèse plus de 60go.
Il est pratique de passer par le SSD pour le traitement des photos avant de les placer sur un disque externe de sauvegarde.
Le prix des SSD a fortement baissé. Les 500go sont à moins de 200€ sur A...Z ..N

OK compris, merci. C'est pour de gros besoins quand même. Avec 34K photos, mon "catalogue + aperçus" ne fait que 20 GB sur le SSD (le backup est ailleurs).
Perso, je suivrais ton conseil, c'est vrai qu'à 200€ les 500GB ce n'est plus très cher, maintenant on peut aussi objectivement se contenter de moins si on veut économiser 100 ou 150€.

Je ne sais pas si ça apporte grand-chose d'avoir les raw sur SSD pour le développement, à l'essai j'avais l'impression que cela ne changeait pas quasiment rien, les accès disque ne me semblaient pas dominants dans cette phase. As-tu une expérience différente ?

[Gérard B.]

L'avantage du SSD n'est pas tant dans le traitement des Raws mais dans la vitesse d'affichage des aperçus.
Pour mon usage, il m'est très important d'avoir des aperçus 1:1 très rapidement et de pouvoir les faire défiler de manière fluide.
J'ai souvent besoin de faire des affichage 100% pour vérifier la netteté.

[fred134]

L'avantage du SSD n'est pas tant dans le traitement des Raws mais dans la vitesse d'affichage des aperçus.
Pour mon usage, il m'est très important d'avoir des aperçus 1:1 très rapidement et de pouvoir les faire défiler de manière fluide.
J'ai souvent besoin de faire des affichage 100% pour vérifier la netteté.

Oui, je trouve aussi (le 100%, c'est même un de mes gros griefs vis-à-vis de LR comparé à C1), mais c'est uniquement l'emplacement du catalogue + aperçus qui compte, non ? (pas des raw, je veux dire, on a le même retour sur ce point semble-t-il)

[fabco]

Pour des gros fichiers type raw un ssd n'apporte rien.L'avantage des ssd c'est qu'il n'y a pas de déplacement de tête.Donc le cas le plus favorable c'est sur des petits fichiers et des accés à répétition comme par exemple une base de donnée.

[Dub]

Pour des gros fichiers type raw un ssd n'apporte rien.L'avantage des ssd c'est qu'il n'y a pas de déplacement de tête.Donc le cas le plus favorable c'est sur des petits fichiers et des accés à répétition comme par exemple une base de donnée.

Ahhh ... un scoop ...

[baséli]

L'avantage des ssd c'est qu'il n'y a pas de déplacement de tête.Donc le cas le plus favorable c'est sur des petits fichiers et des accés à répétition comme par exemple une base de donnée.

Ce n'est pas faux, sauf que les raw sont devenus des petits fichiers (tout tient en RAM! Et je te parle pas du cas où c'est fragmenté en trois ou quatre morceaux), et que même si ce n'est pas le plus favorable, ce n'est pas sans effet. Je ne changerai pas mon baril de SSD contre deux barils de DD. L'essayer c'est l'adopter.

[fabco]

quand je parle de petits fichiers cela ne dépasse pas quelques kilo octets.
Un raw fait quand même 30mo pour 24mp.

J'ai fait des essais en mettant des raw sur un ssd, je n'ai aucun bénéfice par rapport à un DD mécanique.
Un gros proc et de la mémoire sont 10000 fois plus efficaces qu'un SSD pour gagner du temps de traitement.

[Labuzan]

Un gros proc et de la mémoire sont 10000 fois plus efficaces qu'un SSD pour gagner du temps de traitement.

+1 
Aucun intérêt d'un SSD pour les RAW

[Dub]

Quel est le rapport entre un SSD et un RAW  

Ensuite , il parait évident que si il n'y a pas d'accès "disque" , SSD ou pas ...

[Samoreen]

Les raisonnements que je lis ci-dessus à propos de l'intérêt ou non d'un SSD sont pertinents ou pas selon la manière dont travaille le programme. Explications...

Sous Windows, un programme moderne qui doit traiter de gros fichiers d'un seul tenant n'utilise (normalement) pas la technique habituelle de lecture/écriture, mise dans un tampon intermédiaire et traitement. Il passe par ce que l'on appelle un MMF (memory mapped file). Ce mécanisme permet de traiter une grosse masse de données comme un tampon en mémoire sans avoir à se préoccuper des lectures/écritures entre disque et tampon. En fait, il traite le gros fichier exactement comme est traitée la mémoire virtuelle : le fichier en question est vu exactement de la même manière que le fichier de pagination système. Ou dit autrement, le programme voit le fichier comme un énorme tampon en mémoire pouvant être de taille supérieure à la mémoire physique présente dans le système. Les lectures/écritures sont donc traitées à un niveau beaucoup plus bas, de manière automatique et de loin plus performante (exactement la même performance que la mémoire virtuelle).

De même qu'il est évident que le déplacement du fichier de pagination vers un disque SSD améliore les performances du système, il est évident qu'une application qui utiliserait le mécanisme des MMF pour traiter des fichiers importants bénéficierait des mêmes améliorations.

Ce mécanisme est disponible sous Windows et également sous Linux/Unix dans une forme beaucoup plus primitive mais exploitable. J'ai examiné l'état du système pendant une session de développement sous Lightroom mais je n'ai pas trouvé trace d'objets de type MMF pouvant être associés à Lightroom et à un fichier image en cours de traitement.

Donc la réponse à la question pourrait en fait être : oui un SSD pourrait améliorer les performances pendant le traitement d'un RAW si Lightroom voulait bien utiliser les mécanismes de programmation adéquats. Je pense qu'ils ne le font pas soit à cause de leur objectif de portabilité entre plates-formes, soit à cause des outils qu'ils utilisent pour la programmation de Lightroom, soit parce qu'ils ne savent pas que le mécanisme des MMF existe (j'ai souvent constaté cette ignorance parmi mes étudiants).

[fred134]

Donc la réponse à la question pourrait en fait être : oui un SSD pourrait améliorer les performances pendant le traitement d'un RAW si Lightroom voulait bien utiliser les mécanismes de programmation adéquats.

Cela dépend aussi de l'importance relative des I/O disque dans cette phase, non ? N'ont-ils pas un poids assez faible par rapport aux traitements dans l'usage du module de développement ?

[Samoreen]

Cela dépend aussi de l'importance relative des I/O disque dans cette phase, non ? N'ont-ils pas un poids assez faible par rapport aux traitements dans l'usage du module de développement ?

Quelle que soit la manière dont le programme fonctionne, on en revient toujours au même problème : pour faire certains calculs, on a besoin d'avoir accès à la totalité des pixels de l'image. Plus la part de ces données stockées en mémoire est importante, moins il y a d'I/O. C'est une évidence. Ce ratio dépend de la configuration du système. Mais dans une situation donnée, ces I/O se passeront de manière plus performante si elles sont traitées via un MMF plutôt que via un mécanisme de lecture/écriture classique. C'est ça que je voulais dire.

[Labuzan]

Ensuite , il parait évident que si il n'y a pas d'accès "disque" , SSD ou pas ...

C'est juste ce que je voulais dire ; mais ce n'est pas forcément évident pour tout le monde 

[baséli]

soit parce qu'ils ne savent pas que le mécanisme des MMF existe (j'ai souvent constaté cette ignorance parmi mes étudiants).

Pour des étudiants, je veux bien. Pour Adobe, faut les virer si c'est le cas. Il y en a au moins un qui sait quand même!

Par curiosité, comment fais-tu pour savoir sous Unix si un programme utilise mmap? Je ne crois pas qu'il existe de structure de donnée documentée associée, puisque l'appel de munmap nécessite de passer la description de la zone mémoire à libérer?

[Samoreen]

Pour des étudiants, je veux bien. Pour Adobe, faut les virer si c'est le cas. Il y en a au moins un qui sait quand même!

Pas évident. Les MMFs ne font pas partie des cursus de programmation usuels et comme la plupart des développeurs travaillent maintenant avec des frameworks qui encapsulent tout ce qui est système, l'ignorance de ces fonctions système avancées est assez généralisée. Je ne compte pas le nombre de fois où on m'a demandé de former aux MFC ou à des outils équivalents des gens frais émoulus de l'école ou de l'université et qui ne connaissaient pas les bases du système.

C'est une approche pédagogique contre laquelle je me suis toujours battu car quand le framework est défaillant, seule la connaissance des APIs système qu'il utilise permet au développeur de faire un diagnostic (s'il dispose des sources du framework, ce qui malheureusement n'est pas toujours le cas). À tel point qu'en tant que consultant, j'ai fini par refuser de faire des cours sur les frameworks usuels à des gens qui n'avaient pas déjà suivi un cours de programmation et d'architecture système, même basique.

Par curiosité, comment fais-tu pour savoir sous Unix si un programme utilise mmap? Je ne crois pas qu'il existe de structure de donnée documentée associée, puisque l'appel de munmap nécessite de passer la description de la zone mémoire à libérer?

Je ne crois pas non plus que ça soit possible mais il y a longtemps que je n'ai pas regardé de ce côté (et ça n'arrivera plus puisque j'ai cessé de coder depuis 2010 pour cause de retraite). Peut-être que ça a évolué mais je n'y crois guère. Windows (à partir de Windows NT et suivants) est un système dont l'architecture est orientée objet et tout à été prévu dès le départ pour permettre le suivi de chaque processus. Il est donc relativement facile de déterminer quels sont les objets en cours d'utilisation. Il y a un utilitaire qui fait ça très bien : WinObj. On le trouve dans le SDK Windows. Il y a aussi Process Explorer, issu de la fameuse suite SysInternals (aujourd'hui hébergée chez Microsoft), qui affiche directement les objets créés par un processus donné. Un outil indispensable non seulement au programmeur mais à l'utilisateur avancé. Par exemple, si on veut savoir quel processus maintient verrouillé tel ou tel fichier (un cas de figure assez fréquent), Process Explorer donnera la réponse en quelques secondes.

Avec ces outils, on voit que Lightroom utilise bien des objets de type SECTION (c'est le nom donné aux MMFs dans la nomenclature des objets) mais en fait, ce sont les MMFs créés pour gérer l'exécutable lui-même et pour des tâches système diverses. Ils sont donc créés par Windows pour le compte de Lightroom mais Lightroom lui-même ne s'en sert pas. Quasiment toute la programmation de Lightroom utilise des outils de haut niveau qui font abstraction du système, la non-utilisation des MMFs n'est donc pas une surprise.

C'est dommage car je suis sûr qu'on gagnerait en performance. On pourrait rétorquer que ça serait au détriment de la portabilité mais rien n'empêche, en gardant le reste à l'identique, de créer un module particulier qui traiterait les I/O de cette manière avec le mécanisme adéquat pour le système considéré (MMF pour Windows, mmap ou équivalent pour Mac OS).