Améliorer les performances de darktable

[aurelienpierre]

Ce sujet est une ébauche concernant les techniques pouvant améliorer le temps de traitement des photos par darktable. Ces méthodes ne sont pas garanties. Elles ne s'appliquent qu'à Linux car pour optimiser des systèmes propriétaires, il faudrait encore savoir comment ils fonctionnent.

Introduction : performance ou réactivité ?

L'utilisateur non averti confond la performance avec la réactivité. Ces deux concepts sont pourtant quasi antinomiques.

• un ordinateur exporte une photo en très peu de temps : il est performant,
  
• un ordinateur exécute immédiatement un logiciel quand on clique sur son icône : il est réactif.
  

Comment ça se passe sous le capot ? Imaginez que le processeur de l'ordinateur soit un employé de bureau :

• l'employé A traite un dossier, et un seul. Quand il a fini, et seulement quand il a fini, il va prendre un nouveau dossier sur la pile. Il y a de fortes chances que l'employé A soit le très performant, puisqu'il ne fait qu'une seule chose, mais il y a aussi des chances pour qu'il laisse pourrir des dossiers prioritaires sans le savoir. Il faut alors autant d'employés de type A qu'il y a de dossiers à traiter simultanément dans l'entreprise.
  
• l'employé B traite un dossier, et un seul. Mais il s'interrompt toutes les 5 min pour vérifier si un dossier plus urgent n'attend pas sur la pile. Le cas échéant, il traite le dossier prioritaire puis revient au dossier initial. L'employé B sera moins performant que le A car il s'arrête tout le temps, cependant il est meilleur pour gérer les imprévus de l'entreprise. Il faut alors autant d'employés de type B qu'il y a de dossiers à traiter simultanément dans l'entreprise.
  
• l'employé C traite plusieurs dossiers simulatément, mais ne peut en avoir qu'un seul sur son bureau à la fois. Il va donc accorder 10 minutes au dossier 1, puis 10 minutes au dossier 2, puis 10 minutes au dossier 3, etc. puis revenir au dossier 1. Il peut aussi choisir de retraiter plus souvent un dossier prioritaire, et/où d'y accorder plus de temps qu'aux autres, ou même de le traiter en entier avant de passer aux autres. Pour définir les dossiers à traiter, et leur priorité, l'employé C doit, comme le B, s'interrompre pour vérifier la pile. L'employé C sera le moins performant des trois, et sera moins bon que le B pour gérer les imprévus, mais un petit nombre d'employés C sera suffisant pour gérer tous les flux de l'entreprise. De plus, comme il ne peut avoir qu'un seul dossier sur son bureau, il doit prendre le temps d'amener et de remettre chaque dossier de la pile à son bureau, et inversement.
  

Imaginez que l'entreprise soit un système d'exploitation, que les employés soient des cœurs de processeur, que les dossiers soient des programmes à exécuter, que le bureau de l'employé soit la mémoire cache du processeur, et que la pile de dossier soit la mémoire RAM du système.

Il y a bien longtemps que les systèmes d'exploitations sont trop compliqués pour fonctionner en mode A ou B : il faudrait trop de processeurs, ou on ne traiterait pas assez de programmes en même temps. Ouvrez votre gestionnaire de tâches et comptez leur nombre : j'en ai une soixantaine sur un système optimisé.

Le mode C possède différentes stratégies (en fonction de la priorité des tâches) pour répartir les tâches entre les processeurs, qui sont gérées par des ordonnanceurs (en anglais : scheduler). Linux embarque par défaut CFS.

