Zlib-rs est plus rapide que le C

• zlib-rs est une implémentation de zlib en Rust pour la compression de données, et la récente sortie de la version 0.4.2 apporte de nettes améliorations de performances
• Il s’agit actuellement de l’implémentation de zlib compatible API la plus rapide, avec des performances particulièrement supérieures en décompression par rapport aux solutions concurrentes
• Principales améliorations de performances : sélection automatique à l’exécution de l’implémentation SIMD optimale, application d’optimisations DFA, etc.

Multiversioning

• Sélection automatique à l’exécution de la version de fonction la plus rapide selon le CPU
• Rust ne prend pas en charge nativement le multiversioning, il faut donc l’implémenter manuellement
• Permet d’offrir les meilleures performances tout en minimisant l’overhead à l’exécution

Optimisation DFA (Deterministic Finite Automata)

• Le langage C améliore les performances en utilisant un fallthrough implicite dans les instructions switch
• Rust ne dispose pas d’un mécanisme similaire, ce qui entraîne une baisse de performances
• Application de l’option LLVM -Cllvm-args=-enable-dfa-jump-thread → récupération des performances
• Ce réglage n’est pas inclus dans la configuration par défaut de LLVM, mais devrait être activé par défaut dans Rustc à l’avenir

Comparaison des performances en benchmark

1. Comparaison avec zlib-ng

• zlib-rs affiche de meilleures performances que zlib-ng sur la plupart des tailles d’entrée
• En particulier, il est environ 10 % plus rapide sur une entrée de 1 KB et environ 6 % plus rapide sur une entrée de 65 KB
• Il est légèrement en retrait sur les plus petites tailles d’entrée, mais reste globalement supérieur

Par exemple :

• Pour une taille d’entrée de 4 octets, zlib-ng est légèrement plus rapide, mais l’impact en usage réel est limité
• Pour une taille d’entrée de 1 KB, zlib-rs est environ 10 % plus rapide
• Pour une taille d’entrée de 65 KB, zlib-rs est environ 6 % plus rapide

→ Avantage net de performance face à zlib-ng sur les gros blocs

2. Comparaison avec zlib-chromium

• Sur les petits blocs, zlib-chromium est plus rapide
• Mais sur les gros blocs, zlib-rs prend l’avantage
• Sur les tailles d’entrée courantes, zlib-rs offre de meilleures performances

Par exemple :

• Pour une taille d’entrée de 4 octets, zlib-chromium est environ 12 % plus rapide
• Pour une taille d’entrée de 16 octets, zlib-chromium est environ 6 % plus rapide
• À partir de 1 KB d’entrée, zlib-rs prend l’avantage en performances

→ zlib-rs plus performant sur les tailles courantes

Comparaison des performances de compression

• Les performances de compression sont encore en cours d’amélioration, avec des résultats mitigés
• Amélioration de 6 % au niveau de compression par défaut (6), et de 13 % au niveau de compression maximal (9)
• Sur les autres niveaux de compression, zlib-ng reste encore plus rapide

Par exemple :

• Au niveau de compression 6, zlib-rs est environ 6 % plus rapide que zlib-ng
• Au niveau de compression 9, zlib-rs est environ 13 % plus rapide que zlib-ng
• Mais aux niveaux de compression 1 à 4, zlib-ng garde l’avantage

Conclusion

• zlib-rs surpasse zlib-ng et zlib-chromium en performances de décompression
• Les performances de compression continuent de progresser, avec des gains significatifs sur les principaux niveaux de compression
• Peut être utilisé aussi bien dans des projets Rust que C
  • Rust → utiliser le flag zlib-rs dans le crate flate2
  • C → peut être utilisé après compilation sous forme de bibliothèque dynamique

[GN⁺]

Commentaires sur Hacker News

• En le regardant, on voit qu'il faut déjà connaître Rust

  • Je pensais que l'objectif de Rust était la sûreté, mais cette bibliothèque utilise beaucoup le mot-clé unsafe
  • Je me demande à partir de quel moment la différence entre C et Rust perd son sens
  • Avec de l'assembleur inline, les deux langages peuvent produire le même code machine
  • Je me demande si le compilateur Rust optimise mieux que le compilateur C

• « Plus rapide que C » se ramène à une autre conception, implémentation, algorithme, etc.

  • Cela peut être plus rapide qu'une implémentation existante, mais affirmer « plus rapide que C » paraît étrange

• zippy en Nim affirme être 1,5 à 2 fois plus rapide que zlib

  • Il existe aussi des zlib en C plus rapides que l'installation standard
  • zlib est aujourd'hui un peu daté, mais reste populaire
  • Il sert de base à de nouveaux formats davantage adaptés au parallélisme

• Je me demande si les performances de Rust sont liées à Rust lui-même, ou si c'est simplement plus optimisé que d'autres versions en C

  • Il existe des cas, comme le tri, où le C++ obtient de façon constante de meilleures performances que le C
  • Je me demande s'il existe quelque chose de similaire entre Rust et C

• Chromium utilise zlib à cause des algorithmes présents dans le standard

  • Choisir de meilleurs algorithmes peut donner de meilleures performances
  • Zstandard est plus rapide et compresse mieux
  • LZ4 est bien plus rapide, mais la taille n'est pas réduite autant

• Zstandard et les condensats blake3 sont autorisés

• Il serait plus exact de dire que Rust est aussi rapide que C

  • Cela reste une grande réussite

• Quelle bibliothèque compile le plus vite

  • Quelle bibliothèque a le moins de dépendances
  • Est-ce que leur taille est la même, et laquelle est la plus petite

• Les utilisateurs de Rust aiment comparer Rust et C, mais les utilisateurs de C comparent rarement C et Rust

• Quand on parle de langages systèmes compilés, le langage a très peu d'impact sur la vitesse

  • Une version optimisée peut facilement être plus de 100 fois plus rapide en contrôlant les allocations, en utilisant de bons schémas d'accès mémoire, ainsi que SIMD et le multithreading
  • De meilleurs accès mémoire à eux seuls peuvent déjà accélérer un programme de plus de 20 fois

• Cela signifie que l'implémentation est plus rapide que celle en C

  • Il n'existe pas vraiment de « plus rapide que C »