LR et ordi qui rame

[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).