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

zpaq add e:\backup.zpaq c:\* И что ты на диске Е: сжимал?

zpaq add e:\backup.zpaq c:\* И что ты на диске Е: сжимал?

Там есть данные тестов. А еще ZPAQ предполагается в первую очередь как утилита для бэкапов

Ты сам создал его? Или в смысле тебе нравится?

Ты сам создал его? Или в смысле тебе нравится?

Люблю его

Откуда я знаю, что они тестировали, у них может там какой-то особенный файл на разделе лежал, его и тестировали.

Откуда я знаю, что они тестировали, у них может там какой-то особенный файл на разделе лежал, его и тестировали.

Там указано

В лом переводить, всё равно облапошат - никому на лоре повторить на реальных тестах не удалось.

В лом переводить, всё равно облапошат - никому на лоре повторить на реальных тестах не удалось.

Повторить? Кто пытался повторить?

Вышеотписавшиеся.

Вышеотписавшиеся.

Нет.

а частичное извлечение там работает нормально?

а частичное извлечение там работает нормально?

Не знаю. У меня таких задач нет.

Нет.

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

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

OK.
P.S. Не похоже на Напильника - данным от каких-то анонов в инете нельзя доверять

а частичное извлечение там работает нормально?

Да, причем, если использовать в полноценном инкрементальном режиме (с журналированием, дедупликацией и роллбеком), то ещё и прошлые версии можно достать. Назначение zpaq — резервное копирование. А Moderators микроскопом гвозди забивает.

Для простого поточного компрессора xz намного предпочтительной. Во-первых, он в разы быстрее при лучшей степени сжатия и на порядок быстрее при чуть худшей. Во-вторых, время распаковки xz в разы (в десятки раз при запуске выше xz -1) быстрее сжатия, что хорошо именно для распространения дистрибутивов. А вот zpaq на всех алгоритмах (кроме LZ77) практически симметричный.

Там есть данные тестов.

По тем тестам даже старый pcompress выглядит куда лучше. И заметь, время работы по логарифмической шкале, иначе тормоза zpaq -m5 вытянули бы график в небо.

Данные на том древнем графике начала 2014 года давно устарели. Сам zpaq по скорости не изменился, а вот алгоритмы lzma ушли вперед. Твоя изначальная посылка полностью неверна.

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

Свет твоей любви не прольется золотым дождем

Ты уже тяпнул, или как? Ты типа понимаешь что только что написал, или опять не литератор;) Набери в поисковике без кавычек «золотой дождь что это».

Ты уже тяпнул, или как?

Нам не суждено было счастье сохранить свое, свет твоей любви навсегда в моих слезах

И это ты пишешь Баке _куну_.

Яой в хокку потребляди саке,
Как лор породил такого пацака?
Фу таким быть.

Как лор породил такого пацака?

В упор не видеть наилучшего параметра zpaq -m 2, да, тут особый талант нужен

Не отмазывайся, литератор.

Не отмазывайся, литератор.

Сам гляди http://mattmahoney.net/dc/zpaq.html

https://docs.google.com/spreadsheet/ccc?key=0AttLICteMs_OdGxKdmFfZXRVWVRzZW5F...

В 6,6 раз быстрее 7zip, на 800 Mb меньше

Тю, ты ещё хреновее чем казался. Даже если ты прочитал такое странное в манах, пока не протестил, в этом нельзя быть уверенным.

в этом нельзя быть уверенным.

Оставайся неуверенным в своих чувствах

Кроме гона в этом коммете я ничего не прочитал, извини.

Значит у тебя большие проблемы с пониманием прочитанного. Гон — это график, которому более четырех лет.

наилучшего параметра zpaq -m 2

-rw-r--r--  132100096 firefox-esr-52.7.2,1.tar
-rw-r--r--   51461176 firefox-esr-52.7.2,1.xz-1.txz
-rw-r--r--   46950436 firefox-esr-52.7.2,1.xz-7.txz
-rw-r--r--   57256047 firefox-esr-52.7.2,1.zpaq-2.tar.zpaq
-rw-r--r--   59130322 firefox-esr-52.7.2,1.gzip-9.tgz

