Что мешает замержить это в основной код bzip2?

Между делом вспоминаю p7zip, который в 2014 году до сих пор распаковывает архивы в один поток.

bzip2, используемый везде, где только можно - однопоточный? мда

pbzip2 не даёт ускорения при распаковке файлов, сжатых обычным bzip2, в этом главная засада. А новые файлы в bzip2 уже мало кто пакует, все переходят на lzma.

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

Сделал небольшой тест. Сжал файл 700Мб с помощью pbzip2 и bzip2. Степень сжатия получилась почти одинаковая (bzip2 сжал лучше всего на 0,1Мб). А вот скорость очень даже разная:

pbzip2 затратил 44 сек., а bzip2 - 125 сек.

Так что для тех, кто пакует в tar.bz2 - смысл в использовании сабжа есть.

как оно в сравнении с lbzip?

И, если не ошибаюсь, p7zip еще и не обновлялся давно, и объявленного устаревшим кода в нем немало.

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

Обычный bzip2 тоже на блоки бьёт.

распаковывает архивы в один поток

К.О. подсказывает, что при декомрессии сплошного потока (99.9% алгоритмов сжатия) распараллеливать тупо нечего.

А если собрать его не GCC, но ICC (если штеуд), то можно еще 10% выжать.

А на AMD эти 10% пропадут?

Последняя версия 9.20 (18 ноября 2010)
Бета-версия 9.22 beta (18 апреля 2011 года)
Альфа-версия 9.32 alpha (1 декабря 2013 года)

Тем не менее:

Состояние В активной разработке

Не в курсе, не пробовал собирать пакеты ICC'кой для камней AMD.

Производительность будет немного хуже, потому, что ICC определяет набор инструкций по модельному ряду процессоров штеуд, а не по самому факту поддержки SSE / AVX и т.п. Погугли, народ регулярно бурлит в интернетах...

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

Он не предназначен, они просто специально генерируют для не-штеуд процессоров не оптимальный код, по этому поводу были суды =(

При желании можно что-нибудь придумать. Контрольные точки какие-нибудь. Полностью solid-архивы это вообще зло. Лучше бить кусками по 32МБ например. Размер архива от этого вырастет разве что на пару байт, а устойчивость к повреждению содержимого и скорость распаковки возрастёт в несколько раз.

Мне было (и есть) на самом деле интересно. Погуглил, увидел, что тщательно оптимизированный icpc бинарник на АМД может совсем не запуститься.

А новые файлы в bzip2 уже мало кто пакует, все переходят на lzma.

Вот-вот, помнится в том году была новость что сайт ядра Linux перестаёт выкладывать архивы в bz2 формате и оставляет только xz формат архива.

См., например, http://www.agner.org/optimize/blog/read.php?i=49 .

Он же тормоз!

lbzip2 лучше

lbzip2 лучше

lrzip ftw!

Полностью solid-архивы это вообще зло.

Вроде как, из форматов «сплошных» архивов популярностью до сих пор пользуется только .tar.*. И ничего особо тут не придумаешь — юниксвей и всё такое, архиватор и [де]компрессор являются независимыми друг от друга программами и потому второй ничего не знает о первом. На сжатие подаётся один файл, до содержимого которого компрессору нет никакого дела, что вполне логично. При распаковке, соответственно, наоборот — раз сжимали один файл, то и декомпрессор выплюнет один файл, о содержимом которого он ничего не знает и знать не хочет.

IMHO, это как раз один из тех случаев, когда конструирование комбайнов наподобие ZIP, RAR, 7z и т.п., где архиватор совмещён с [де]компрессором, вполне оправдано, пусть и в ущерб гибкости выбора метода сжатия.

О, тогда ждем бету 9.32 :)

LORzip?

IMHO, это как раз один из тех случаев, когда конструирование комбайнов наподобие ZIP, RAR, 7z и т.п., где архиватор совмещён с [де]компрессором, вполне оправдано, пусть и в ущерб гибкости выбора метода сжатия.

месье толстяк?

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

хотя, если это было искренне - то это многое объясняет про нынешние тренды в софте.

как оно в сравнении с lbzip?

Медленнее.

xz. end of story.

xz жмёт хуже.

На дефолтных настройках, как обычно, типо lrzip -9 --extreme vs xz -5, да?

Файлы, созданные с использованием pbzip2, полностью совместимы с bzip2.

А как с остальной совместимость? Можно сделать симлинк на bzip2 и пользоваться без проблем?

Исправлен формат printf.

В смысле закрыли уязвимость?

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

Ну попилит компрессор таровский архив на блоки и что дальше? Кто потом скажет декомпрессору, какие из этих блоков надо распаковывать, а какие можно пропустить? Тар, который без распаковки всего файла .tar.* даже список файлов в архиве получить не сможет? Или файловый менеджер, который индекс получает от тара и понятия не имеет, какие блоки сжатого архива занимает тот или иной файл и где эти блоки находятся?

Можно сделать симлинк на bzip2 и пользоваться без проблем?

Симлинк делать не пробовал, но свои скрипты переделывал sed'ом, так что и с симлинком проблем быть не должно.