Différence: LZ77 vs LZ4 vs LZ4HC (algorithmes de compression)?
Je comprends les algorithmes LZ77 et LZ78. J'ai lu sur LZ4 ici et ici et trouvé code pour cela .
Ces liens décrivaient le format de bloc LZ4. Mais ce serait génial si quelqu'un pouvait expliquer (ou me diriger vers une ressource expliquant):
- En quoi LZ4 est différent de LZ77?
- En quoi le LZ4HC est-il différent du LZ4?
- Quelle idée rend l'algorithme LZ4HC si rapide?
LZ4 est conçu pour compresser rapidement, à des centaines de Mo/s par cœur. Il convient aux applications où vous souhaitez une compression très bon marché: par exemple, vous essayez de rendre un format réseau ou sur disque plus compact, mais vous ne pouvez pas vous permettre de consacrer beaucoup de temps processeur à la compression. C'est dans une famille avec, par exemple, snappy et LZO .
Le point de comparaison naturel est zlib algorithme DEFLATE , qui utilise LZ77 et codage Huffman et est utilisé dans gzip, les formats .Zip et .PNG, et trop d'autres endroits pour compter.
Ces compresseurs rapides diffèrent parce que:
- Ils utilisent un code de détection de répétition plus rapide (souvent un simple table de hachage sans détection de collision) mais ne recherche pas parmi plusieurs correspondances possibles la meilleure (ce qui prendrait du temps mais entraînerait une compression plus élevée), et ne trouve pas de courtes correspondances.
- Ils essaient seulement de compresser les répétitions en entrée - ils n'essaient pas de tirer parti de certains octets qui sont plus courants que d'autres.
- Étroitement liés à 2, ils génèrent des octets de sortie à la fois, pas des bits; autoriser les codes fraction de octet permettrait parfois plus de compression, mais nécessiterait plus d'opérations CPU (potentiellement le décalage de bits et le masquage et la ramification) pour coder et décoder.
- Beaucoup de travaux pratiques ont été effectués pour rendre leurs implémentations rapides sur les processeurs modernes.
Par comparaison, DEFLATE obtient une meilleure compression mais compresse et décompresse plus lentement, et des algorithmes de compression élevée comme LZMA , bzip2 , LZHAM , ou brotli ont tendance à prendre encore plus de temps (bien que Brotli à ses paramètres plus rapides peut rivaliser avec zlib ) . Il y a beaucoup de variations entre les algorithmes à haute compression, mais généralement, ils ont tendance à capturer les redondances sur de plus longues distances, à tirer davantage parti du contexte pour déterminer quels octets sont probables et à utiliser des moyens plus compacts mais plus lents pour exprimer leurs résultats en bits.
Le LZ4HC est une variante "haute compression" du LZ4 qui, je crois, modifie le point 1 ci-dessus - le compresseur trouve plus d'une correspondance entre les données actuelles et passées et recherche la meilleure correspondance pour s'assurer que la sortie est petite. Cela améliore le taux de compression mais réduit la vitesse de compression par rapport à LZ4. La vitesse de décompression n'est pas affectée, cependant, donc si vous compressez une fois et décompressez plusieurs fois et que vous voulez surtout une décompression extrêmement bon marché, le LZ4HC aurait du sens.
Notez que même un compresseur rapide peut ne pas permettre à un cœur de saturer une grande quantité de bande passante, comme celle fournie par les SSD ou les liaisons rapides dans le centre de données. Il existe des compresseurs encore plus rapides avec des ratios inférieurs, parfois utilisés pour emballer temporairement les données dans la RAM . WKdm et Densité sont deux de ces compresseurs; un trait qu'ils partagent est d'agir sur des mots machine de 4 octets d'entrée à la fois plutôt que sur des octets individuels. Parfois, du matériel spécialisé peut atteindre une compression très rapide, comme dans puces Exynos de Samsung ou technologie QuickAssist d'Intel .
Si vous souhaitez compresser plus que LZ4 mais avec moins de temps CPU que de dégonfler, l'auteur de LZ4 (Yann Collet) a écrit une bibliothèque appelée Zstd ; à sa version stable, Facebook a posté comment ils l'utilisent . Il utilise machines à états finis , pas des codes Huffman, pour le codage entropique; Je ne suis pas un expert dans ce domaine, mais au moins l'algorithme est décrit en détail dans un RFC . Les modes les plus rapides de zstd approchent maintenant LZ4 en rapport et en vitesse. Apple a écrit lzfse sur des principes similaires. Il y a quelques années, Google a publié une bibliothèque appelée gipfeli , même si elle ne semblait pas choisir Il existe également des projets visant à une compression plus rapide au format Zlib, comme SLZ et correctifs pour zlib par CloudFlare et Intel =.
Par rapport aux compresseurs les plus rapides, ces packers "moyens" ajoutent une forme de encodage entropique , c'est-à-dire qu'ils profitent de la façon dont certains octets sont plus courants que les autres et (en fait) mettent moins de bits dans la sortie pour les valeurs d'octets les plus courantes.
Si la latence plutôt que le temps CPU total est votre principale préoccupation et que vous compressez un long flux, il existe des outils pour effectuer la compression en parallèle, comme pigz et le -T option de filetage vers l'outil de ligne de commande zstd. (Il y a divers expérimental packers là-bas aussi, mais ils existent plus pour repousser les limites de vitesse ou de densité, plutôt que pour une utilisation aujourd'hui.)
Donc, en général, vous avez un assez bon éventail de compresseurs alternatifs pour différentes applications: LZ4 (ou même des compresseurs de mémoire plus faibles) pour la compression en temps réel, DEFLATE comme l'ancien standard pour la compression équilibrée et Zstd comme une nouvelle alternative développée activement, et brotli et d'autres pour une compression élevée. Lorsque vous passez de LZ4 à DEFLATE en passant par brotli, vous vous concentrez sur plus d'efforts pour prévoir et coder les données et obtenir plus de compression au prix d'une certaine vitesse.
Soit dit en passant, les algorithmes comme brotli et zstd peuvent généralement surpasser gzip - mieux compresser à une vitesse donnée, ou obtenir la même compression plus rapidement - mais ce n'est pas en fait parce que zlib a fait quelque chose de mal . Au contraire, zlib a été publié en 1995 et a fait de bons choix pour le matériel de l'époque: par exemple, sa fenêtre d'historique de 32 Ko avait du sens lorsque RAM cost plus de 3000 fois Les processeurs d'aujourd'hui tordent également l'équilibre entre les opérations bon marché/coûteuses, par exemple les branches difficiles à prévoir sont plus importantes aujourd'hui et faire beaucoup d'arithmétique est relativement moins cher.