LINUX.ORG.RU

Zstandard 1.5.4

 , , ,


0

2

После более года разработки и 650 коммитов состоялся выпуск 1.5.4 библиотеки быстрого сжатия данных и консольной утилиты Zstandard.

Улучшение производительности:

  • на 20% ускорена декомпрессия Хаффмана для архитектур, не имеющих реализации на ассемблере;
  • ускорение до 10% потоковой компрессии для уровней сжатия 1-2;
  • ускорение на 4-13% для уровней сжатия 5-12;
  • 3-11% ускорения компрессии для архитектуры arm;
  • 5-30% ускорения компрессии со словарём для уровней сжатия 1-4;
  • улучшена производительность ввода/вывода консольной утилиты zstd.

Изменения API:

  • удалено несколько расширенных экспериментальных функций;
  • поддержка декомпрессии «на месте»;
  • добавлена поддержка внешних поставщиков последовательностей;

Другие изменения:

  • улучшен man, с более детальным описанием режима --train;
  • увеличена производительность утилиты генерации однофайлового исходного текста;
  • множество улучшений в скриптах сборки;
  • улучшения консольной утилиты zstd.

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

★★★★★

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

Ответ на: комментарий от greenman

А вот этим нельзя пренебречь?

Ну так-то 140мс можно и на глаз заметить. Хотя, то что этим можно пренебречь при загрузке, наверное да, но 140мс тут, 140мс там, так и пол секунды можно насобирать по мелочам. А то как посмотришь сколько какой-нибудь ведроид загружается - плакать хочется(а ведь я уверен что при загрузке в 2 минуты, секунд 20-30 легко при желании наоптимизировать, просто всем наплевать).

PS: У меня ядро 11Мб, так что максимум выйдет наверное 30-40мс.

=====ZSTD=====
test.zst            : 33554432 bytes                                           

real    0m0,025s
user    0m0,005s
sys     0m0,012s
====ZIP====

real    0m0,143s
user    0m0,127s
sys     0m0,015s
====TARGZ====

real    0m0,143s
user    0m0,136s
sys     0m0,025s
=====LZ4=====
test.lz4             : decoded 33554432 bytes                                  

real    0m0,020s
user    0m0,012s
sys     0m0,008s
=====LZMA=====

real    0m1,617s
user    0m1,590s
sys     0m0,026s
=====XZ=====

real    0m0,055s
user    0m0,022s
sys     0m0,033s

Ну и на моем процессоре всего 5мс разница оказалась.

Loki13 ★★★★★
()
Последнее исправление: Loki13 (всего исправлений: 1)
Ответ на: комментарий от thegoldone
  • Плохой Го-код на уровне текста.
  • Безмозглая структура пакетов.
Joe_Bishop
()
Ответ на: комментарий от annulen

У Вас есть формула. И выигрыш. Если Вы считаете приемлемым проводить расчёты, замеры и прочее ради ничтожного, а он именно, что ничтожный, выигрыша – пожалуйста. Это зовётся крахоборством. Вряд ли нормально. Но не запрещено.

thegoldone
()
Ответ на: комментарий от windows10

Если ориентироваться только на время распаковки, то быстрее всего не сжимать вообще. Поэтому только время распаковки оценивать бессмысленно, оценивать надо некий компромисс между степенью сжатия и временем распаковки.

Scondo
()
Ответ на: комментарий от windows10

Ну так чем сильнее сжатие -> тем меньшего размера файл -> тем быстрее он должен считываться с диска.

Именно поэтому может иметь смысл выбрать алгоритм сильнее, чем LZ4 (который является, наверное, самым слабым из алгоритмов общего назначения).

Кстати

Во-первых, как тебе уже сказали, ты сжимаешь рандом (который по определению несжимаем) и твой тест не имеет смысла.

Во-вторых, ты читаешь не с диска, а из кэша в RAM, и твой тест опять же не имеет смысла.

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

