Почему повсеместно используют архивы с однопоточными арихваторами?

Я удивляюсь, ты слепой или тупой?

Я тоже. Ты вообще про gzip писал. Ну и где он лучше zpaq -m 1?

Если для тебя нормально

Что? Где конкурент zpaq -m 1, цифры. Знаем мы вашего брата, чушь плести горазд, Напильник яркий тому пример

 > time zpaq -method 1 a Morrowind.tar.zpaq-M1 Morrowind.tar

real	1m14.510s
user	4m8.342s
sys	0m10.930s

 > time zpaq -method 5 a Morrowind.tar.zpaq-M5 Morrowind.tar

real	53m25.476s
user	206m32.883s
sys	0m52.498s

 > time 7z a -t7z -m0=LZMA2 -mmt=on -mx3 -md=1m -mfb=32 -ms=128m -mqs=on -bb0 Morrowind.tar.7z-fast Morrowind.tar

real	2m43.005s
user	8m56.022s
sys	0m3.167s

 > time 7z a -t7z -m0=LZMA2 -mmt=on -mx9 -md=64m -mfb=64 -ms=4g -mqs=on -bb0 Morrowind.tar.7z-ultra Morrowind.tar

real	7m44.051s
user	25m42.411s
sys	0m9.151s

 > du -m *
3392	Morrowind.tar
1733	Morrowind.tar.7z-fast
1540	Morrowind.tar.7z-ultra
2100	Morrowind.tar.zpaq-M1
1418	Morrowind.tar.zpaq-M5


 > time 7z e Morrowind.tar.7z-fast

real	2m36.215s
user	1m37.151s
sys	0m2.624s


 > time 7z e Morrowind.tar.7z-ultra 

real	2m10.670s
user	1m29.733s
sys	0m2.771s


 > time zpaq x Morrowind.tar.zpaq-M1

real	1m43.589s
user	1m6.957s
sys	0m1.254s


 > time zpaq x Morrowind.tar.zpaq-M5

real	54m5.086s
user	209m38.815s
sys	0m55.915s

Speed Ratio = Size Mb/Real seconds:

7z fast: 10.6319
7z ultra: 3.3189
zpaq m1: 29.7432
zpaq m5: 0.4636

Compression Ratio = Original size/Compressed size:

7z fast: 1.9572
7z ultra: 2.2025
zpaq m1: 1.6152
zpaq m5: 2.3921

Decompression Ratio = Compressed Size/Real seconds

7z fast: 11.1089
7z ultra: 11.8461
zpaq m1: 20.3883
zpaq m5: 0.4369

Ну как-то так. i5 3450, 8gb 1866

Я предлагаю? Ты из какой пещеры вылез? Их сжимают даже и эти ваши дэвелоперс и мэйнтейнерс

Да - ты предлагаешь. Ты предложил жать исошники с дистрибутивами линукса, в которых данные уже пожаты (то, что сжали «дэвелоперс» и «мэйнтейнерс»). Ты предложил сжимать фоточки и видеофайлы, в которых данные уже пожаты. Выше уже показали, что реальный тест на сжатие исходников линукса ZPAQ провалил с треском, и привели обоснование, почему.

Пруфов не будет

Конечно у тебя пруфов не будет. У тебя их и не было.

Ты тоже «анон в инете»,

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

Угомонись уже

Но ты же сам в технической теме разговорчики про хентай начал.

Какой архиватор на сегодняшний день лучше всех сжимает по-твоему?

1. Архиватор не сжимает и сжимать не должен. Задача архиватора - подготовить из кучи файлов набор данных для удобного хранения на архивном носителе. Классический пример: TAR (Tape ARchiver).

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

Хоть бы http://prooflink.ru/ давал, чесслово

Специально для тебя сослались даже на названия алгоритмов, по которым ты эти алгоритмы легко можешь загуглить. А на prooflink.ru ты сам ссылаешься, показывая тем самым свою настойчивую неправоту.

форсить всякое непотребство - слова твоего брата?

У тебя с головой всё не в порядке. Во-первых ни я ему не брат ни он мне. Во-вторых: ты форсишь нецелевое использование инструментов вообще и сжатие пожатых данных в частности. Это ли не непотребство?

Это как раз у тебя предрассудки насчёт ZPAQ.

Ты вообще про gzip писал. Ну и где он лучше zpaq -m 1?

Тебе прямо написали, что он лучше в совокупности распространённости и эффективности. Тебе также прямо указали, zpaq -m 1 работает практически по тому же алгоритму сжатия, что и gzip.

