Les pièges invisibles de l'arithmetic coding : pourquoi votre compression gaspille des bits

Vous avez déjà codé un arithmetic coding ? Vous vous êtes senti fier. Cet algo mappe les séquences de bits sur des intervalles probabilistes avec élégance. Mais attention : la plupart des implémentations basiques trouvées en ligne sous-performent en silence.

Pas de souci de vitesse CPU ici (même si c'est important). On parle ratio de compression. C'est le but de l'entropy coding.

L'implémentation "classique" qui trompe

Vous avez vu ça partout dans les tutos :

let mut left: u32 = 0;
let mut right: u32 = u32::MAX;

fn encode_bit(bit: bool, probability: f32) {
    let mid = left + ((right - left) as f32 * probability) as u32;
    if !bit {
        right = mid;
    } else {
        left = mid + 1;
    }
    
    while left >> 24 == right >> 24 {
        output_byte((left >> 24) as u8);
        left <<= 8;
        right = (right << 8) | 0xff;
    }
}

Logique, non ? Un intervalle [left, right] se rétrécit à chaque bit selon sa proba. Quand un byte est sûr, on l'émet et on libère de la précision.

Le hic ? Une asymétrie subtile qui n'existe pas en théorie mathématique.

La faute aux frontières de bytes

Dans l'idéal infini, tous les intervalles de même taille se comportent pareil. Pas avec nos 32 bits.

Exemples :

1. Un intervalle à left = 0 ne descend jamais sous 2^24 bits.
2. Un à left = 2^31 - 1 peut rétrécir à 2 bits seulement.

Pourquoi ? La condition left >> 24 == right >> 24 dépend de la position, pas de la taille.

Si l'intervalle chevauche une frontière de byte, comme [2^31 - 1, 2^31], il devient minuscule. Les probas se quantifient mal. Votre bit à 0.95 proba passe pour 50/50. Résultat : plus de bits émis que prévu par l'entropie.

Le décodeur plus compliqué qu'il n'y paraît

Côté décodeur, un autre souci :

fn decode_bit(probability: f32) -> bool {
    let mid = left + ((right - left) as f32 * probability) as u32;
    if x <= mid {
        right = mid;
        bit = false;
    } else {
        left = mid + 1;
        bit = true;
    }
    
    while left >> 24 == right >> 24 {
        left <<= 8;
        right = (right << 8) | 0xff;
        x = (x << 8) | (bytes.next().unwrap() as u32);
    }
    
    bit
}

Il gère left, right et x (la valeur codée). En maths, deux infos suffisent : taille (right - left) et position relative (x - left).

Mais la boucle while force à tracker les absolus pour vérifier les bytes hauts. Ça couple précision et position :

• Plus de registres utilisés.
• Moins d'optimisations compilateur.
• Code dur à suivre.

Inutile, car on devrait se focaliser sur la taille seule.

La solution

Changez la gestion de précision. Émettez les bytes sur taille d'intervalle (indépendant de la position), pas sur bytes identiques (dépendant).

Ça bouleverse encode/decode. Mais gain : compression optimale, décodeur simplifié et rapide.

Pourquoi ça compte chez NameOcean

Chez NameOcean, on aide les devs à builder des apps AI avec Vibe Hosting ou des systèmes ultra-optimisés. Que ce soit pour stocker en cloud, alléger des API ou traiter des datasets massifs, maîtriser la compression est clé.

Beaucoup reprennent des libs sans en sonder les limites. Un gain de 5-10% en ratio ? Ça pèse sur des petabytes ou des millions de requêtes.

Leçon générale : les implémentations "standard" cachent des failles. Creusez. Vérifiez les hypothèses. Les top ingénieurs décortiquent les cas limites, pas juste copient les algos.

Pour des apps cloud performantes, chaque choix d'infra s'additionne. Un petit fix algo, multiplié par des millions de calls, explose les perfs. Besoin d'optimiser votre stack ? Les détails font la différence.