Ну-ну. Сжатие zpaq -m2 — это тот же плохо распараллеливающийся LZ77 за авторством Абрахама Лемпеля и Якоба Зива 1977 года рождения, что и -m1, только с более тщательным поиском. При этом размер архива у xz -1 на 11% меньше, а работает он в семь раз быстрее по часам (ниже сравнение). За похожее время xz -7 сделает на 22% меньший по размеру архив.

Для справки, LZ77 (c Хаффманом сверху) — это тот же алгоритм, что используется в PKZIP и gzip. Поэтому обычный gzip даст сравнимый с zpaq -m2 размер гораздо быстрее даже в один поток (но медленнее xz -1 по реальному времени, конечно). :)

> time xz -T 0 -1 -c firefox-esr-52.7.2,1.tar > /dev/null
25.362u 0.252s 0:07.15 358.1%   86+192k 4+0io 0pf+0w

> time xz -T 0 -7 -c firefox-esr-52.7.2,1.tar > /dev/null
100.320u 1.347s 0:44.43 228.8%  86+192k 4+0io 0pf+0w

> time zpaq a "" firefox-esr-52.7.2,1.tar -m 2 >/dev/null
88.148u 0.771s 0:49.97 177.9%   467+335k 2+0io 0pf+0w

> time gzip -c -9 firefox-esr-52.7.2,1.tar > /dev/null
17.076u 0.157s 0:17.35 99.2%    45+167k 2+0io 0pf+0w

Твой «наилучший» многопоточный zpaq -m2 оказался в три раза медленнее древнего однопоточного gzip -9, дав сравнимый по размеру результат (разница менее 1%).

У тебя даже нет http://prooflink.ru/ якобы подтверждающее брэдор

У тебя даже нет http://prooflink.ru/

Да, да. Закрывать глаза на реальность — это стильно, модно, молодежно. Зачем тебе видеть, что в онтопике и вокруг повсеместно используется многопоточный xz.

Сравнить современные алгоритмы мог бы для начала на https://quixdb.github.io/squash-benchmark/, если сам осилить тесты не можешь.

потому что это идеология архиваторов застряла в 20 веке.

нужен НЕ многопоточный архиватор, нужен нормальный многопоточный контейнер типа tar, который запакует/распакует любым алгоритмом, а если там один большой файл то он должен его разбивать внутри на блоки.

внутри контейнера должны быть блоки, и не важно как будет идти распараллеливание, через потоки или через fork....

Начнем с того, что большие объемы данных сжимают и эти ваши дэвелоперс и мэйнтейнерс

Начнём с того, что ты предлагаешь сжать уже пожатые данные (несжимаемые).

(а не только хентай для депозита)

Палишься.

а закончим тем, что ZPAQ с этим справляется намного более лучше.

Уже закончили тем, что ZPAQ на практике бесполезен.

Ксенофобов просьба не беспокоить.

Да я вижу, что ты на всех несогласных независимо от обоснованости позиции (при том, что твоя необоснована) вешаешь ярлыки.

У меня все.

У тебя давно всё, но ты почему-то не унимаешься.

Это хентай так на тебя повлиял?

Такой «аргумент» приводят любители форсить всякое непотребство на замену старому хорошо работающему.

Отлично. Теперь регистрант это анонимус. Эк тебя понесло.

Тебе доступно расписали области применения и реальные технические характеристики. А ты какую-то чушь несёшь.

нужен нормальный многопоточный контейнер

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

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

Выбрал большой файл - mozilla [48.85 MiB], выбрал машину s-desktop [Intel® Core™ i5-2400]
Compression Speed vs. Decompression Speed
lzma:xz Level:9 - CS 2,1 Mb/s, DS 47,77 Mb/s, Ratio: 3,89
zpaq:zpaq Level:1 - CS 17,39 Mb/s, DS 70,4 Mb/s, Ratio: 2,57
Подходящего для раскочегаривания на полную ZPAQ файла в несколько Gb, когда все остальные сольются уже капитально, в несколько крат, у них, конечно же, не было, но и 48 Mb - уже неплохо. По крайней мере, это уже лучше того брэдора, что пытались мне впарить.

