[gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)

[Daniel Cordey]

Frédéric,

> Le problème de tout algorithme, c’est sa reconnaissance par une base large d’utilisateurs, en dehors de nous-mêmes.

C'est surtout vrai dans le cas d'un algorithme de cryptage, beaucoup 
moins dans le cas d'un algorithme de compression dont le code est un 
logiciel libre et qui ne nécessite aucune configuration particulière.

> Compte tenu de la chute régulière du prix du Go, le taux de compression est aujourd’hui moins critique (sauf masses de données absolument considérables à archiver).

Oui... à condition de ne traiter toujours que la même quantité 
d'information. Or... c'est très loin d'être le cas. Dans les années 70, 
un disque de 400KB était déjà extraordinaire. Quelques années plus tard, 
on se pâmait devant un disque de 5 MB, puis ce fut 64MB, puis 500MB dans 
la deuxième moitié des années 80. Nous sommes alors entré dans le monde 
Giga, puis du Tera plus récemment et bientôt les disques de quelques 
centaines de TB seront monnaie courante. Le nouveau centre météo 
Européen (en Italie) prévoit de gérer 10PB de données par jour et on se 
trouve donc à parler d'Exabytes comme quelque chose de courant. 1 Exa 
c'est 10**18 et 1kilo c'est 10**3... entre les deux, 15 ordres de 
grandeur et je ne vois aucun signe de ralentissement. Je ne dis pas que 
c'est bien ou que l'on pourrait faire autrement, je me content de constater.

Donc, non, la compression va sans doute devenir un enjeu majeur et 
partout. J'ai développé un algorithme avec des taux de compression de 
97-98% pour des valeurs numériques et des situations particulières. 
C'est pour l'instant en Python et je dois encore faire une version avec 
Numpy ainsi qu'une version en C. Je mettrai ce logiciel en GPL V3 et 
tout le monde pourra l'utiliser sans restriction. Je dois aussi faire 
des tests sur d'autres types de données, mais j'ai bon espoir d'obtenir 
de meilleurs résultats que tout ce qui existe. En plus, la vitesse de 
décompression est imbatable et celle de compression est très bonne 
(aussi meilleur que bzip2/bzip). Il faut juste que je fasse des tests, 
que je finisse la version Numpy/C et que je mette tout ça sur un serveur 
git (sans doute un serveur perso), mais certainement pas sur github !

Si le gain es faible, cela n'intéresse personne, par contre les choses 
changent à partir d'un certain pourcentage. Ce qui signifie que 
l'intérêt est là à partir du moment où le jeu en vaut la chandelle.

> Ce que je retiens surtout, c’est la faible charge CPU. Je serai curieux de savoir si les mêmes résultats s’observent sur AMD, comme sur Intel. L’optimisation de l’algorithme pourrait être très lié à une implémentation du jeu d’instructions plutôt qu’à une autre. Simple hypothèse.


Ces codes son écrit en C, donc pas vraiment de révolution d'un CPU à 
l'autre. Ce que tu dis est vra à partir du moment où l'on peut utiliser 
des instructions assembleurs spécifiques, mais ce n'est pas le cas avec 
des compilateurs standards. Par contre, dans le domaine du traitement 
d'images et de vidéos, il existe des instructions accessible à partir de 
librairies spécifiques.

> Si l’application consiste au contraire à distribuer des fichiers à l’extérieur, la valeur d’usage de tout nouvel algorithme de compression me paraît très faible. A cause de la difficulté à le faire adopter par une nouvelle masse critique d’utilisateurs. A contrario, combien de fois voit-on des archives distribuées sous forme de .zip, « parce que ça peut-être ouvert sur n’importe quel ordinateur », n’est-ce pas ?

L'adoption se fait d'elle même. Mon expérience m'a montré que les gens 
s'intéresse à quelque choses de nouveau à partir du moment où le gain 
est de 20-30% supérieur. C'est vrai pour les performances des CPU, et 
c'est aussi vrai pour les logiciels.

dc