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)
Ответ на: комментарий от annulen

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

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

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

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

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

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

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

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

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

greenman ★★★★★
()
Ответ на: комментарий от 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)
Ответ на: комментарий от annulen

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

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

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

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

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

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

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

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

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