Я попробовал сжать архив с Кудой (NVIDIA Cuda*), который в Арчевском ZST-пакете весит 1,5ГБ. Распакованный он весит 5,2ГБ. Если паковать так

zstd test -o test.zst

то получается 2,1ГБ. Далековато от реальности.

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

thegoldone
()
Ответ на: комментарий от intelfx

Я почти уверен, что у Вас есть знание о том, что на любом нормальном носителе cat отработает быстрее. Просто это знание ещё не подгрузилось, ввиду низкой скорости чтения.

#!/bin/bash

ls -alh

echo "Creating archives"
if [ ! -f test.zst ]; then
	echo "compress ZSTD"
	zstd test -o test.zst
fi

if [ ! -f test.zip ]; then
	echo "compress ZIP"
	zip test.zip test
fi

if [ ! -f test.gz ]; then
	echo "compress GZ"
	gzip -c test > test.gz
fi

if [ ! -f test.xz ]; then
	echo "compress XZ"
	xz -zk test
fi

if [ ! -f test.lz4 ]; then
	echo "compress LZ4"
	lz4 test
fi

if [ ! -f test.lzma ]; then
	echo "compress LZMA"
	lzma -k test
fi

ls -alh

echo "===== CAT"
hyperfine -m 5 "sh -c 'cat test > /tmp/test'"

echo "===== ZSTD"
hyperfine -m 5 "sh -c 'zstd -d test.zst -f -o /tmp/test 2> /dev/null'"

echo "===== ZIP"
hyperfine -m 5 "sh -c 'unzip -o test.zip -d /tmp/ > /dev/null'"

echo "===== GZ"
hyperfine -m 5 "sh -c 'gunzip test.gz -c > /tmp/test'"

echo "===== LZ4"
hyperfine -m 5 "sh -c 'lz4 -f -d test.lz4 /tmp/test 2> /dev/null'"

echo "===== LZMA"
hyperfine -m 5 "sh -c 'lzma -df test.lzma -c > /tmp/test'"

echo "===== XZ"
hyperfine -m 5 "sh -c 'xz -df test.xz -c > /tmp/test'"

rm -rf /tmp/test
$ ls -alh
итого 19G
drwxr-xr-x 1 user users  118 фев 12 08:29 .
drwxr-xr-x 1 user users  688 фев 12 07:00 ..
-rw-r--r-- 1 user users 1,1K фев 12 08:27 bench.sh
-rw-r--r-- 1 user users 5,2G фев 12 07:06 test
-rw-r--r-- 1 user users 2,6G фев 12 08:13 test.gz
-rw-r--r-- 1 user users 3,4G фев 12 07:06 test.lz4
-rw-r--r-- 1 user users 1,6G фев 12 07:06 test.lzma
-rw-r--r-- 1 user users 1,6G фев 12 07:06 test.xz
-rw-r--r-- 1 user users 2,6G фев 12 08:10 test.zip
-rw-r--r-- 1 user users 2,1G фев 12 07:06 test.zst
===== CAT
Benchmark 1: sh -c 'cat test > /tmp/test'
  Time (mean ± σ):      1.257 s ±  0.078 s    [User: 0.006 s, System: 1.247 s]
  Range (min … max):    1.119 s …  1.299 s    5 runs
 
===== ZSTD
Benchmark 1: sh -c 'zstd -d test.zst -f -o /tmp/test 2> /dev/null'
  Time (mean ± σ):      4.597 s ±  0.055 s    [User: 3.442 s, System: 1.147 s]
  Range (min … max):    4.546 s …  4.671 s    5 runs
 
===== ZIP
Benchmark 1: sh -c 'unzip -o test.zip -d /tmp/ > /dev/null'
  Time (mean ± σ):     28.361 s ±  0.115 s    [User: 27.162 s, System: 1.171 s]
  Range (min … max):   28.179 s … 28.469 s    5 runs
 