Знаем мы вашего брата, чушь плести горазд, Напильник яркий тому пример

Тебе срочно нужна галоперидоловая ванна.

Да - ты предлагаешь.

Никогда сжатых «несжимаемых» системных и прочих файлов от дэвелоперс и мэйнтейнерс не видел?

Выше уже показали, что реальный тест на сжатие исходников линукса ZPAQ провалил с треском

Кто, что и где.

А меня здесь знают и идентифицируют как отдельного пользователя.

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

Но ты же сам в технической теме разговорчики про хентай начал.

Это было адресовано Напильнику, который балдеет от хентая, не тебе, чего ты так взъелся, хентая захотелось?

Тебе также прямо указали, zpaq -m 1 работает практически по тому же алгоритму сжатия, что и gzip.

Цифр как всегда, не будет, не ты ли писал про «реализацию» алгоритма?

Тебе срочно нужна галоперидоловая ванна.

Взаимно

1. Архиватор не сжимает и сжимать не должен.

Слив засчитан.

Кто-нибудь, кроме выше отписавшихся еще читает этот тред? Отзвовитесь. Чувствую, что зря трачу ресурс клавиатуры, доказывая что-то фанатику.

скорость упаковки/распаковки чего?

скорость упаковки/распаковки чего?

Хентая

Сравни ZPAQ с bsc

http://libbsc.com

Сравни ZPAQ с bsc

Почему повсеместно используют архивы с однопоточными арихваторами? (комментарий)
bsc:bsc - CS 8,3 Mb/s, DS 11,87 Mb/s, Ratio: 3,19

Потому что работа с ZPAQ будет занимать гораздо больше времени.

Потому что работа с ZPAQ будет занимать гораздо больше времени.

Ну тут или да, или нет, на самом деле, чакры забиты, истины не видно совершенно, лишь избранному дано это постичь

Я говорю про практические задачи.

Если мне надо переслать файлы кому нибудь, то гораздо проще запаковать их в обычный zip (который даже древняя винда из коробки открывает), чем постоянно объяснять и уговаривать людей поставить архиватор который жмёт/распаковывает лучше и быстрее.

Ты вообще про gzip писал. Ну и где он лучше zpaq -m 1?

zpaq:zpaq Level:1 - CS 17,39 Mb/s, DS 70,4 Mb/s, Ratio: 2,57
zlib-ng:gzip Level:6 - CS 22,72 Mb/s, DS 208,84 Mb/s, Ratio: 2,68

Это просто gzip с ключами по умолчанию. Архиватор с алгоритмом deflate (например zip) будет ещё быстрее.

Пора уже действительно определиться: у тебя слепота от фапа на хентай или просто общая задержка развития?

Пора уже действительно определиться: у тебя слепота от фапа на хентай или просто общая задержка развития?

Допустим ты наконец принес какой-то пруф своих слов, дальше-то что? Вилять с LZMA на другие алгоритмы я тебя не просил, только запросил пруф, а ты уже в драку полез, ты дурачок или как? Особенно на фоне рукоплескания от сравнения ZPAQ и gzip в скорости на серьезных щах

Допустим ты наконец принес какой-то пруф своих слов

Разжевал и в рот положил то, что ты в упор не видел раньше. Кто же виноват, что не умеешь получать и анализировать информацию, поэтому вынужден вечно делать неверные выводы из неверных посылок.

дальше-то что?

А дальше ты понимаешь, что неоднократно получил ответ на свой вопрос. Никто не использует повсеместно такой «быстрый и эффективный» (на самом деле нет) zpaq просто потому, что он вчистую сливает распространенным gzip, zip и xz на большинстве задач. У zpaq есть своя очень узкая ниша, но даже там он не лидер.

Или не понимаешь и продолжаешь отрицать очевидное. Хотя, ты ведь уже давно переключился в damage control режим, и жирно троллишь.

Ну спасибо, услужил пруфом своих слов, выпей пивас. Вот только троллинг идет от вашего брата, из которого пруфы надо клещами доставать. Про скорость в сравнении с малоэффективными алгоритмами спору вообще не было

Про скорость в сравнении с малоэффективными алгоритмами спору вообще не было

Ну да. Как можно спорить, если многопоточный zpaq -m1 и -m2 (с малоэффективными алгоритмами) сливает по скорости однопоточному zlib (gzip, zip и т.п.), проигрывая по эффективности сжатия.