Начнём с того, что ты предлагаешь сжать уже пожатые данные (несжимаемые).

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

Уже закончили тем, что ZPAQ на практике бесполезен.

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

Отлично. Теперь регистрант это анонимус. Эк тебя понесло.

Ты тоже «анон в инете», хочешь сказать, что нет?

Это хентай так на тебя повлиял?

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

форсить всякое непотребство

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

«xz Level:9» vs. «zpaq Level:1»

Отличное решение: сравнивать максимальное сжатие одного с минимальным другого. Конечно, тут xz на треть лучше запаковал. Он вообще может сжимать лучше любого алгоритма zpaq, кроме -m5, который жуткий тормоз. Приблизиться (но не догнать) по степени сжатия к xz можно только начиная с -m3, что сразу становится медленнее быстрых алгоритмов xz, и сравнимо по скорости сжатия с дефолтным xz -6, но по распаковке будет отставание zpaq в 10 раз.

Хвастаться алгоритмами zpaq -m1 и -m2 вообще не стоит — даже gzip в один поток обгоняет их по скорости, а первого одновременно и по степени сжатия, дыша второму в затылок (разница около 1%).

Подходящего для раскочегаривания на полную ZPAQ файла в несколько Gb

Я тебе открою маленький секрет: от большого файла начнет выигрывать xz с большими словарями. :)

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

Смотря для какой задачи.

Если наплевать на скорость, то для большинства наборов данных — zpaq -m5 из распространённых. Что может быть хорошо для резервного копирования. А может и не быть.

Если для экономии времени скачивания из интернета, то однозначно xz -9: скачать и распаковать твой пример (mozilla [48.85 MiB]) будет раз в пять быстрее, чем качать не запакованный.

Если для сжатия блоков диска налету — lz4: он распаковывает быстрее, чем SATA3 успевает передавать данные.

Опять пустой треп. Да что за?! Хоть бы http://prooflink.ru/ давал, чесслово

для большинства наборов данных — zpaq -m5 из распространённых

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

Всё с https://quixdb.github.io/squash-benchmark/ — твой пример mozilla [48.85 MiB] + s-desktop [Intel® Core™ i5-2400].

слова твоего брата?

Какого брата? Ты меня с кем-то спутал.

Всё с https://quixdb.github.io/squash-benchmark/

Не заметно. Даже цифр никаких нет.

Какого брата? Ты меня с кем-то спутал.

Это у вашего брата какие-то плохие предрассудки насчет ZPAQ

Даже цифр никаких нет.

Ты в своих же цифрах не можешь 1-2.57/3.89 ≈ 34% посчитать? То есть сам же написал: xz запаковал на треть лучше. Или ты не можешь на той же странице с mozilla [48.85 MiB] график посмотреть? Оставь на нём lzma, zlib-ng и zpaq — по легенде кликать можно. Неужели не видишь, что xz запакует лучше любого zpaq, кроме -m5? Неужели не замечаешь, что zlib кроет -m1 и -m2 как бык овцу? Я удивляюсь, ты слепой или тупой?

Это у вашего брата какие-то плохие предрассудки насчет ZPAQ

О каких предрассудках речь? Если для тебя нормально получить выигрыш в сжатии в 16%, потратив в 20 раз больше времени на сжатие и 140 раз на распаковку потом — флаг в руки. Значит устраивает, и именно это ты называешь «быстрее и даже выигрывая в эффективности».

  zpaq -m5        xz -3
4.16            3.47
332.49 KiB/s    6.61 MiB/s
331.2 KiB/s     46.2 MiB/s

1 - 3.47/4.16 ≈ 16%
6.61 MiB / 332.49 KiB ≈ 20
46.2 MiB / 331.20 KiB ≈ 143