LINUX.ORG.RU

ZXC 0.9.0

 , , , ,


1

2

Состоялся выпуск 0.9.0 библиотеки и кроссплатформенной консольной утилиты ZXC (github.com), реализующих высокопроизводительное многопоточное асимметричное сжатие без потерь и оптимизированное для игровых ресурсов, прошивок и пакетов приложений. Формат разработан по принципу «один раз записать, многократно читать» (WORM).

В отличие от таких кодеков, как LZ4, ZXC жертвует скоростью сжатия ради максимальной пропускной способности при распаковке.

Декларируется скорость распаковки на 40%+ выше, чем у LZ4 на Apple Silicon, на 25%+ выше на Google Axion (ARM64) и на 5%+ выше на x86_64, при этом во всех случаях обеспечивается более высокий коэффициент сжатия.

В этом выпуске представлен API многократно используемого контекста, возможность настройки размера блоков, полное справочное руководство по API и ABI, а также несколько исправлений, связанных с безопасностью, в том числе устранение уязвимости переполнения буфера в куче, обнаруженной в ходе фаззинга модуля сжатия.

Данный релиз содержит изменения, нарушающие ABI, поэтому SOVERSION увеличена до 2.

Проект написан на языке C и распространяется по лицензии BSD 3.

Подробности
  • Изменения, приводящие к несовместимости:
    • SOVERSION 2: Версия ABI библиотеки была увеличена. Бинарные файлы, скомпилированные под SOVERSION 1, необходимо перекомпилировать.
    • Структуры опций: функции zxc_compress() и zxc_decompress() теперь принимают zxc_compress_opts_t* и zxc_decompress_opts_t* вместо позиционных параметров. Для поведения по умолчанию передавайте NULL.
    • Кодирование размера блока: Заголовок файла теперь хранит размер блока в виде экспоненты log2 [12..21] вместо прежнего кодирования с двумя шкалами. Старое значение 64 по-прежнему принимается для обратной совместимости.
  • Новые возможности:
    • Непрозрачные контексты сжатия и распаковки, выделяемые в куче, которые устраняют накладные расходы на выделение памяти при каждом вызове; идеально подходят для плагинов файловой системы (squashfs, dwarfs) и пакетной обработки:
      • zxc_create_cctx(), zxc_free_cctx() и zxc_compress_cctx() для компресии;
      • zxc_create_dctx(), zxc_free_dctx() и zxc_decompress_dctx() для декомпресии;
      • внутренние буферы перераспределяются только в том случае, если между вызовами изменяется значение block_size или level.
  • Настраиваемые размеры блоков:
    • размер блока теперь можно настроить с помощью поля block_size в структуре zxc_compress_opts_t;
    • допустимый диапазон: от 4 КБ до 2 МБ (степень двойки);
    • по умолчанию значение остается 256 КБ;
    • в консольную утилиту zxc добавлен новый параметр --block-size (или -B) с поддержкой суффиксов единиц измерения (4K, 1M или 4KB, 1MB и т. д.).
  • Быстрая прямая декомпрессия:
    • когда буфер назначения достаточно заполнен, при распаковке пропускается промежуточное копирование в рабочий буфер, что позволяет снизить нагрузку на память и сократить задержку.
  • Безопасность и стабильность:
    • исправлено переполнение буфера кучи в zxc_bitpack_stream_32: цикл упаковки мог записывать до 4 байтов за пределы выходного буфера, если последнее упакованное значение пересекало границу байта;
    • исправлена проверка потока при распаковке (в zxc_decompress.c): добавлена проверка, гарантирующая, что размер потока последовательностей достаточен для заявленного количества последовательностей, что предотвращает чтение за пределами допустимого диапазона.
    • проверка размера блока: теперь в функциях zxc_cctx_init() и zxc_read_file_header() выполняется проверка, что размеры блоков находятся в диапазоне [ZXC_BLOCK_SIZE_MIN, ZXC_BLOCK_SIZE_MAX] и они являются степенями двойки;
    • совместимость с C++: все публичные заголовочные файлы теперь содержат защитные конструкции extern "C" для беспроблемного использования в C++;
    • хранение корпуса тестов для фаззинг-тестирования: настроено постоянное хранилище корпуса для ClusterFuzzLite CI.
  • Документация:
    • docs/API.md: новый исчерпывающий справочник по API и ABI, в котором описаны все 21 экспортируемый символ, определения типов, стратегия видимости, версионирование ABI, гарантии потокобезопасности и шаблоны обработки ошибок;
    • обновлены man и файл README с инструкциями по установке и информацией о статусе пакетов (vcpkg, Conan, Homebrew);
    • обновлён файл docs/FORMAT.md с описанием кодирования размера блока на основе экспоненты.
  • Обновлены врапперы для Python, Rust и Node.js.

