Обсуждение архиваторов

[drBatty]

а bzip2 почти не отличается от gzip, даёт мизерную экономию. Не лучше ли тогда gzip использовать? Он таки побыстрее.

вы не правы

Код: Выделить всё

-rw-r--r-- 1 drb users 60292527 2010-01-13 05:25 all.tar.bz2
-rw-r--r-- 1 drb users 78040607 2010-01-13 05:26 all1.tar.gz

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

[Flaming]

Сожмите тот же архив lzma/lzop, интересно же.

[drBatty]

Сожмите тот же архив lzma/lzop, интересно же. smile.gif

сейчас...
lzma нету, есть xz - это тоже, только круче. (lzma-2)

-rw-r--r-- 1 drb users 207349760 2010-01-13 10:51 all.tar
-rw-r--r-- 1 drb users 37068622 2010-01-13 10:50 all.tar.bz2
-rw-r--r-- 1 drb users 54976214 2010-01-13 10:56 all.tar.gz
-rw-r--r-- 1 drb users 34232664 2010-01-13 10:57 all.tar.xz

xz жмёт немного лучше bzip2 но уж ооочеееенььь дооолгооооо
и памяти жрёт немеренно.
gzip жмёт плохо но быстро.

Сам файл - логи IRC (текст по-русски)

PS: а всех обскакал WinRAR

-rw-r--r-- 1 drb users 29817682 2010-01-13 11:14 all.rar

А что вы хотите? PPMD лучший алгоритм для текстов.

[sciko]

Кстати, а как переводитьсяв xz "run-length encoder chunk size" (застрял на этом когда клепал перевод)?

Вроде бы PPMD есть и в xz.

[drBatty]

Кстати, а как переводитьсяв xz "run-length encoder chunk size" (застрял на этом когда клепал перевод)?

без понятия...

Вроде бы PPMD есть и в xz.

нет. во всяком случае в документации об этом ни слова

[sciko]

без понятия...

Вот так всегда T_T

нет. во всяком случае в документации об этом ни слова

А, точно! Попутал с p7zip.

[Luinnar]

PS: а всех обскакал WinRAR

-rw-r--r-- 1 drb users 29817682 2010-01-13 11:14 all.rar

А что вы хотите? PPMD лучший алгоритм для текстов.

7zip обычно лучше rar'а жмет, может и его попробуете?

[Flaming]

drBatty, у lzma есть неоценимое преимущество - он зато распаковывает быстрее
Кстати, люди, не в курсе, почему его переименовали в xz?

[drBatty]

7zip обычно лучше rar'а жмет, может и его попробуете?

лень... его-же собирать надо. И думаю жать он будет лучше, а памяти жрать больше рара.

lzma есть неоценимое преимущество - он зато распаковывает быстрее

ещё-бы. BWT который в bzip2 и LZMA из xz - это не симметричные алгоритмы, при распаковке нужно намного меньше памяти и времени. А вот PPM... Жрёт память тоннами, и тормозит. Причём и на распаковке тоже.

А xz это как я понял новый архиватор на основе алгоритма LZMA-2

