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 _______________________________________________ gull mailing list [email protected] https://forum.linux-gull.ch/mailman/listinfo/gull