La morale de cette introduction est qu'un système qui réagit vite aux événements (commandes de l'utilisateur, capture de flux audio, vidéo, opérations synchronisées) doit s'interrompre plus souvent (en général, toutes les 10 millisecondes) pour lire la pile de tâches, et a plus de chances d'exécuter ses tâches moins vite. Cependant, un tel système donne une illusion trompeuse de performance à l'utilisateur, puisque l'interface répond au quart de tour. En général, un système d'exploitation classique s'interrompt toutes les 50 à 100 millisecondes (ce qui n'est pas assez pour enregistrer du son par exemple, pour cette raison on a des système temps-réel à 10 ms).

Du point de vue de darktable, les tâches sont des opérations mathématiques sur les valeurs RGB des pixels. Elles sont systématiques (répétées de la même manière pour chaque pixel), et donc prévisibles (on découpe l'image en autant de parties que de processeurs/cœurs, chaque processeur devrait mettre le même temps à traiter son bout d'image). On aimerait donc éviter de laisser l'ordonnanceur faire plein de vérifications compliquées pour optimiser l'ordre des tâches, et laisser darktable exécuter ses calculs sans s'interrompre.

1. Choisir un système d'exploitation stable

Venant de migrer de Linux Ubuntu 16.04 à Debian 9.3, j'ai vu la rapidité d'exportation de darktable augmenter de façon inexplicable. Notamment le module « liquéfier », qui devient enfin utilisable.

Certains utilisateurs de darktable sous Windows rapportent une meilleure performance avec darktable tournant dans une machine virtuelle Linux installée sur Windows qu'avec l'application Windows native.

Tous les systèmes d'exploitations ne se valent pas, et toutes les distributions Linux non plus. Suivant les versions des librairies utilisées par les distributions, suivant les combinaisons de logiciels utilisées et les environnements de bureau, on créée des distributions plus ou moins performantes, plus ou moins stables.

Le site phoronix.com fourni des comparatifs réguliers des performances sur différents benchmarks entre les différentes distributions :

• Comparatif 2017
  
• Comparatif 2016
  
• Comparatif post-Meltdown 2018
  

Les benchmarks pertinents pour darktable sont ceux impliquant SQLite, le calcul parallèle avec OpenMP et les lectures/écritures de fichiers (I/O). Les deux distributions qui ressortent en tête de façon assez homogène sont Ubuntu et Debian (pour les départager : https://www.phoronix.com/scan.php?page=a...soon&num=3).

2. Compiler darktable

La compilation n'est pas si effrayante qu'elle en a l'air. Elle consiste à créer des binaires exécutables à partir du code source en C/C++. Les versions packagées de dt sont déjà compilées pour vous. Cependant, ce sont des compilations génériques. En effet, chaque famille de processeur possède des jeux d'instructions spécifiques et optionnels, qui permettent des optimisations fines au cas par cas. Recompiler le logiciel pour votre architecture spécifique peut permettre de déverrouiller ces optimisations et d'aller chercher un supplément de performance.

Il vous faudra installer git au préalable. Par sécurité, désinstaller la version actuelle de darktable s'il y en a une. Puis exécutez les commandes suivantes dans un terminal :

Code :

$ git clone git://github.com/darktable-org/darktable.git
$ cd darktable
$ git checkout release-2.4.0 # ignorez cette ligne si vous voulez la dernière version de développement (instable) ou adaptez le numéro de version
$ git submodule init
$ git submodule update

La partie la plus difficile est ensuite de faire la chasse aux dépendances requises. La page https://redmine.darktable.org/projects/d...rktable_22 vous donnera de plus amples renseignements suivant votre configuration. Vous devez basiquement installer toutes les librairies requises par dt pour compiler. Ensuite, exécutez :

Code :

sudo sh build.sh --build-type Release --install

Si la compilation s'arrête sur une erreur, par exemple :

Code :

--   No package 'gtk+-3.0' found
CMake Error at /usr/share/cmake-3.7/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Could NOT find GTK3 (missing: GTK3_INCLUDE_DIRS GTK3_LIBRARIES) (Required
  is at least version "3.14")

il faut aller chercher quel paquet de votre distribution fournit la librairie manquante et l'installer (habituellement, ce sont des paquets dont le nom finit par -dev). Ici c'est libgtk-3-dev qui manque. Si votre système est différent de ceux listés sur la documentation, trouver les bons paquets peut être un peu fastidieux mais ça n'est pas plus compliqué que cela.

Une fois les dépendances satisfaites, relancez :

Code :

sudo sh build.sh --build-type Release --install

La partie un peu pénible est qu'il faudra recommencer l'opération manuellement à chaque mise à jour. On accède alors à darktable par la commande :

Code :

/opt/darktable/bin/darktable

Si vous utilisez Ubuntu ou Debian, vous pouvez installer le paquet alacarte pour éditer l'entrée darktable du menu des applications et modifier le chemin de l'exécutable.


3. Optimiser la gestion du processeur (Intel seulement)

Assurez-vous d'utiliser les dernier pilotes Intel P-state et le dernier micro-code (en général, le paquet est appelé intel-microcode).

Utilisez le contrôleur "performance" de P-state (par défaut, il utilise "powersave"). Il existe plusieurs moyens simples (modules, applets, etc.) qui permettent de changer cette consigne dans votre environnement de bureau (Gnome, KDE, Unity, etc.). Cherchez "cpufreq" dans votre distribution.

Il est aussi possible de désactiver complètement les C-states Intel. Ceux-ci sont des états de veille plus ou moins profonds (voire de débranchement électrique) des cœurs non utilisés, dans des cas de charge processeur réduite, pour réduire la consommation électrique. Ces cœurs sont automatiquement réactivés quand la charge système augmente, mais il y a un latence, une sorte de retard à l'allumage. Une amélioration de 10 % a été rapportée par certains utilisateurs en les désactivant. Pour ce faire, éditez le fichier /etc/default/grub à la ligne GRUB_CMDLINE_LINUX_DEFAULT comme suit :

Code :

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=0 processor.max_cstate=0"

puis exécutez :

Code :

sudo update-grub

Il est évident que cette manipulation va réduire l'autonomie de votre batterie si vous êtes sur portable.

4. Réglez la priorité du processus darktable

On a vu dans l'introduction que le système gère à la volée les différents processus (aussi appelés tâches) suivant leur priorité. On peut donc attribuer une plus grande priorité à dt. Ceci risque de geler le système quand dt calcule, mais, à moins que vous n'écoutiez de la musique en même temps, ça n'a pas grande importance. Lancez darktable de la façon habituelle puis exécutez :

Code :

gksudo -- renice -n -20 -p $(pgrep ^darktable$)

À l'aide du programme alacarte (Unity et Gnome), vous pouvez créer un lanceur pour exécuter cette commande après avoir lancé darktable.

5. Optimisez la lecture/écriture sur SSD

De même qu'il y a un ordonnanceur pour les tâches processeur, il y en a un pour les tâches de lecture/écriture sur les disques durs, qui distribue l'accès au disque aux différentes applications qui l'utilisent.

Par défaut, Linux utilise CFQ, particulièrement adapté aux disque-durs optiques (rotatifs). Pour les SSD, cette stratégie est sous-optimale, et deadline ou noop donne de meilleurs résultats. Noop, en particulier, suppose que le SSD a une puce dédiée à la gestion des entrées-sorties et que le système d'exploitation ne fera pas mieux que la puce, qui connaît l'architecture du disque. Donc il revient à ne pas gérer les accès, mais à laisser le disque s'en occuper.

Pour changer cette règle, éditez le fichier /etc/default/grub, et à laligne GRUB_CMDLINE_LINUX, entrez :

Code :

GRUB_CMDLINE_LINUX="elevator=noop"

puis exécutez :

Code :

sudo update-grub

6. Ajuster OpenCL

Ajuster OpenCL est compliqué et dépend beaucoup de votre matériel. Je ne vais m'étendre dessus ici, je vous renvoie à la doc officielle.

7. Travailler sur des copies locales

Si, pour des raisons de place, vous avez l'habitude de stocker vos photos sur des disques durs externes, il peut être intéressant de copier les photos de travail temporairement sur votre disque interne, pour diminuer les latences et accélérer la lecture de l'image. darktable offre nativement cette possibilité, dans la table lumineuse, colonne de droite, module "images sélectionnées", bouton "copier localement" (il faut bien sûr sélectionner les images à copier au préalable). Quand vous avez terminé et exporté, sélectionnez à nouveau les images copiés localement (elles ont un point blanc sur leur miniature), puis cliquez sur "resync copie locale" (même endroit que pour la copie).

8. Tester et évaluer

Pour voir les temps d'export et comparer l'impact de vos modifications sur la performance du logiciel, vous pouvez exécuter darktable en console avec les paramètres :

Code :

darktable -d perf

Dans mon cas, par exemple, faire une copie locale (conseil 7.) me fait gagner 0.1 s et augmenter la priorité de darktable (conseil 4.) ne génère aucun bénéfice (sur un système puissant et peu chargé). Passer mon processeur en mode "performance" me fait gagner 1,5 % du temps d'exportation.

[Carafife]

Passionnant !

[jpg54]

Comme d'habitude, une super article qui vulgarise la théorie. J'ai bien l'analogie entre le travail des cœurs d'un processeur avec les employés d'une entreprise (je n'y aurais pas pensé).
Je diffère un peu dans la chaîne de compilation :
https://docs.google.com/document/d/1Cjny...sp=sharing
Je ne sais pas quelle est la meilleure ?
Une petite coquille : tu situes "copier localement" dans la chambre noire alors que c'est accessible dans la table lumineuse.

[aurelienpierre]

Comme d'habitude, une super article qui vulgarise la théorie. J'ai bien l'analogie entre le travail des cœurs d'un processeur avec les employés d'une entreprise (je n'y aurais pas pensé).
Je diffère un peu dans la chaîne de compilation :
https://docs.google.com/document/d/1Cjny...sp=sharing
Je ne sais pas quelle est la meilleure ?
Une petite coquille : tu situes "copier localement" dans la chambre noire alors que c'est accessible dans la table lumineuse.

Merci Jean-Paul, c'est corrigé. En fait les deux méthodes se rejoignent, c'est juste que le script build.sh avec l'option --install fait directement le cmake build install.