LINUX.ORG.RU

 ← 1 2 →
Ответ на: комментарий от Deleted

Вот примерно это и хотел услышать. Надо жать много и сильно. Осталось решить, что важнее. Но процессоры сейчас дешевы.

namezys ★★★★
() автор топика
Ответ на: комментарий от devl547

Эээ, вероятно, я путаю с pixz. Развелось, понимаешь ли, клонов.

Homura_Akemi ★
()

gzip быстрее, жрёт меньше памяти и жмёт хуже.

xz ещё медленнее bzip2, жрёт НАМНОГО больше памяти, работает НАМНОГО медленнее, но жмёт несколько лучше bzip2 (не всегда).

ЗЫЖ по дефолту у gzip средняя компрессия(-6), а у bzip2 максимальная(-9). Учти, когда будешь сравнивать.

drBatty ★★
()
Ответ на: комментарий от namezys

Ну если только из двух в ОП, то однозначно bzip2. gzip очень слабо жмёт.

Homura_Akemi ★
()
Ответ на: комментарий от namezys

Надо жать много и сильно. Осталось решить, что важнее

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

drBatty ★★
()
Ответ на: комментарий от namezys

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

xz и lzma - это утилиты, реализующие тот же алгоритм сжатия, который используется в 7zip. Плюсы: очень хорошо жмёт. Минусы: жмёт медленно и при этом требует много памяти. Распаковка в принципе достаточно быстрая, но расход памяти тоже зависит от степени сжатия (хоть памяти потребляется и меньше, чем при сжатии).

ИМХО лучший вариант: прогнать все доступные запаковщики/распаковщики на тестовых образцах тех данных, которые нужно жать, а потом выбрать тот вариант, который лучше всего подойдёт по коэффициенту сжатия, скорости работы и потреблению ресурсов.

Deleted
()
Ответ на: комментарий от Deleted

Придется делать. Правда я еще с сериализатором не решился. Раньше pickle был из питона. Но он уже очень не оптимален

namezys ★★★★
() автор топика
Ответ на: комментарий от YAR

А в параллельной версии вполне могут быть и десятки гигов :)

ИЧСХ параллельная версия ничем не лучше. Ибо скорость упирается в память, память не кешируется, и память _одна_.

drBatty ★★
()
Ответ на: комментарий от namezys

Памяти там десятки гигов. Только жать надо тоже десятки гигов. И память там много кто хочет

тогда xz, если что, там есть memory limit.

drBatty ★★
()

Если ядер много, то я выберу bzip2 в распараллеленном исполнении — pbzip2. В силу алгоритма обработки, bzip2 превосходно размножается на любое количество ядер, при этом скорость обработки и кол-во потребляемой памяти растут почти линейно.

Наскольно мне известно, для предлагаемого здесь xz нет готовой распараллеленной версии.

Для gzip есть pigz, но в силу особенностей алгоритма, от распараллеливания страдает эффективность сжатия, да и выигрыш в скорости далеко не линеен.

uuwaan ★★
()
Ответ на: комментарий от x3al

xz быстрее bzip2 на распаковке.

не факт. xz конечно быстрее на распаковке, но и bzip2 быстрее. Зависит от фазы луны. Там _очень_ разные алгоритмы.

Если пакуется один раз, а распаковывается много — bzip2 не нужен.

если памяти до дури при упаковке - согласен. Но памяти много не бывает, а процесс сжатия не быстрый... Потому часто лучше пожертвовать 5% сжатия, и сэкономить. Но решать не мне конечно.

drBatty ★★
()
Ответ на: комментарий от namezys

Только жать надо тоже десятки гигов

Каждую ночь xz -9 жмёт около 40-50 гигов на «сервере» слабее топовых планшетов, с 2Gb DDR RAM. Брат жив.

redgremlin ★★★★★
()
Ответ на: комментарий от bl

но пришел к выводу что лучше всех - rar (даже под вайном)

о да... Алгоритмы, которым 20 и 40 лет конечно покруче будут. Математики последние 40 лет МПХ пинали...

drBatty ★★
()
Ответ на: комментарий от uuwaan

Если ядер много, то я выберу bzip2 в распараллеленном исполнении — pbzip2. В силу алгоритма обработки, bzip2 превосходно размножается на любое количество ядер

если к «любому количеству ядер» у тебя есть 7600К кеша КАЖДОМУ ядру(для --best) - да. И размножать надо на физические ядра, а не на HT.

Наскольно мне известно, для предлагаемого здесь xz нет готовой распараллеленной версии.

есть. только нет CPU, у которых для _каждого_ ядра гигабайты памяти. А в сжатии математики особой нет, поиск/сортировка...

Для gzip есть pigz, но в силу особенностей алгоритма, от распараллеливания страдает эффективность сжатия

оно потоковое, а не блочное. впрочем как и LZMA(xz).

drBatty ★★
()
Ответ на: комментарий от namezys

1) Так мой «сервер» и не всю ночь на 40гиг тратит, часа 2.5 где-то
2) Доки говорят, что xz -9 сожрет 670Мб, что на «десятках гигов» оперативы - плюнуть и растереть.

redgremlin ★★★★★
()
Ответ на: комментарий от YAR

У меня оно упиралось в процессор

откуда ты знаешь, КУДА оно упиралось? Да, штрафные такты при работе процессора с памятью. Потому-что все твои ядра ВНЕЗАПНО полезли в память (не в свой кеш!), а память одна. И шина одна. Вот стоят и ждут. С виду - CPU тупит.

