Komprese i přehrávání MP3, FLAC, Vorbis, Opus a Monkey Audio zrychluje díky novému CRC algoritmu

Jeden by řekl, že zrychlení nějakého blbého CRC16 nemůže tak moc ovlivnit spotřebu procesoru u procesu, kde jsou kvanta výpočtů ohledně zvuku. Ta původní implementace musela být pořádná hrůza.

crc64 (no table)
CRC = ee43263b0a2b6c60
7.142642 seconds at 102.30 MB/s (24.18 CPU cycles per byte)

crc64 (lookup table)
CRC = ee43263b0a2b6c60
1.777920 seconds at 411.00 MB/s (6.02 CPU cycles per byte)

crc64speed
CRC = ee43263b0a2b6c60
0.448819 seconds at 1628.09 MB/s (1.52 CPU cycles per byte)

https://github.com/mattsta/crcspeed/blob/master/README.md

https://github.com/mattsta/crcspeed/blob/master/crcspeed.c#L32

/* Fill in a CRC constants table. */
void crcspeed64little_init(crcfn64 crcfn, uint64_t table[8][256]) {
    uint64_t crc;

    /* generate CRCs for all single byte sequences */
    for (int n = 0; n < 256; n++) {
        table[0][n] = crcfn(0, &n, 1);
    }

    /* generate nested CRC table for future slice-by-8 lookup */
    for (int n = 0; n < 256; n++) {
        crc = table[0][n];
        for (int k = 1; k < 8; k++) {
            crc = table[0][crc & 0xff] ^ (crc >> 8);
            table[k][n] = crc;
        }
    }
}

Pre lorem ipsum z unit testu to bude asi signifikantny cas, ale pre 700MB+ subor z vyssie uvedeneho testu to nebude nic strasne.

Jak?