>>> Подробности на GitHub

★★★★★

Проверено: CrX ()
Последнее исправление: CrX (всего исправлений: 2)

Две недели всего прошло же.

Bfgeshka ★★★★★
()

На словах ты ZXC, а на деле - QWE

Logopeft ★★
()

файловой системы на fuse для него нет?

demidrol ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Это не важно, т.к. данная новость по множеству параметров на 146% лучше многих и многих других.

deep-purple ★★★★★
()

Я правильно понял, что эта штука позволяет делать сжатые файловые системы типа того же squashfs? Или это что-=то еще?

gns ★★★★★
()
Ответ на: комментарий от gns

что эта штука позволяет делать сжатые файловые системы типа того же squashfs?

Нет, это просто кодек. Но автор форкнул несколько *fs, наверное планирует добавить в них поддержку zxc.

dataman ★★★★★
() автор топика
Ответ на: комментарий от andreyu

Есть сравнение с lz4hc -12 на двух графиках.

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

наверное планирует добавить в них поддержку zxc.

@gns, https://github.com/hellobertrand/zxc/issues/113#issuecomment-4019668515:

I have implemented a prototype in the add-zxc branch of my fork: https://github.com/hellobertrand/squashfs-tools/tree/add-zxc), and I have conducted a series of benchmarks across three major architectures (Apple M3, AMD Turin, and Google Axion) using different datasets to evaluate zxc against lz4 within squashfs. I used squashfs-tools/squashfs-tools/bench.sh on 3 differents corpus: some logs (374MB), random data (not compressible 257MB) and linux kernel (1.7GB).

ArchitectureDatasetAlgorithmComp. TimeDecomp. Time (Best)Archive SizeRatio (%)
Apple M3 (arm4)linuxlz45.371s6.949s415M23.9%
zxc4.868s6.968s374M21.5%
Apple M3 (arm64)logslz40.199s0.223s309M82.4%
zxc0.941s0.093s296M78.9%
Apple M3 (arm64)randomlz40.114s0.110s257M100.0%
zxc0.089s0.069s257M100.0%
AMD Turin (x86\_64)linuxlz42.561s1.003s415M23.9%
zxc5.248s0.993s374M21.5%
AMD Turin (x86\_64)logslz40.463s0.165s309M82.4%
zxc2.366s0.157s296M78.9%
AMD Turin (x86\_64)randomlz40.141s0.086s257M100.0%
zxc0.173s0.087s257M100.0%
Google Axion (arm64)linuxlz412.404s2.216s415M23.9%
zxc10.994s2.036s374M21.5%
Google Axion (arm64)logslz41.856s0.249s309M82.4%
zxc3.797s0.235s296M78.9%
Google Axion (arm64)randomlz41.527s0.136s257M100.0%
zxc0.273s0.129s257M100.0%

Там, кстати, мейнтейнер Debian активно участвует, и уже добавил пакет zxc в Debian/sid.

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

Спасибо, полезно может быть.

gns ★★★★★
()

Раз тут собрались такие профи по архивам, то задам вопрос: а что есть для пожатия текста (xml тот же самый или json) в холодное хранилище? Т.е. когда жать я готов хоть неделю, главное чтоб жалось сильно и читалось быстро. Хорошо если можно не 1 файл в архив класть, а 100500 и скорость извлечения любого из них одинаковая. Из того что я знаю лучшее - non solid 7z архив с lzma2 компрессией. Но может есть что-то лучше? И как этот самый zxc не с бинариками под который он заточен?

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Т.е. когда жать я готов хоть неделю, главное чтоб жалось сильно Например, человек уже давно улучшает zpaq: https://github.com/fcorbelli/zpaqfranz.
Но этот форк уже не просто архиватор.

Он даже запилил GUI на Паскале: https://github.com/fcorbelli/catpaq (но я не пробовал).

Небыстренько сравнил с файлом выше:

7z a -mx9 ucd.7z ucd.all.flat.xml
zpaqfranz a ucd1.zpaq ucd.all.flat.xml -m1
zpaqfranz a ucd2.zpaq ucd.all.flat.xml -m2
zpaqfranz a ucd3.zpaq ucd.all.flat.xml -m3
zpaqfranz a ucd4.zpaq ucd.all.flat.xml -m4
zpaqfranz a ucd5.zpaq ucd.all.flat.xml -m5

