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)

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

Написать-то новость не трудно, но может быть дождаться очередного мини-релиза (прошлый был полгода назад)?

Или могу в Development тиснуть.

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

Думаю стоит в мини-новости упомянуть - многие не знают об этом проекте, как я. Спасибо dataman за то, что он обратил внимание на него.

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

«Да будет срач !!!» - объявил «рогатый аватар».

Почему же срач ? Вполне себе критика. Пример чуть выше указал - ядро и модули. В этом случае критична именно скорость распаковки, а не коэффициент сжатия или скорость сжатия.

В моем случае, мне 2 секунды важнее чем 2 мегабайта.

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

Я хоть и арчевод, но как-то не заморачивался с тем, чем жмёт пакет арч...

Единственное, что я помню, так это xz на фряхе.

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

Имелась в виду малоизвестность kanzi.

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

рандомные блобы, практически тот же самый /dev/random, не?

Я не знаю. Просто отношусь ко всему как тупая блондинка. Я ж «работаю» не с /dev/random, а с файлами. Если технология №1 распаковывает мои файлы быстрее технологии №2, то я выбираю первую технологию =)

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

ну из man dd:
утрированно:
согласно опциям оно делает копию данных из устройства /dev/random с размером блока данных 100 мегабайт, в количестве 1 блока в выходной файл testfile в текущей директории

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

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

etwrq ★★★★★
()

А это вообще законно? Если вы понимаете о чём я (а вы понимаете)…

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

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

Зачем мне псевдослучайные данные, если я их не использую ?

Не усложняй.

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

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

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

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

Пример чуть выше указал - ядро и модули. В этом случае критична именно скорость распаковки, а не коэффициент сжатия или скорость сжатия.

А время чтения архива с диска ты учёл?

Если ты в самом деле оптимизируешь миллисекунды при загрузке (а не просто чешешь языком), то твоя целевая функция — это (archive size / read performance) + decompression time, а не просто decompression time.

В моем случае, мне 2 секунды важнее чем 2 мегабайта.

Прости, а сколько гигабайт у тебя занимают «ядро и модули», что между LZ4 и Zstd 2 секунды разницы на декомпрессии?

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

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

Учитывая что у меня NVMe, думаю что временем чтения архива можно пренебречь. Конечный размер ядра я не замерял, но думаю там порядка 9-10 мегабайт, плюс-минус.

Ты слишком буквально воспринял фразу про 2 секунды и 2 мегабайта, ее смысл не в цифре «2», а в том что время распаковки важнее чем экономия места на разделе.

Кстати.

#!/bin/bash
rm -f test*
rm -rf /dev/shm/*
echo "Creating test file"
dd if=/dev/random of=test bs=1M count=32
echo "Creating archives"
zstd test -o test.zst > /dev/null
zip test.zip test > /dev/null
tar -czvf test.tar.gz test > /dev/null
xz -zk test > /dev/null
lz4 test
lzma test
echo "=====ZSTD====="
time zstd -d test.zst -o /dev/shm/test1 > /dev/null
echo "====ZIP===="
time unzip test.zip -d /dev/shm/test2/ > /dev/null
echo "====TARGZ===="
mkdir /dev/shm/test3
time tar -xvf test.tar.gz -C /dev/shm/test3/ > /dev/null
echo "=====LZ4====="
time lz4 -d test.lz4 /dev/shm/test4 > /dev/null
echo "=====LZMA====="
time lzma -df test.lzma > /dev/null
echo "=====XZ====="
time xz -df test.xz > /dev/null

На 32-мегабайтном файле, на высокоскоростном носителе, у меня распаковка ZST занимает 172мс, распаковка LZ4 занимает 39мс. Размер архивов одинаковый.

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

Ты понимаешь, что сжатие рандома - это бред, который ничего не оценивает?

В настоящем случае разница будет в размере занимаемого файла. Потому что большинство реальных данных в отличие от рандома - сжимаемые. И вот взяв данные, актуальные для твоей задачи надо уже оценивать что будет больше и что быстрее.

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

Вы верно сказали. Но только чтение с диска можно не учитывать. Если работа по сети, тогда возможно размер будет что-то решать. Зависит. И нужно будет решать это уравнение.

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

Этот тест некорректен, так как отсутствует очистка кэша ФС после каждой распаковки. Когда грузится ОС, ядро распаковывается только один раз, и никакого кэша еще нет.

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

Но только чтение с диска можно не учитывать.

Почему? Если носитель медленный или CPU очень быстрый, размер сжатого файла вносит больший вклад во время его чтения, чем скорость работы алгоритма декомпрессии.

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

На практике, чтением с диска всегда можно пренебречь. Либо это случай, когда носитель действительно медленный.

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

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

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

То есть если проц настолько быстрый, что распаковывает lz4 быстрее, чем nvme успевает считывать данные, то нужно не менять алгоритм сжатия на более эффективный, а ставить еще более быстрый носитель? Ясно-понятно.

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

На практике, чтением с диска всегда можно пренебречь.

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

«На 32-мегабайтном файле, на высокоскоростном носителе, у меня распаковка ZST занимает 172мс, распаковка LZ4 занимает 39мс»

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

уже с 2020/21 перешли

сразу медленней стало - вам на ваших ssd этого не видать, а я на своих ide шлейфовых винтарях такое сразу заметил и теперь debian грузится быстрее чем arch на одном и том же железе, а раньше было наоборот.

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

Ты понимаешь, что сжатие рандома - это бред, который ничего не оценивает?

При чем здесь сжатие, если замеряется время расжатия ?

В настоящем случае разница будет в размере занимаемого файла.

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

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

Этот тест некорректен, так как отсутствует очистка кэша ФС после каждой распаковки. Когда грузится ОС, ядро распаковывается только один раз, и никакого кэша еще нет.

В смысле некорректен ? Запусти скрипт из shm или из tmpfs, и скорость ФС у тебя будет равна скорости кеша, делов-то. Даже если с кешем - тем лучше, можно абстрагироваться от скорости носителя.

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

В смысле некорректен ? Запусти скрипт из shm или из tmpfs, и скорость ФС у тебя будет равна скорости кеша, делов-то. Даже если с кешем - тем лучше, можно абстрагироваться от скорости носителя.

Если цель теста - узнать, с каких алгоритмом сжатия ядро будет быстрее грузиться с диска, то надо наоборот, обойти кэш и читать только с диска.

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

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

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

Если цель теста - узнать, с каких алгоритмом сжатия ядро будет быстрее грузиться с диска, то надо наоборот, обойти кэш и читать только с диска.

Тесты с ядром я провел еще раньше чем наваял этот тупой скрипт. Теперь lz4 онли. Я бы вообще ведро не запаковывал, с современными-то скоростями и объемами, но в конфигураторе такой опции нет.

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

в конфигураторе такой опции нет

В теории опция существует, но зависит от флага HAVE_KERNEL_UNCOMPRESSED, который почему-то включен только для s390

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

...Просто отношусь ко всему как тупая блондинка...
Если технология №1 ... быстрее технологии №2, то я выбираю первую технологию =)

Простите, пожалуйста, это не про Вас анекдот про машинистку, набирающую 1000 знаков в минуту?

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

Или могу в Development тиснуть.

Тоже вариант.

А если ты им пользуешься и можешь привести пример кода с разбором — можно даже и мини-статью, там оно точно не утонет.

hobbit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.