LINUX.ORG.RU

ZXC 0.8.0 и 0.8.1

 , zxc, , ,


2

3

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

Декларируется на 40%+ более быстрая распаковка, чем LZ4 на ARM64, с лучшими коэффициентами сжатия.

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

Список изменений:

  • Версия формата теперь 5, «ломающая» совместимость:
    • Реализовано смещение LZ (+1) на уровне формата для устранения потенциальных векторов атаки с нулевым смещением.
    • Контрольные суммы заголовков теперь используют алгоритм Marsaglia xorshift.
  • Новая стратегия хеширования LZ77 и оптимизация конфигурации хеш-таблиц обеспечивают значительное повышение производительности на различных архитектурах, особенно при высоких уровнях сжатия.
  • Значительные улучшения для уровней сжатия 3–5, демонстрирующие увеличение скорости сжатия на 33–43 % как на архитектурах x86_64, так и на ARM64.
  • Заметные улучшения для более быстрых уровней сжатия (1 и 2), с увеличением скорости на 10-18% на x86_64 и ~8-10% на ARM64.
  • Переработана обработка и коды ошибок. Python-враппер теперь предоставляет доступ к этим константам ошибок C для обеспечения улучшенной и нативной отчетности об ошибках.
  • Размер ZXC_BLOCK_SIZE больше не ограничивается 1 МБ. Формат файла ZXC теперь официально поддерживает размеры блоков до 8 МБ.
  • В консольную утилиту добавлен режим обработки нескольких файлов: опция -m (или --multiple) позволяет обрабатывать несколько входных файлов одной командой. Каждый файл обрабатывается независимо, а имена выходных файлов автоматически производятся от входных (например, файл file.txt сжимается в file.txt.xc, файл file.txt.xc распаковывается в file.txt).
  • В консольную утилиту также добавлен режим рекурсивной обработки директорий: опция -r (или --recursive) позволяет обрабатывать все файлы в указанных директориях и их поддиректориях.
  • Другие улучшения (документация, тестирование) и исправления ошибок.
  • В версии 0.8.1 исправлена только генерация динамической библиотеки libzxc.so.1 для сохранения возможности использования прежних версий библиотеки.

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

★★★★★

Проверено: CrX ()
Последнее исправление: dataman (всего исправлений: 3)
Ответ на: комментарий от BydymTydym

Библиотека весьма спецефичная, сделать биндинг для rust не проблема. А вот если бы это был растовый крейт - уже сложнее было бы использовать из других языков

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

сделать биндинг для rust не проблема

Уже входит в комплект. :)

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

Я ж новость обсуждаю а не гитхаб. Думаю, тут большинство (как и я) знают что такое симметричное/асимметричное шифрование, а вот про сжатие вряд ли, можно было и уточнить.

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

Можно в код глянуть. Можно на глазок по соотношению времени сжатия и разжатия, если соотношение близко к единице, то симметричное.

imul ★★★★★
()

интересно если слать сжатые данным алгоритмом udp пакеты groupcast'ом как в dota 2 между server и 10 clients как это сильно отразится на gameplay?

doomer
()
Последнее исправление: doomer (всего исправлений: 1)
Ответ на: комментарий от mittorn

скорость сжатия бы ему ещё повыше…

Точнее, многопоточность не помешает. Вот сэмь-зэ жмет на всех ядрах, можно такую опцию задать. У zxc есть такое?

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

У zxc есть такое?

«Number of threads» на скриншоте.

dataman ★★★★★
() автор топика

Декларируется на 40%+ более быстрая распаковка, чем LZ4 на ARM64

Засомневался, возможно ли такое вообще. Как понял, скорее всего сказывается раздельное хранение потоков литералов, смещений и прочей хрени. Но 40% что-то всё равно многовато.

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

Засомневался, возможно ли такое вообще.

В lzbench добавили zxc, хотя пока и не эту версию. Можно попробовать обновить и проверить.

dataman ★★★★★
() автор топика

Ещё не пробовал на практике, но API выглядит многообещающе. Нравится возможность работать в стримах FILE * в частности.

Не нравится требование CMake, но проект простой и можно будет свою сборку подсунуть без особых болей, думаю.

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

В моёп юзкейсе многопоточность вряд ли будет полезна, но в принципе что мешает разбить входные данные на блоки и пускать в разные потоки?

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

Не на Rust? Надо срочно переписать!

fix

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

Ниче, я тут ядро Linux постепенно на Rust начал переписывать, так что скоро им ничего не останется, как сишное запретить.

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

