Арифметика потоковых архиваторов - 2
Исходный пост 2008-го года: https://mpd.livejournal.com/5302.html или https://dememax.dreamwidth.org/4730.html
Отправная мысль проста (в исходном посте это выражено по-другому):
Производительность и эффективное использование ресурсов (память, процессор, использование всех ядер процессора, место на диске, и т.д., и т.п.) - нас не интересует вообще, исключительно факт сжатия очевидного повторения в исходном потоке.
Размер: в прошлый раз я брал файл 8'677'260 байт, в этот раз (всё ж таки 12 лет прошло!) - 94'883'920 байт (некий ELF 64-bit LSB shared object, x86-64, dynamically linked, stripped).
В результате: получилось определить первый пункт с новым файлом только с помощью zstd.
Теперь подробнее.
Объединение файлов: выполнено с помощью «tar (GNU tar) 1.32» командой:
> tar cf two.tar filename.ext the_same_file.extполученный размер - 189'777'920 байт, накладные расходы: 189777920 - 94883920*2 = 10080 байт, что не так уж и много, относительно исходного файла - чуть больше одной сотой процента, можно пренебречь.
Rar: установленный в системе «RAR 5.90 Copyright (c) 1993-2020 Alexander Roshal 26 Mar 2020» - хоть и выдаёт в хелпе опцию «md[k,m,g] Dictionary size in KB, MB or GB», только не распознаёт её, пишет «ERROR: Unknown option: md10m». К автору не обращался, что за фигня - не хочу выяснять.
Остальные инструменты: «bzip2 version 1.0.6, 6-Sept-2010», «gzip 1.9», «zstd command line interface 64-bits v1.4.4».
Один файл
Если сжимать разными архиваторами один исходный файл, получаем:
rar: в зависимости от опции «m<0..5> Set compression level (0-store...3-default...5-maximal)»:
1: 43823050; 2: 40681104; 3: 40316157; 4: 40270861; 5: 40255324
bzip2: fast: 48144181; best: 44582638
gzip: fast: 51006034; best: 48020924
zstd: default: 44192751; long=31: 44132616
Промежуточный вывод: rar - лучший с 40'255'324, никто даже рядом не стоит.
Худший - gzip с 48'020'924.
Два файла в одном
Даю только лучшие результаты. Для rar - опция «-m5», для bzip2 и gzip - опция «--best», для zstd - опция «--long=31».
rar: 80'438'911
bzip2: 89'178'197
gzip: 96'043'097
zstd: 44'139'807
Окончательный вывод: только один zstd смог обнаружить повторение файла, два файла он сжал лучше, чем bzip2 сжал один файл (на том этапе bzip2 был не самый худший!).
Разница между сжатым одним и сжатыми двумя файлами для zstd ничтожная при таких размерах: 44139807 - 44132616 = 7191 (меньше накладных расходов tar'а)!
Как заставить *zip* увидеть дублирование такого размера с таким расстоянием - не знаю, похоже, что никак.
Rar - как сказано выше, хоть и имеет соответствующую опцию, но не распознаёт её, и в результате суммарно сжал два файла по-отдельности. (
| Комментировать в Dreamwidth)
Отправная мысль проста (в исходном посте это выражено по-другому):
- Архиватор должен найти повторяющиеся последовательности.
- А что, если они очень далеко?
- А что, если очень велики?
Производительность и эффективное использование ресурсов (память, процессор, использование всех ядер процессора, место на диске, и т.д., и т.п.) - нас не интересует вообще, исключительно факт сжатия очевидного повторения в исходном потоке.
Размер: в прошлый раз я брал файл 8'677'260 байт, в этот раз (всё ж таки 12 лет прошло!) - 94'883'920 байт (некий ELF 64-bit LSB shared object, x86-64, dynamically linked, stripped).
В результате: получилось определить первый пункт с новым файлом только с помощью zstd.
Теперь подробнее.
Объединение файлов: выполнено с помощью «tar (GNU tar) 1.32» командой:
> tar cf two.tar filename.ext the_same_file.extполученный размер - 189'777'920 байт, накладные расходы: 189777920 - 94883920*2 = 10080 байт, что не так уж и много, относительно исходного файла - чуть больше одной сотой процента, можно пренебречь.
Rar: установленный в системе «RAR 5.90 Copyright (c) 1993-2020 Alexander Roshal 26 Mar 2020» - хоть и выдаёт в хелпе опцию «md[k,m,g] Dictionary size in KB, MB or GB», только не распознаёт её, пишет «ERROR: Unknown option: md10m». К автору не обращался, что за фигня - не хочу выяснять.
Остальные инструменты: «bzip2 version 1.0.6, 6-Sept-2010», «gzip 1.9», «zstd command line interface 64-bits v1.4.4».
Один файл
Если сжимать разными архиваторами один исходный файл, получаем:
rar: в зависимости от опции «m<0..5> Set compression level (0-store...3-default...5-maximal)»:
1: 43823050; 2: 40681104; 3: 40316157; 4: 40270861; 5: 40255324
bzip2: fast: 48144181; best: 44582638
gzip: fast: 51006034; best: 48020924
zstd: default: 44192751; long=31: 44132616
Промежуточный вывод: rar - лучший с 40'255'324, никто даже рядом не стоит.
Худший - gzip с 48'020'924.
Два файла в одном
Даю только лучшие результаты. Для rar - опция «-m5», для bzip2 и gzip - опция «--best», для zstd - опция «--long=31».
rar: 80'438'911
bzip2: 89'178'197
gzip: 96'043'097
zstd: 44'139'807
Окончательный вывод: только один zstd смог обнаружить повторение файла, два файла он сжал лучше, чем bzip2 сжал один файл (на том этапе bzip2 был не самый худший!).
Разница между сжатым одним и сжатыми двумя файлами для zstd ничтожная при таких размерах: 44139807 - 44132616 = 7191 (меньше накладных расходов tar'а)!
Как заставить *zip* увидеть дублирование такого размера с таким расстоянием - не знаю, похоже, что никак.
Rar - как сказано выше, хоть и имеет соответствующую опцию, но не распознаёт её, и в результате суммарно сжал два файла по-отдельности. (
| Комментировать в Dreamwidth)