Hier, j’ai publié des tests de six distributions Linux sur le HP Dev One, le nouvel ordinateur portable Linux passionnant lancé par HP en collaboration avec System76 qui utilise leur distribution Pop!_OS. À partir de ces références, l’une des découvertes bizarres était que les performances de compression Zstd sur Arch Linux étaient tout simplement nulles, mais certains développeurs intéressés ont plongé et ont trouvé le coupable plutôt bizarre pourquoi leurs performances Zstd sont si médiocres par rapport aux autres distributions Linux sur la même version.
Les performances du binaire zstd fourni par Arch Linux se sont avérées extrêmement lentes par rapport aux autres distributions Linux sur ce même ordinateur portable… Bien plus lentes que les autres distributions Linux testées sur le même matériel exact et toutes les distributions utilisant leur binaire Zstd fourni par le système pour ces benchmarks :
Mais les résultats étaient reproductibles, répétés plusieurs fois, et je me tiens derrière les benchmarks. Bien qu’étant étiré pour joindre les deux bouts (envisagez de désactiver votre bloqueur de publicités ! Ou de rejoindre Phoronix Premium pour un visionnage sans publicité et d’autres avantages), je n’ai pas eu le temps ni les ressources pour approfondir ce problème particulier. avec régulièrement (presque quotidiennement) des particularités de performances similaires avec différents matériels/logiciels sous Linux.
Heureusement, certains développeurs passionnés d’Arch Linux se sont penchés sur cet article et ont trouvé la raison plutôt surprenante pour laquelle leurs performances Zstd étaient scandaleusement lentes :
Le système de construction (en quelque sorte). Hein ? Non, pas de différence d’indicateurs de compilateur pour régler l’optimisation ou le niveau… Arch Linux utilise le système de construction CMake de Zstd pour construire son paquet tandis qu’Ubuntu et d’autres distributions Linux utilisent souvent la version simple Makefile fournie par Zstd. Zstd fournit également la prise en charge du système de construction Meson. Les développeurs Arch Linux ont découvert que l’utilisation de CMake pour la construction de Zstd entraînait une vitesse de compression Zstd plus lente, mais si l’utilisation de la construction de fabrication conventionnelle était conforme aux attentes (Meson a également régressé).
Alors, comment diable le système de construction interfère-t-il avec les performances binaires résultantes s’il ne s’agit pas d’une différence de niveau d’optimisation ? C’est là que ça devient encore plus étrange et un autre exemple de l’impact que la prise en charge de plusieurs systèmes de construction peut avoir sur le projet…
Le système de construction CMake pour Zstd finit par ajouter le”-std=c99“alors que les autres systèmes de construction ne spécifient pas l’utilisation de la norme C99. De manière assez surprenante, la spécification de la norme C99 est ce qui a finalement causé cette grande différence de performances… Mais quant à la raison pour laquelle la spécification de C99 provoque une différence de performances aussi importante, cela est probablement dû à un problème/différence de thread, mais pour le moment il n’y a pas ça ne semble pas être une explication solide. Dans tous les cas, il s’agit d’un bogue Zstd avec un comportement fondamental différent en fonction du système de construction pris en charge utilisé.
Les développeurs ont testé la construction basée sur CMake sans spécifier le”-std=c99″et cela a donné des performances similaires aux binaires Zstd produits par les systèmes de construction alternatifs. Alternativement, régler C11 à la place était correct aussi.
L’excellent travail des développeurs/contributeurs d’Arch Linux (Arvid Norlander, Antonio Rojas, etc.) est présenté via leur Rapport de bogue Arch Linux et l’avoir également signalé à Zstd en tant que problème en amont. Espérons que Zstd modifiera à son tour sa version standard du langage C pour CMake afin qu’elle corresponde au comportement de ses autres systèmes de construction ou qu’elle unifie mieux la gestion des choses.
Arch Linux a au moins une solution de contournement simple et devrait donc être en mesure d’expédier bientôt un correctif à ses utilisateurs pour fournir de bien meilleures performances.
