LINUX.ORG.RU

Zstandard 1.5.5

 , , ,


1

2

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

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

  • увеличена скорость сжатия на средних уровнях;

Улучшения консольной утилиты zstd:

  • использование mmap при использовании больших словарей;
  • увеличение скорости режима --patch-from;
  • увеличение скорости на ~+10% при обработке множества маленьких файлов;
  • устранена ошибка при записи в директорию без прав на запись.

Документация:

  • обновлена спецификация zstd;
  • документирована возможность создания «жирных» бинарников для macos;

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

  • tests/fullbench может использоваться для нескольких файлов.

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

★★★★

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

Годно, нужно.

Изменения довольно минорные, впрочем.

увеличена скорость сжатия на средних уровнях;

Кто в курсе, какие уровни сжатия считаются средними? Те, что не требуют --ultra, или ещё сильно ниже?

upd: нашёл по ссылке. level 9. То есть очень далеко от того, что реально юзается как среднее (17–19)… Жаль. Вот на высоких бы скорость компрессии увеличить, было бы совсем здорово.

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

The best compressor in the world bar none.

Без шуток.

Если хочется сжимать что-то ещё сильнее, то пожалуйста LZMA2 4GB dictionary, но со скоростью распаковки на порядок ниже.

Почему туча дистров до сих пор поставляет модули ядра, даже man страницы и прочее в XZ - ума не приложу.

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

Ты загнул, конечно, с 19 уровнем. Я подобные тесты еще давно изучал, выбирая алгоритм сжатия для Btrfs, и пришел к выводу, что нет смысла использовать иные уровни кроме 3-го (между 3 и 19 уровнями скорость сжатия падает в 100 раз!!!)

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

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

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

Я не для Btrfs юзаю, а либо с SquashFS (level 19), либо для тарболлов tar.zst (level 20 или 21 с --ultra), меня интересует скорость разжатия (особенно для SquashFS) и степень сжатия, а скорость сжатия мне не критична, но было бы, конечно приятно улучшить, именно потому что она значительно ниже.

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

документирована возможность создания «жирных» бинарников для macos;

ЖЫР стекает с монитора

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

Для прям максимально крутого сжатия надо юзать zpaq и аналоги. Но там скорость сжатия на порядок ниже даже, чем у xz.

CrX ★★★
()

увеличение скорости на ~+10% при обработке множества маленьких файлов;

Это может положительно сказаться на zram?

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

Сомневаюсь, это же про консольную утилиту.

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

Если хочется сжимать что-то ещё сильнее

lrzip от анестезиолога. Правда я хз, насколько оно ещё живое.

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

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

Но всё равно гляну из интереса, не слышал о нём.

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

zpaq, вписанный в 2 гига оперы всё ещё заметно превосходит 7zip, вписанный в 2 гига оперы.

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

Ну для встраивания в ФС «максимально крутая» степень сжатия никогда не требуется. Там всегда компромис между скоростью и степенью сжатия, причём с приоритетом первому.

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

А если пользователь считает по другому, почему бы не дать возможность указать это в конфиге? В конце концов сейчас уровень сжатия zip не такой уж компромис, современные цпу способны на большее. Да и форматы сжатия с несколькими алгоритмами под капотом тоже имеются.

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

Это вроде бы можно пережить, а вот невозможность работать в конвейре...

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

А если пользователь считает по другому, почему бы не дать возможность указать это в конфиге?

Честно говоря, я не понял, как это соотносится с контекстом предыдущей беседы. Ну как бы у нас уже есть lzo, сабж, DEFLATE и lzma2/xz. Почему не подойдёт zpaq, вы уже и так сказали. Но он и так неюзабелен был бы для R/W файловой системы, просто в виду скорости на порядок (а то и порядки) ниже, чем даже у lzma2, не говоря уж об остальных. Для RO в каком-то очень экзотическом виде — может быть, но даже такой юзкейс мне сложно представить.

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

Честно говоря, я не понял, как это соотносится с контекстом предыдущей беседы.

Там речь шла «а зачем нам все эти 17+ уровней сжатия, если 3-й оптимален по скорости?».

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

А, в этом смысле… Ну да, согласен. Тут случаи разные бывают, и даже подо что-то уровня xz/lzma2 могут быть юзкейсы.

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

Вот собственно я и хотел бы включить прозрачное сжатие lzma -6 для ФС некоторых своих дисков. Мелкими блоками это не требует дофига памяти.

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