Zstandard 1.5.4

Отдельно упомяну о проекте Kanzi: C++, Go, Java.

может отдельной мини-новостью?
вроде выглядит интересно

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

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

А LZ4 все равно побыстрее будет.

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

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

А PAQ8 сожмёт получше.

на /dev/random?

многие не знают об этом проекте

Ну, учитывая, что некоторые дистры (арч, юбунта…) уже с 2020/21 перешли на сжатие пакетов в zstd… )

Ссылка1
Ссылка2

на /dev/random?

Нет, на распаковке свежескомпиленного ведра, тащемта.

А PAQ8 сожмёт получше.

Наверное, осталось дело за малым - пропяхнуть это в апстрим.

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

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

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

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

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

Оно уже, правда жать будет до-о-о-о-лго.

свежескомпиленного ведра

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

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

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

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

dd if=/dev/random bs=100M of=testfile count=1 разве не делает файл?
что ты такое?!

Го-либа позорище то ещё, каэш.

dd if=/dev/random bs=100M of=testfile count=1 разве не делает файл?
что ты такое?!

Какая мне разница что делает твой dd if\of?

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

Это понятно, но что твой /dev/random делает в теме про zst и в ответе на коммент о распаковке ядра ?

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

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

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

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

Не усложняй.

Чем оно лучше WinRar?

Стивен Кинг интересуется, «Оно» или «Оно-2»?

Только «Оно», только фильм 2017го года!

Ещё Fedora: https://fedoraproject.org/wiki/Changes/Switch_RPMs_to_zstd_compression

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

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

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

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

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

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

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

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

Учитывая что у меня 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мс. Размер архивов одинаковый.

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

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

Да пофиг. Белый шум жать смысла нет.

Раскройте мысль, пожалуйста.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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