Казалось, все архиваторы так и работают. Файл 100 мегабайт делят на мелкие части, а 100 файлов по 10 килобайт возьмут за один блок

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

Мне надо сжимать текстуры в реальном времени. Сначала сжимаю блочным алгоритмом на GPU, потом уже lossless алгоритмом на cpu. zxc, кажется, как раз под такие задачи должен подходить

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

Это используется для стриминга изображения на vr шлем. Часть коэффициентов DWT, где не нужна высокая точность шлётся по схеме BC1+lossless

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

@GAMer

Можно попробовать обновить и проверить.

Обновил до 0.8.3. Тестировал с 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 name I_Threads Compress. Decompress. Compr. size  Ratio Filename
brotli 1.2.0 -1         1   981 MB/s  1218 MB/s    10831984   4.74 ucd.all.flat.xml
brotli 1.2.0 -2         1   319 MB/s  1490 MB/s     8932549   3.90 ucd.all.flat.xml
brotli 1.2.0 -3         1   308 MB/s  1565 MB/s     8818494   3.85 ucd.all.flat.xml
brotli 1.2.0 -4         1   177 MB/s  1672 MB/s     8396656   3.67 ucd.all.flat.xml
brotli 1.2.0 -5         1  97.2 MB/s  1656 MB/s     7365547   3.22 ucd.all.flat.xml
zstd 1.5.7 -1           4  2814 MB/s  3136 MB/s     9485427   4.15 ucd.all.flat.xml
zstd 1.5.7 -2           4  2498 MB/s  2973 MB/s     9299308   4.07 ucd.all.flat.xml
zstd 1.5.7 -3           4  1572 MB/s  2991 MB/s     9157269   4.00 ucd.all.flat.xml
zstd 1.5.7 -4           4  1021 MB/s  2975 MB/s     9138377   3.99 ucd.all.flat.xml
zstd 1.5.7 -5           4   710 MB/s  2963 MB/s     8596049   3.76 ucd.all.flat.xml
lz4 1.10.0 --fast -1    1  1604 MB/s  5360 MB/s    15659269   6.85 ucd.all.flat.xml
lz4 1.10.0 --fast -2    1  1651 MB/s  5306 MB/s    16283003   7.12 ucd.all.flat.xml
lz4 1.10.0 --fast -3    1  1662 MB/s  5395 MB/s    16762524   7.33 ucd.all.flat.xml
lz4 1.10.0 --fast -4    1  1695 MB/s  5306 MB/s    17302361   7.56 ucd.all.flat.xml
lz4 1.10.0 --fast -5    1  1702 MB/s  5400 MB/s    17903623   7.83 ucd.all.flat.xml
lz4hc 1.10.0 -1         1  1181 MB/s  5281 MB/s    14255209   6.23 ucd.all.flat.xml
lz4hc 1.10.0 -2         1  1182 MB/s  5344 MB/s    14255209   6.23 ucd.all.flat.xml
lz4hc 1.10.0 -3         1   299 MB/s  5671 MB/s    11435777   5.00 ucd.all.flat.xml
lz4hc 1.10.0 -4         1   262 MB/s  5679 MB/s    11250958   4.92 ucd.all.flat.xml
lz4hc 1.10.0 -5         1   223 MB/s  5707 MB/s    11132953   4.87 ucd.all.flat.xml
zxc 0.8.3 -1            1  1395 MB/s  5688 MB/s    22414846   9.80 ucd.all.flat.xml
zxc 0.8.3 -2            1  1140 MB/s  5770 MB/s    18482899   8.08 ucd.all.flat.xml
zxc 0.8.3 -3            1   690 MB/s  5442 MB/s    14885407   6.51 ucd.all.flat.xml
zxc 0.8.3 -4            1   546 MB/s  5490 MB/s    14192609   6.20 ucd.all.flat.xml
zxc 0.8.3 -5            1   353 MB/s  5569 MB/s    13415765   5.86 ucd.all.flat.xml
[Params] cIters=1 dIters=1 cTime=1.0 dTime=2.0 chunkSize=0KB cSpeed=0MB

Может на ARM64 zxc и намного быстрее, но у меня так.

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

но у меня так

Потому что у тебя нормальный кэш )
А они, видимо, взяли какой-нибудь конченый unisoc, которому сильно помогла локальность данных.

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

Справедливости ради, автор интеграции zxc в lzbench не справился с многопоточностью. Возможно, что из-за недостаточно удобного API zxc.

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