ЗЫЖ что-то я не нашёл PPM сжимателя для Linux, разве что HA, но он не собирается :( и устаревший.

[/dev/random]

ЗЫЖ что-то я не нашёл PPM сжимателя для Linux, разве что HA, но он не собирается и устаревший.

http://http.us.debian.org/debian/pool/main/p/ppmd/
Последний релиз - чуть больше месяца назад.

[drBatty]

странно - исходные тексты PPMd для Windows, а деб-пакет не ковыряется :(
ладно, запустил под wine, как и для xz выделил 100Мб

-rw-r--r-- 1 drb users 32262437 2010-01-13 19:23 all.pmd

что-то хуже рара (он выдал 29Мб, видимо в раре имеется спец-таблицы для русского текста)

[drBatty]

а вот 7z мне не понравился:
документация слишком обширная, ключей и параметров выше крыши, причём все нестандартные. понапихано туда всё что угодно...

-rw-r--r-- 1 drb users 35235240 2010-01-13 20:16 all.tar.7z

и жмёт плохо. хуже рара, xz, почти как bzip2 причём очень долго, и как-то всё вешает - другие утилиты не тормозят всю систему.

[Luinnar]

и жмёт плохо. хуже рара, xz, почти как bzip2 причём очень долго, и как-то всё вешает - другие утилиты не тормозят всю систему.

7zip использует многопоточность, соответственно и работает он быстрее однопоточных архиваторов, дающих ту же степень сжатия. И система ваша тормозит из-за этого же.
А вот по-поводу степени сжатия не согласен, как правило 7zip всё же лучше rar'а жмет.

[Flaming]

7zip использует многопоточность, соответственно и работает он быстрее однопоточных архиваторов, дающих ту же степень сжатия. И система ваша тормозит из-за этого же

Это, кстати, очень полезно на многопроцессорных системах. Кстати, а никто не знает, по сети нельзя заставить 7zip работать? Чтобы задействовал сразу несколько компьютеров, кластер?..
Или есть для этого другой архиватор?

drBatty, да, кстати, попробуйте сжимать не tar-архив, а целый каталог 7zip-м. Кстати, вы странно поступили - 7zip-ом сжали tar, а rar-ом исходный каталог, а ещё осмеливаетесь их сравнивать :-P
Может результат и не поменяется... я просто не знаю. Не пробовал.

[Luinnar]

Провёл я тут своё собственное тестирование. 7zip показал себя лучше всех по степени сжатия, однако по скорости сжатия он в первом тесте проиграл bzip2, отыгравшись на скорости распаковки (в два раза быстрее, чем bzip2). Абсолютный чемпион по скорости сжатия gzip, что и не удивительно.

Следует, однако, учесть, что тестирование было проведено на двухядерной машине, так что 7zip имел преимущество в скорости за счет многопоточности.
Rar запускал через wine, поэтому скорость сжатия/распаковки под Windows будет отличаться, но вот размер архива должен быть тот же.

Вывод для себя я сделал такой: если критична скорость, то следует использовать tar/gzip, а в остальных случаях лучше всего подойдёт 7zip (с tar'ом если важно сохранить права, атрибуты, ссылки и т.п., а иначе без tar'а).

А вот и сами результаты, отсортированные по размеру архива:

Код: Выделить всё

============================================
    72M     thunderbird imap mail box
--------------------------------------------
type    size    compress_time   extract_time
----    ----    -------------   ------------
7z       35414424        29.6    4.3
tar.7z   37681707        30.4    4.9
tar.xz   40510040        51.8    5.1
tar.lzma 40520060        1:19.3  4.7
rar      41578551        44.4    4.2
tar.bz2  48665550        21.6    9.4
tar.gz   48742648        5.8     2.2
zip      48754035        5.8     1.6
============================================

Код: Выделить всё

============================================
    378M    source code
--------------------------------------------
type    size    compress_time   extract_time
----    ----    -------------   ------------
tar.7z   67792249        1:50.0  49.3
tar.lzma 68405002        6:40.5  44.8
tar.xz   68686588        3:20.2  43.4
7z       68773748        2:03.9  52.3
tar.bz2  92384314        2:53.5  43.8
rar      105795556       2:04.8  -
tar.gz   106120786       21.8    50.5
zip      114070861       24.0    45.9
============================================

Код: Выделить всё

============================================
    733M    thunderbird imap mail box
--------------------------------------------
type    size    compress_time   extract_time
----    ----    -------------   ------------
7z       247761545       4:19.0  46.6
tar.7z   247868452       4:05.2  53.4
tar.lzma 257929044       7:47.1  1:28.5
tar.xz   257969224       7:30.7  48.2
rar      281261905       5:57.9  44.7
tar.bz2  359186147       5:20.9  1:26.7
tar.gz   383313519       1:04.6  47.9
zip      383452624       1:05.6  41.2
============================================

Версии архиваторов:
tar: 1.22
zip: 2.3
gzip: 1.3.5
bzip2: 1.0.5
p7zip: 9.04
xz: 4.999.9beta
lzma: 4.999.9beta
rar: 3.50 via wine

Процессор: AMD Athlon™ 64 X2 Dual Core Processor 5200+ Socket AM2

[drBatty]

7zip использует многопоточность, соответственно и работает он быстрее однопоточных архиваторов, дающих ту же степень сжатия. И система ваша тормозит из-за этого же.
А вот по-поводу степени сжатия не согласен, как правило 7zip всё же лучше rar'а жмет.

а у меня 1 CPU.
к тому-же, xz вроде тоже использует.
а вот "как правило" - не наблюдаю. зависит от исходных файлов. PPM всё-же лучше (наверное он будет неплохо работать и в 7z, он это может, но слишком запутанные параметры - не осилил).

Или есть для этого другой архиватор?

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

да, кстати, попробуйте сжимать не tar-архив, а целый каталог 7zip-м. Кстати, вы странно поступили - 7zip-ом сжали tar, а rar-ом исходный каталог, а ещё осмеливаетесь их сравнивать :-P
Может результат и не поменяется... я просто не знаю. Не пробовал.

не должен сильно изменится, надо попробовать.
а сжимал так потому, что winrar так по умолчанию сжимает, а 7z это вроде как unix-way...

[Flaming]

Rar запускал через wine, поэтому скорость сжатия/распаковки под Windows будет отличаться, но вот размер архива должен быть тот же.

На чём основано данное предположение?

[drBatty]

378M source code

результаты практически не отличаются. некоторое превышение 7z наверное связано с тем, что он использует в несколько раз больше памяти (т.к. по умолчанию жмёт в несколько потоков), ну а чем больше памяти, тем лучше сжатие. А вообще странно: как может более старый алгоритм LZMA жать лучше чем LZMA-2? зачем тогда придумали №2?
с bzip2 ясно - 7Мб это не о чём, по сравнению с сотнями Мб 7z, xz... Ну куда с таким блоком в неполных 900К?!

На чём основано данное предположение?

запустите игрушку под wine, она работать будет, но медленно.
точно так-же и здесь. Хотя это предположение, возможно в Linux лучше работа с памятью (а она лучше), за счёт чего некоторые архиваторы будут работать даже быстрее (на некоторых файлах).

tar.gz 106120786 21.8 50.5
zip 114070861 24.0 45.9

[quote name='Luinnar' date='14th January 2010 - в 18:37' post=1003090]
что-то не так: время извлечения по этому алгоритму должно быть МЕНЬШЕ. наверное это из-за медленной записи на диск (при извлечении писать нужно больше в разы).

[NickLion]

Кстати, а как переводитьсяв xz "run-length encoder chunk size" (застрял на этом когда клепал перевод)?

Ну, "классически" можно перевести как "размер порции кодировщика длин серий".

[drBatty]

Ну, "классически" можно перевести как "размер порции кодировщика длин серий".

ну так и я-бы перевёл. а теперь объясните что вы написали
(учитывая, что название "кодировщик длин серий" это название одного из самых простых алгоритмов сжатия, и оно здесь похоже не причём)

[/dev/random]

(учитывая, что название "кодировщик длин серий" это название одного из самых простых алгоритмов сжатия, и оно здесь похоже не причём)

RLE используется как промежуточная или подготовительная стадия в очень многих "сложных" алгоритмах сжатия, так что вполне возможно, что и "при чём".

[NickLion]

Ну, "классически" можно перевести как "размер порции кодировщика длин серий".

ну так и я-бы перевёл. а теперь объясните что вы написали
(учитывая, что название "кодировщик длин серий" это название одного из самых простых алгоритмов сжатия, и оно здесь похоже не причём)

Как ни при чём? В оригинале написано: RLE chunk size. Согласен, что не очень звучит, но что делать? Размер буфера, используемого кодировщиком.

[Flaming]

запустите игрушку под wine, она работать будет, но медленно.

Смотря что за игрушка.

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

Ну вот тут уже есть логика. Хотя мне всё равно кажется, разницы особой не будет.

[drBatty]

Как ни при чём? В оригинале написано: RLE chunk size. Согласен, что не очень звучит, но что делать? Размер буфера, используемого кодировщиком.

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

PS: сам алгоритм очень прост:
если встретилось 100 шестёрок мф пишем "100", а потом "6", распаковщик размножает эти байты обратно в 100 шестёрок. Куда там вставить "размер куска" - не понимаю...

[drBatty]

запустите игрушку под wine, она работать будет, но медленно.

Смотря что за игрушка.

у меня почти все работали медленнее.

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

Ну вот тут уже есть логика. Хотя мне всё равно кажется, разницы особой не будет.

логика есть... пускай кто-нибудь проверит, у меня венды нет.
хотя это ещё будет зависеть от скорости записи/чтения на диск, а может и ещё от чего-то...

[Schlecht]

Кстати, пользуясь случаем - не подскажете, в чём проблема с Q7Z? Не стартует, зараза...

Код: Выделить всё

greg@linux-op42:~> Q7Z.pyw
Traceback (most recent call last):
  File "/usr/bin/Q7Z.pyw", line 14, in <module>
    import      Main
  File "/usr/share/Q7Z/Source/Main.py", line 49, in <module>
    uiMain.setupUi(mwMain)
  File "/usr/share/Q7Z/Source/Ui_Main.py", line 774, in setupUi
    self.retranslateUi(Main)
  File "/usr/share/Q7Z/Source/Ui_Main.py", line 841, in retranslateUi
    self.cbAlgorithm.addItem(icon,QtGui.QApplication.translate("Main", "7-Zip", None, QtGui.QApplication.UnicodeUTF8))
NameError: global name 'icon' is not defined
greg@linux-op42:~>

Спасибо.

[NickLion]

Как ни при чём? В оригинале написано: RLE chunk size. Согласен, что не очень звучит, но что делать? Размер буфера, используемого кодировщиком.

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

ХЗ... Возможно сообщение бьется на чанки фиксированного размера и каждый обрабатывается отдельно - для возможности параллельной обработки. А RLE может использоваться для предварительной подготовки, уже говорили... Может что-то и меняли, но название ведь не изменилось, так что...

PS я знаю, как RLE работает, знаю, что толку от него почти 0 (ну, разве что BMP малоцветные сжимать - тогда толк есть)

[/dev/random]

Кстати, пользуясь случаем - не подскажете, в чём проблема с Q7Z? Не стартует, зараза...

Код: Выделить всё

greg@linux-op42:~> Q7Z.pyw
[...]
NameError: global name 'icon' is not defined

Известный баг в py-qt4. Присутствовал всего в нескольких минорных версиях, но как назло, именно они попали во многие дистрибутивы. Решение одно: обновить py-qt4.

[drBatty]

ХЗ... Возможно сообщение бьется на чанки фиксированного размера и каждый обрабатывается отдельно - для возможности параллельной обработки. А RLE может использоваться для предварительной подготовки, уже говорили...

возможно. но RLE и так быстро работает (по сравнению с остальным)...

PS я знаю, как RLE работает

я знаю, что вы знаете это объяснение не для вас.

знаю, что толку от него почти 0 (ну, разве что BMP малоцветные сжимать - тогда толк есть)

только-что рядом было обсуждения файлов в 50Гб от dd, в которых 45Гб нулей

[Schlecht]

[Известный баг в py-qt4. Присутствовал всего в нескольких минорных версиях, но как назло, именно они попали во многие дистрибутивы. Решение одно: обновить py-qt4.

Cпасибо, щас попробую...
UPD. Последняя версия стоит - в репах новее нет...