Zstandard 1.5.4

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

Ну так-то 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мс разница оказалась.

• Плохой Го-код на уровне текста.
• Безмозглая структура пакетов.

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

Откуда мне знать какая там конфигурация?

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

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

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

Кстати

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

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

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

zstd test -o test.zst

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

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

Я почти уверен, что у Вас есть знание о том, что на любом нормальном носителе 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Крахоборство – это не борьба с крахом. О, как же Вы скучны.

Вы

5.2.

Ты прав, крахоборство - это крах борьбы.

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

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

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

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

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

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

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

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