drBatty ★★
()
Ответ на: комментарий от redgremlin

2) Доки говорят, что xz -9 сожрет 670Мб, что на «десятках гигов» оперативы - плюнуть и растереть.

чё??

man xz:

Memory usage The memory usage of xz varies from a few hundred kilobytes to several gigabytes depending on the compression settings. The settings used when compressing a file determine the memory requirements of the decompressor. Typically the decompressor needs 5 % to 20 % of the amount of memory that the compressor needed when creating the file. For example, decompressing a file created with xz -9 currently requires 65 MiB of memory. Still, it is possible to have .xz files that require several gigabytes of memory to decompress.

IRL есть такое правило - чем лучше пакует, тем больше жрёт. 500..1000Гб сожрать может легко. Я-бы рассчитывал как минимум на 2Гб. Да и memlimit на компрессию поставил-бы на всякий. А то рухнуть может...

drBatty ★★
()
Ответ на: комментарий от drBatty

чё??

То:

man xz

The following table summarises the features of the presets:

                     Preset   DictSize   CompCPU   CompMem   DecMem
                       -0     256 KiB       0        3 MiB    1 MiB
                       -1       1 MiB       1        9 MiB    2 MiB
                       -2       2 MiB       2       17 MiB    3 MiB
                       -3       4 MiB       3       32 MiB    5 MiB
                       -4       4 MiB       4       48 MiB    5 MiB
                       -5       8 MiB       5       94 MiB    9 MiB
                       -6       8 MiB       6       94 MiB    9 MiB
                       -7      16 MiB       6      186 MiB   17 MiB
                       -8      32 MiB       6      370 MiB   33 MiB
                       -9      64 MiB       6      674 MiB   65 MiB

Т.е. xz -9 будет жрать примерно 674. Естественно, что ручками выставив dict=1536M mf=bt4, можно заставить жрать 10.5*1536, т.е. 16128Мб

redgremlin ★★★★★
()
Последнее исправление: redgremlin (всего исправлений: 1)

bzip2, потому что в 90% случаев сжимает лучше. Но lzma/xz ещё лучше, но сжатие у него медленное. Я пытался заархивировать домашний каталог и думал, за сутки заархивируется. Сначала скорость была 2 Мб/сек, но через несколько часов упала до 130 кб/сек. постепенно снижаясь до 110 кб/сек. И я выключил архивацию.

Причина в том, что дублирующиеся куски данных видны lzma. Например архив с программой Jimm на официальном сайте занимает 6 Мб в RAR и 1 Мб в 7zip. Потому что там много папочек с jar-файлами для разных моделей телефонов, но многое дублируется. Вот проверка на то, дублируются ли данные, и приводит к постепенному замедлению скорости создания архива.

А если скорость критична, то zip и gzip лидируют. У меня на старом Siemens даже Opera Mini им сжимает.

ZenitharChampion ★★★★★
()
Ответ на: комментарий от uuwaan

в распараллеленном исполнении — pbzip2

я проверял lbzip2 работает немного быстрее чем pbzip2

http://www.linux.org.ru/news/opensource/7907280?cid=7916348
bzip2  -- 33 sec, cpu  99%
pbzip2 -- 13 sec, cpu 391%
lbzip2 --  8 sec, cpu 387%
sdio ★★★★★
()
Последнее исправление: sdio (всего исправлений: 2)
Ответ на: комментарий от ZenitharChampion

Ну скажем разница на 20% при разнице в скорости раза 2 уже однозначно говорит мне, что пусть меньше, но быстрее

namezys ★★★★
() автор топика
Ответ на: комментарий от redgremlin

То:

это ориентировочная таблица. IRL у мну жрал почти гиг...

Т.е. xz -9 будет жрать примерно 674. Естественно, что ручками выставив dict=1536M mf=bt4, можно заставить жрать 10.5*1536, т.е. 16128Мб

я ничего не ставил. может баг какой...

drBatty ★★
()
Ответ на: комментарий от ZenitharChampion

Сначала скорость была 2 Мб/сек, но через несколько часов упала до 130 кб/сек. постепенно снижаясь до 110 кб/сек. И я выключил архивацию.

очевидно памяти не хватило.

gzip лидируют. У меня на старом Siemens даже Opera Mini им сжимает.

gzip в стандарте. им даже IE разжимает странички.

drBatty ★★
()
Ответ на: комментарий от quantum-troll

Rar быстрее жмёт, но дольше распаковывает, так что всё зависит от задачи.

ЛПП

rar использует гибридный алгоритм - там LZ78 и PPMD. оба - УГ мамонта. PPMD доставляет тем, что жрёт немеренно памяти как при распаковке, так и при упаковке. Ну «немеренно» для своих 90х годов прошлого века. Мой друг помню плакал - на его компе мой архив не распаковался. Памяти не хватило. Пришлось везти через весь Питер ещё раз.

drBatty ★★
()
Ответ на: комментарий от zolden

есть альтернативы?

LZMA в большинстве случаев даёт лучший результат. В принципе и BWT из bzip2 даёт результат обычно немногим хуже rar'а (несколько %%), а иногда лучше. Это по сжатию. По остальным характеристикам rar suxx.

PPMD при сжатии текста всё ещё круче всех

может сравнишь?

drBatty ★★
()

В своё время для своих данных выяснял и пришел к формуле xz -2

Жрет не так уж много памяти ~60-80Мб, для меня критично, но зато получается быстрее и сильнее чем bzip2 -9

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 →
Admin