При этом «высокоэффективные» zpaq -m3 и -m4 сливают одновременно и по скорости, и по сжатию xz. Остаётся только очень эффективный zpaq -m5, выигрывающий десяток процентов сжатия, но сливающий по скорости в сотни раз.

Я так и не увидел от тебя подтверждения, где zpaq «в разы быстрее, выигрывая при этом в эффективности». На деле он всегда медленнее других распространенный компрессоров.

Троллинг и маняврирование в твоем послании шиты белыми нитками. Ваш брат всегда «тактично забывал» о m2, а коли речь о нем с пинка и заходила, напоминал о своей ксенофобии

Но у всех архиваторов очень плохо с распараллеливанием по вполне очевидным причинам.

Да ладно. Вон, bzip2 и gz вроде по блокам фиксированного размера жмут.

lzma тоже наверное. Конечно не совсем solid archiv получается, ну и что?

Ваш брат всегда «тактично забывал» о m2…

У тебя память какая-то куриная, что ли… Только последние минуты сохраняет.

Определись уже, был ли у тебя спор «про скорость в сравнении с малоэффективными алгоритмами». Но если так хочешь, давай ещё раз посмотрим на малоэффективный LZ77 в zpaq -m2.

zpaq -m2 vs. xz -1

1 - 3.39 / 2.73 ≈ 24% лучше сжимает xz
13.11 / 3.91 ≈ 3.4 раз быстрее сжимает xz

zpaq -m2 vs. gzip -6 (по умолчанию)

1 - 2.73 / 2.68 ≈ 1.8% хуже сжимает gzip
22.72 / 3.91 ≈ 6 раз быстрее сжимает gzip

Видимо, я так и не дождусь от тебя подтверждения, где zpaq «в разы быстрее, выигрывая при этом в эффективности» против самых распространенных программ.

Видимо, я так и не дождусь от тебя подтверждения, где zpaq «в разы быстрее, выигрывая при этом в эффективности» против самых распространенных программ.

Пруф я дал давным-давно, У тебя память какая-то куриная, что ли… Только последние минуты сохраняет.

Пруф я дал давным-давно

Пруф того, что что zpaq -m1 (уступающий во всём gzip) жмет на 34% хуже, чем xz -9?

Где подтверждение «в разы быстрее, выигрывая при этом в эффективности»?

Пруф того, что что zpaq -m1 (уступающий во всём gzip) жмет на 34% хуже, чем xz -9?

Месье тролль? Хотя, чего я спрашиваю?

Да ладно.

Именно так. Алгоритмы параллелятся плохо, остаётся только сжимать независимыми кусками, жертвуя эффективностью.

Вон, bzip2 и gz вроде по блокам фиксированного размера жмут.

Bzip2 действительно работает независимыми блоками (по 600КБ по умолчанию), и параллельные реализации существуют (pbzip2). На каждый блок нужно восемь его размеров в памяти в один поток и несколько больше в параллельной реализации.

А вот deflate в gzip может легко ссылаться на распакованные данные предыдущего блока, при этом размер не только выходного но и входного блока не фиксирован. По этой причине декомпрессию распараллелить невозможно. В природе есть pigz, который почти линейно масштабирует сжатие, делая его незначительно хуже из-за не совсем оптимальных границ блоков. Распаковывает он в один поток.

lzma тоже наверное.

LZMA2 уже давно неплохо параллелится и пропускает участки с плохой энтропией.

А какие ещё пруфы ты давал, кроме http://prooflink.ru/

Где подтверждение «в разы быстрее, выигрывая при этом в эффективности»? Цитату или ссылку на сообщение приведи.

Где подтверждение «в разы быстрее, выигрывая при этом в эффективности»? Цитату или ссылку на сообщение приведи.

Чукча писатель. Эта ссылка со всеми данными светилась в треде раз 5, думаю, такому «таланту» как ты, _в который раз_ ее приводить не надо

Ты опять про безбожно устаревшую таблицу с http://mattmahoney.net/dc/zpaq.html, где нет ни xz, ни gzip?

Ты опять про безбожно устаревшую таблицу с http://mattmahoney.net/dc/zpaq.html, где нет ни xz, ни gzip?

Новее у тебя все равно нет, достаточно троллинга.

Новее у тебя все равно нет

https://quixdb.github.io/squash-benchmark/

И никто не мешает протестировать на своём собственном компьютере, как многие и сделали. Результаты совсем не в пользу zpaq.

достаточно троллинга

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

https://quixdb.github.io/squash-benchmark/

3 шланга в треде, so cute. Или ты действительно читать не умеешь?

таблицы четырехлетней давности доказательств у тебя нет

...