===== GZ
Benchmark 1: sh -c 'gunzip test.gz -c > /tmp/test'
  Time (mean ± σ):     26.184 s ±  0.358 s    [User: 24.996 s, System: 1.161 s]
  Range (min … max):   25.780 s … 26.598 s    5 runs
 
===== LZ4
Benchmark 1: sh -c 'lz4 -f -d test.lz4 /tmp/test 2> /dev/null'
  Time (mean ± σ):      3.506 s ±  0.032 s    [User: 2.228 s, System: 1.271 s]
  Range (min … max):    3.462 s …  3.540 s    5 runs
 
===== LZMA
Benchmark 1: sh -c 'lzma -df test.lzma -c > /tmp/test'
  Time (mean ± σ):     61.371 s ±  0.939 s    [User: 60.062 s, System: 1.254 s]
  Range (min … max):   60.630 s … 62.971 s    5 runs
 
===== XZ
Benchmark 1: sh -c 'xz -df test.xz -c > /tmp/test'
  Time (mean ± σ):     53.321 s ±  0.616 s    [User: 52.029 s, System: 1.248 s]
  Range (min … max):   52.831 s … 54.351 s    5 runs

Итого, в фаворе cat, zstd и lz4. Разумеется cat уделывает всех.

Архив – блоб NVIDA CUDA. Вполне реальный и достаточно большой.

cc @annulen

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

Качественно сгенерированные случайные данные несжимаемы

Есть ли вероятность что в качественно сгенерированных случайных числах будет 4 единицы подряд?

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

Итого, в фаворе cat, zstd и lz4. Разумеется cat уделывает всех.

В тестах нет сбросов кэша, поэтому результат предсказуем и, разумеется, не зависит от носителя.

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

Если Вы считаете приемлемым проводить расчёты, замеры и прочее ради ничтожного, а он именно, что ничтожный, выигрыша – пожалуйста

Не вижу проблемы потратить раз в несколько лет пять минут на сравнение алгоритмов.

Это зовётся крахоборством

Хорошее слово. Борьба с крахом - это замечательно.

Вряд ли нормально. Но не запрещено.

Мамку свою учи, что нормально, а что нет.

annulen ★★★★★
()

В связи с некоторым бурлением, рекомендуется использовать TurboBench или lzbench.

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

На неделе напишу, скорее всего. Там без сопутствующего PR не обойтись.

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

Вы теорией информации не владеете? Ни один архиватор не сможет сжать рандом сколько-нибудь значительно. Архиваторы работают за счёт дедупликации данных. И нет, машинный код имеет немало регулярности в себе, поэтому достаточно неплохо сжимается. Текст на естественых языках сжимается ещё легче, а уж тем более код на языке программирования.

Вообще простейший алгоритм сжатия текста — это обратный base64, пользуясь одним тем, что большинство байтов в тексте печатные ASCII можно уже сжать файл примерно на четверть.

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

Вы явно бредите. Так же, как и Ваш собрат по несчастью – @intelfx.

Ну да и ладно. Ваше право нести околесицу.

thegoldone
()
Ответ на: комментарий от Xenius

Архиваторы работают за счёт дедупликации данных.

Есть ещё сжатие по словарю. Например, если vmlinuz добавить в словарь. То сжиматься оно будет в один, несколько байт. В зависимости от реализации.

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

Это и есть дедупликация. То есть слово vmlinuz встречается несколько раз, а записано в одном месте — в словаре.

По крайней мере, я это и имел ввиду.

Xenius ★★★★★
()

zstd - отличный алгоритм сжатия. Юзаю как для сжимания дампов баз данных при бекапе так и в zfs. В последнем, на некоторых наборах данных, по скорости распаковки он сравним с lz4 при большей степени сжатия.

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

Есть ли вероятность что в качественно сгенерированных случайных числах будет 4 единицы подряд?

Начинать надо с того, насколько адекватна реальности вероятностная модель…

А распределение можно взять любым, приняв его за «норму».

i_am_not_ai
()
Последнее исправление: i_am_not_ai (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.