Plateforme d’évaluation et limites théoriques

Notre plateforme d’évaluation se compose de quatre systèmes identiques chacun équipé avec une configuration de mémoire de masse spécifique. Le premier, nommé HDD, utilise un seul HDD ; le second, hybride, dispose d’un SSD en plus du HDD ; le troisième, SSD, est équipé d’un

seul SSD ; le quatrième, RAID-0 exploite un RAID logiciel composé de quatre SSD identiques pilotés par l’outil mdadm2_{. Le système de fichier ext4 est utilisé sur toutes les configurations.} Les références matérielles des mémoires de masse sont les suivantes :

— HDD 7200 tr/min SATA : HGST Travelstar 0J22423 - 7K1000 (version 1 To) ; — SSD SATA : Transcend SSD370S (version 256 Go).

Le tableau4.10 présente les vitesses maximales effectives de lecture et d’écriture que nous avons mesurées en réalisant des accès séquentiels à l’aide de la commande dd(1). Ces vitesses correspondent aux spécifications techniques émises par les constructeurs respectifs des deux types de mémoire de masse. La configuration RAID 0 logiciel permet une accélération d’un facteur de 3,17× en lecture et de 3,87× en écriture par rapport à un SSD seul.

Tableau 4.10 : Vitesses maximales en accès séquentiels selon la configuration des mémoires de masse

HDD SSD RAID 0 (4 SSD)

Vitesse en lecture 135 Mo/s 535 Mo/s 1700 Mo/s Vitesse en écriture 125 Mo/s 310 Mo/s 1200 Mo/s

Les quatre systèmes sont équipés d’un processeur Intel Xeon D-1521 avec 2× 4 Gio de mémoire vive DDR4 fonctionnant à 2133 MT/s, sur que d’une carte mère Supermicro X10SDV-4C-TLN2F. Le système d’exploitation est Ubuntu 18.04.1 LTS doté du noyau Linux 4.15.0-43-generic. Les programmes sont compilés par le compilateur gcc en version 7.3.0 avec les options -O3 -fopenmp.

Nous réalisons la comparaison de trois implémentations différentes de rotation de matrices : — Simple est l’implémentation de l’algorithme naïf présenté dans la figure4.1 (b3) du

chapitre 4 : Rotation et transposition de matrices rectangulaires out-of-core et out-of-place qui réalise la transformation à partir et à destination de deux fichiers mappés rendus accessibles par la fonction mmap(2) en manipulant les éléments un par un grâce à deux boucles imbriquées ;

— Caldera est une implémentation qui a été développée spécifiquement par la société Caldera pour la rotation rapide de matrices out-of-core et out-of-place. Elle est optimisée manuellement pour réduire la quantité de données lues et écrites en traitant la matrice d’entrée tuile par tuile tout en exécutant les écritures de façon séquentielle. Cette implémentation est utilisée dans son logiciel CalderaRIP V12.0 [Cal18] ;

— MaRTOO (prononcée « marteau », pour « Matrix Rotation and Transposition Out-of-core Out-of-place ») implémente notre solution utilisant l’algorithme que nous avons décrit dans le chapitre 4 : Rotation et transposition de matrices rectangulaires out-of-core et

out-of-place.

2. Utilitaire standard des noyaux Linux pour la gestion de configurations RAID logicielles

Nous n’avons pas trouvé d’autres implémentations proposant la transformation efficace de matrices rectangulaires dans des conditions out-of-core et out-of-place pour compléter nos évaluations. Cependant, la version Caldera a été hautement optimisée en se basant sur les connaissances disponibles lors de son écriture, aussi la considérons-nous comme à l’état de l’art.

Contrairement à l’implémentation Simple, l’implémentation Caldera et MaRTOO utilisent une mémoire intermédiaire pour réaliser les transformations tuile par tuile dans la mémoire vive, avant d’écrire le résultat dans le fichier de sortie. Ainsi, nous exécutons nos évaluations avec trois tailles différentes de mémoire intermédiaire : 35 Mo, 1 Go et 5 Go. Ces trois tailles correspondent respectivement à : un usage restreint de la mémoire vive, un usage modéré, et un usage glouton. Allouer 5 Go de mémoire vive sur notre plateforme d’évaluation implique de n’en laisser que 3 Go pour le noyau et les autres programmes et services en cours d’exécution.

Nous utilisons le programme cp(1) comme référence pour évaluer le temps d’exécution des différentes implémentations. Celui-ci permet de réaliser une copie exacte du fichier indiqué, ce qui correspond au critère out-of-place sans application de transformation. Nous utilisons l’implémentation standard de cp(1) sans option particulière dans sa version 8.28 issue du paquet d’application GNU coreutils3 fourni par défaut dans la majorité des distributions Linux. Les temps d’exécution de cp(1) sont collectés avec les mêmes exigences et précautions d’état stable et de reproductibilité présentées précédemment. La figure4.11met en évidence l’évolution linéaire des temps d’exécution de cette référence selon la taille de la matrice copiée et la configuration de mémoire de masse utilisée. De plus, les temps d’exécution confirment les vitesses de lecture et d’écriture présentées dans le tableau 4.10. Ces deux observations démontrent la qualité et la validité de ce programme comme référence des temps d’exécution optimaux. 1 10 100 1000 10000 8 16 32 64 Temps d'e xécution (s)

Taille matrice (Go)

HDD SSD RAID 0

Figure 4.11 : Temps d’exécution du programme cp(1) en fonction de la taille de la matrice et de la configuration des mémoires de masse

Dans chacune de nos évaluations, les éléments des matrices ont une taille de 1 octet, ce qui correspond à la précision habituelle d’un canal chromatique d’un pixel d’une image

d’entrée. Ainsi, la taille des matrices indique également le nombre d’éléments traités. Nos expérimentations préliminaires ont montré que modifier la taille des données en conservant la même quantité totale de données n’impactait pas le temps d’exécution de la transformation. De ce fait, les résultats présentés sont valables pour d’autres types (char, int, float, etc.) ou tailles (8 bits, 16 bits, etc.) d’éléments.

Enfin, parallèlement au temps d’exécution, nous relevons la quantité de données accédées en lecture et en écriture sur les mémoires de masse par le biais de statistiques offertes par le noyau Linux au travers de l’interface /proc/<pid>/io/.