$ ls ucd.* -gG:

-rw-rw-r-- 1 10459182 Mar 17 21:13 ucd1.zpaq
-rw-rw-r-- 1  9291058 Mar 17 21:07 ucd2.zpaq
-rw-rw-r-- 1  7802532 Mar 17 21:08 ucd3.zpaq
-rw-rw-r-- 1  4078305 Mar 17 21:10 ucd4.zpaq
-rw-rw-r-- 1  3073476 Mar 17 20:54 ucd5.zpaq
-rw-rw-r-- 1  6483639 Mar 17 20:45 ucd.7z

и читалось быстро.

С этим не очень, но может быть нужно с опциями поиграть.

dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

Заведу новую тему наверное. Там у меня много всего накопилось.

peregrine ★★★★★
()
Ответ на: комментарий от andreyu

как он в сравнении с LZ4 HC?

Автор сделал PR#267 в lzbench.

$ lzbench -o1 -ezstd,1,3,5/lz4/lz4hc,1,3,5/zxc,1,3,5 ucd.all.flat.xml:

lzbench 2.2.1 | GCC 15.2.0 | 64-bit Linux | Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz

Compressor nameCompressionDecompress.Compr. sizeRatioFilename
zstd 1.5.7 -11245 MB/s3068 MB/s94857844.15ucd.all.flat.xml
zstd 1.5.7 -3821 MB/s2889 MB/s91578614.00ucd.all.flat.xml
zstd 1.5.7 -5356 MB/s2850 MB/s85895343.75ucd.all.flat.xml
lz4 1.10.01584 MB/s5209 MB/s156592696.85ucd.all.flat.xml
lz4hc 1.10.0 -11163 MB/s5364 MB/s142552096.23ucd.all.flat.xml
lz4hc 1.10.0 -3298 MB/s5512 MB/s114357775.00ucd.all.flat.xml
lz4hc 1.10.0 -5230 MB/s5525 MB/s111329534.87ucd.all.flat.xml
zxc 0.9.1 -11327 MB/s5555 MB/s224148469.80ucd.all.flat.xml
zxc 0.9.1 -3646 MB/s5282 MB/s148854076.51ucd.all.flat.xml
zxc 0.9.1 -5342 MB/s5357 MB/s134157655.86ucd.all.flat.xml

$ lzbench -o1 -T4 -ezstd,1,3,5/lz4/lz4hc,1,3,5/zxc,1,3,5 ucd.all.flat.xml:

Compressor nameC,D ThreadsCompressionDecompress.Compr. sizeRatioFilename
zstd 1.5.7 -14, 42735 MB/s5626 MB/s94952104.15ucd.all.flat.xml
zstd 1.5.7 -34, 41429 MB/s4537 MB/s91610894.00ucd.all.flat.xml
zstd 1.5.7 -54, 4695 MB/s4517 MB/s85920753.76ucd.all.flat.xml
lz4 1.10.04, 43836 MB/s6310 MB/s156627886.85ucd.all.flat.xml
lz4hc 1.10.0 -14, 42380 MB/s6422 MB/s142592166.23ucd.all.flat.xml
lz4hc 1.10.0 -34, 4725 MB/s6522 MB/s114404035.00ucd.all.flat.xml
lz4hc 1.10.0 -54, 4514 MB/s6430 MB/s111376164.87ucd.all.flat.xml
zxc 0.9.1 -14, 42836 MB/s6325 MB/s228585419.99ucd.all.flat.xml
zxc 0.9.1 -34, 41119 MB/s6267 MB/s148359986.49ucd.all.flat.xml
zxc 0.9.1 -54, 4631 MB/s6405 MB/s134159985.86ucd.all.flat.xml
dataman ★★★★★
() автор топика
Ответ на: комментарий от dataman

Ну по этим результатам, их заявления - брехня, и zxc не нужен )
И это на тексте! На ресурсах будет скорее всего ещё хуже. Там как раз zstd с малым уровнем должен жать лучше всех, не сильно снижая скорости.

GAMer ★★★★★
()
Ответ на: комментарий от dataman

Там же в обоих случаях что-то из семейства lzss, они не могут отличаться по производительности на 40% при распаковке. Там элементарнейший алгоритм, где для ощутимой разницы нужно накосячить ну очень серьёзно.

GAMer ★★★★★
()
Ответ на: комментарий от dataman

Спасибо, значит смело можно оставаться с lz4hc, как наиболее оптимальным и стабильным.

В моем случае, lz4hc умудряется очень неплохо ужать текстуры в формате astc с любым размером блока.

andreyu ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.