La compression c'est tout le contraire du bas niveau. C'est justement un truc purement algorithmique et indépendant du matériel.
Si le problème était résolu, on aurait un algo super efficace de la mort qui tue et il serait implémenté par le premier disque dur/ssd/carte sd venue (qui ne voudrait pas faire x2 sur sa capacité de stockage affichée?). A priori ce n'est pas le cas.
En télécom, on utilise la compression (et ça fait partie de la formation, en tout cas y'a 10 ans quand j'étais étudiant?) mais on a des problématiques qui font qu'on ne peut pas forcément atteindre les limites théoriques: contraintes de temps réel, de limitations matérielles (taille de la mémoire disponible) et de latence. En gros, on ne peut pas attendre d'avoir 4Go de données à envoyer pour les compresser de façon optimale, on est obligés de traiter ça en flux au fur et à mesure que les données arrivent.
Après, oui, y'a plein de cas ou il n'y a pas besoin de compression à proprement parler (ça peut être suffisant d'utiliser un format approprié pour les données, ou il y aura déjà peu de redondance), ou alors, on peut utiliser un algorithme existant qui fonctionnera très bien pour les besoins identifiés. Ou bien on peut tomber sur des cas tordus, par exemple dans Haiku on a un gestionnaire de paquets qui a besoin de faire des accès aléatoires au contenu du paquet. Actuellement l'approche utilisée est de découper le paquet en blocs de 4K et de compresser chaque bloc séparément, et c'est pas hyper efficace. Y'a probablement mieux comme algo de compression qui permet de décompresser une partie aléatoire du flux (sans décompresser tout ce qu'il y a avant), non? Des suggestions?
[^] # Re: Comment ça perdu?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 5.
La compression c'est tout le contraire du bas niveau. C'est justement un truc purement algorithmique et indépendant du matériel.
Si le problème était résolu, on aurait un algo super efficace de la mort qui tue et il serait implémenté par le premier disque dur/ssd/carte sd venue (qui ne voudrait pas faire x2 sur sa capacité de stockage affichée?). A priori ce n'est pas le cas.
En télécom, on utilise la compression (et ça fait partie de la formation, en tout cas y'a 10 ans quand j'étais étudiant?) mais on a des problématiques qui font qu'on ne peut pas forcément atteindre les limites théoriques: contraintes de temps réel, de limitations matérielles (taille de la mémoire disponible) et de latence. En gros, on ne peut pas attendre d'avoir 4Go de données à envoyer pour les compresser de façon optimale, on est obligés de traiter ça en flux au fur et à mesure que les données arrivent.
Après, oui, y'a plein de cas ou il n'y a pas besoin de compression à proprement parler (ça peut être suffisant d'utiliser un format approprié pour les données, ou il y aura déjà peu de redondance), ou alors, on peut utiliser un algorithme existant qui fonctionnera très bien pour les besoins identifiés. Ou bien on peut tomber sur des cas tordus, par exemple dans Haiku on a un gestionnaire de paquets qui a besoin de faire des accès aléatoires au contenu du paquet. Actuellement l'approche utilisée est de découper le paquet en blocs de 4K et de compresser chaque bloc séparément, et c'est pas hyper efficace. Y'a probablement mieux comme algo de compression qui permet de décompresser une partie aléatoire du flux (sans décompresser tout ce qu'il y a avant), non? Des suggestions?