» FreeArc: бесплатный open-source архиватор

Цитата:

Если надо более точно подобрать значение - скажи

да, посмотри плиз


Цитата:

Правильное сокращение для обозначения килобайта - kB, а мегабайта - MB

там где скорость - исправил. там где объёмы памяти показываются, попробовал - не порнравилось и вернул назад:

Memory for compression 112MB, decompression 64MB, cache 16MB
Compressed 2 files, 2.933.042 => 733.045 bytes. Ratio 24.9%
Compression time 6.82 secs, speed 430 kB/s. Total 7.92 secs

кроме того, добавлено:
* lzma по умолчанию = lzma:64m:ht4
* -m4 вместо rep:64m+lzma:8m:bt4 теперь использует lzma:64m:ht4:mc16 (аналогично изменению в -m3)
* в lzma добавлен параметр :h, позволяющий изменять размер хеша (для ht4, по умолчанию dict/2) или заголовка хеша (для hc4/bt4, по умолчанию dict*2). изменением этого параметра можно ускорить поиск или наоборот, чуть уменьшить требования к памяти

ловите очередной http://www.haskell.org/bz/arc1.arc

Добавлено:
программа снова обновлена. плиз проверьте работу с 1gb и если не получится - с какого размера словаря оно начинает работать?


Цитата:

Прогресс распаковки показывает с шагом 46,2 %

да, индикатор прогресса обновляется по размеру словаря, т.е.е раз в 1гб в данном случае. как-нить поправлю

Добавлено:
ps: старую версию соответственно тестировать уже незачем

Bulat_Ziganshin

Цитата:

ловите очередной http://www.haskell.org/bz/arc1.arc

Цитата:

программа снова обновлена. плиз проверьте работу с 1gb и если не получится - с какого размера словаря оно начинает работать?

затыкаются в одном и томже месте, как память выделенная заканчивается (1.5Гб), так прогресс останавливается, но процессор остаётся загруженным.

Allocated 1562 mb, addr=10010000
Allocated 234 mb, addr=015D0000

ARC.EXE a a -mlzma:1gb:fast:ht4:mc4 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.02 secs
Using lzma:1gb:fast:ht4:32:mc4
Memory for compression 1536mb, decompression 52.4%

ARC.EXE a a -mlzma:1gb:ht4:mc64 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.02 secs
Using lzma:1gb:normal:ht4:32:mc64
Memory for compression 1536mb, decompression 52.4%


Цитата:

программа снова обновлена. плиз проверьте работу с 1gb и если не получится - с какого размера словаря оно начинает работать?

с ARC.EXE от 14.05.08 15:14 работал 1023m упаковывал\распаковывал

Добавлено:
а ARC.EXE от 14.05.08 18:07 затыкается

Compressing 1 file of 2.046.033.507 bytes: 0.02 secs
Using lzma:1023mb:fast:ht4:32:mc4
Memory for compression 1535mb, decompression 52.4%

Насколько понял там где 1.5xdict используется, там и косячит:

Compressing 1 file of 2.046.033.507 bytes: 0.03 secs
Using lzma:980mb:fast:ht4:32:mc4
Memory for compression 1492mb, decompression 50.2%

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

итак, новая версия выложена на другой сайт http://freearc.narod.ru/arc1.arc
* lzma:1gb:ht4 должен наконец заработать (проверьте, плиз!)

Bulat_Ziganshin

Цитата:

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

итак, новая версия выложена на другой сайт http://freearc.narod.ru/arc1.arc
* lzma:1gb:ht4 должен наконец заработать (проверьте, плиз!)

ды не в размере словаря дело, а в новом 1.5xdict

ARC.EXE a a -mlzma:1gb:ht4 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.03 secs
Using lzma:1gb:normal:32
Memory for compression 1536mb, decompression 52.4%

новая версия http://freearc.narod.ru/arc1.arc
* в режимах -m3/-m4 создаёт архивы, совместимые с 0.40

кстати говоря, 0.40 архивы с lzma словарём >256mb принципиально не способна распаковывать


Цитата:

с ARC.EXE от 14.05.08 15:14 работал 1023m упаковывал\распаковывал

Цитата:

а ARC.EXE от 14.05.08 18:07 затыкается

буду думать

Добавлено:

Цитата:

ды не в размере словаря дело, а в новом 1.5xdict

да, верно. я пытался подобрать кое-какие параметры, чтобы оно работало с 1.5х, но пока что все работоспособные варианты были, видимо, именно с 1.75x. придётся вернуться к нему пока я не разберусь лучше в lzma

Добавлено:
http://freearc.narod.ru/arc1.arc - последняя попытка

на этот раз вашему вниманию представлены целых четыре версии - от 1537m до 1792m. итак, какой наименьший объём памяти достаточен для lzma:1gb?! я затаил дыхание

Bulat_Ziganshin

Цитата:

http://freearc.narod.ru/arc1.arc - последняя попытка

на этот раз вашему вниманию представлены целых четыре версии - от 1537m до 1792m. итак, какой наименьший объём памяти достаточен для lzma:1gb?! я затаил дыхание

Работают все, но Arc1537m.exe медленно, точнее первый гиг окучивает быстро, далее медленно.

Arc1792m.exe a a -mlzma:1gb:fast:ht4 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.02 secs
Using lzma:1gb:fast:32
Memory for compression 1792mb, decompression 99.9%
Solid block compression results (292.625 seconds)
lzma:1gb:fast:32: 30.317.715 bytes in 292.625 seconds

Writing directory: 323.13 secs
Found 1 directory names: 323.13 secs
Directory written: 323.1
Compressed 1 file, 2.046.033.507 => 30.317.715 bytes. Ratio 1.4%
Compression time 292.63 secs, speed 6.992 kB/s. Total 323.14 secs


Arc1600m.exe a a -mlzma:1gb:fast:ht4 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.02 secs
Using lzma:1gb:fast:32
Memory for compression 1600mb, decompression 99.9%
Solid block compression results (309.547 seconds)
lzma:1gb:fast:32: 30.317.715 bytes in 309.547 seconds

Writing directory: 338.42 secs
Found 1 directory names: 338.44 secs
Directory written: 338.4
Compressed 1 file, 2.046.033.507 => 30.317.715 bytes. Ratio 1.4%
Compression time 309.55 secs, speed 6.610 kB/s. Total 338.45 secs


Arc1552m.exe a a -mlzma:1gb:fast:ht4 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.02 secs
Using lzma:1gb:fast:32
Memory for compression 1552mb, decompression 99.9%
Solid block compression results (372.516 seconds)
lzma:1gb:fast:32: 30.317.715 bytes in 372.516 seconds

Writing directory: 400.89 secs
Found 1 directory names: 400.89 secs
Directory written: 400.8
Compressed 1 file, 2.046.033.507 => 30.317.715 bytes. Ratio 1.4%
Compression time 372.52 secs, speed 5.492 kB/s. Total 400.91 secs


Arc1537m.exe a a -mlzma:1gb:fast:ht4 -di+$#% enwikinews-20060927-pages-meta-history.xml

Compressing 1 file of 2.046.033.507 bytes: 0.00 secs
Using lzma:1gb:fast:32
Memory for compression 1537mb, decompression 99.9%
Solid block compression results (1580.281 seconds)
lzma:1gb:fast:32: 30.317.715 bytes in 1580.281 seconds

Writing directory: 1603.20 secs
Found 1 directory names: 1603.20 secs
Directory written: 1603.2
Compressed 1 file, 2.046.033.507 => 30.317.715 bytes. Ratio 1.4%
Compression time 1580.28 secs, speed 1.295 kB/s. Total 1603.22 secs

да, похоже что-то я опять недопонимаю в этой жизни обрати внимание, все версии тормозят по сравнению с первой. это происходит копирование гигабайта данных каждые 256/64/16/1 мб. ну и какую из них выберем?

Bulat_Ziganshin

Цитата:

да, похоже что-то я опять недопонимаю в этой жизни обрати внимание, все версии тормозят по сравнению с первой. это происходит копирование гигабайта данных каждые 256/64/16/1 мб. ну и какую из них выберем?

за более быстрый, или сделать настройку (выбор) между первыми тремя вариантами (256/64/16, или более плавный, или произвольный в пределах).

встречайте новую альфа-версию! http://www.haskell.org/bz/FreeArc-0.50-win32-alpha-2008-05-15.exe

Главные изменения по сравнению с предыдущей альфа-версией от 8 февраля:
* Улучшено авто-определение типов файлов
* Улучшены режимы сжатия -m3/m4
* Появилась зачаточная поддержка скриптов на Lua (см. каталог scripts)
* -di+% для вывода на экран статистики по памяти
* Настройки lzma по умолчанию изменены; добавлен matchfinder ht4, позволяющий
создавать архивы со словарём до 1гб; параметр :h позволяет изменять размер хеша
* GUI: Научили понимать кнопку BackSpace для возврата на уровень выше



Цитата:

за более быстрый

так и сделал

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

Bulat_Ziganshin

Цитата:

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

Ага, в связи с этим есть вопрос/предложение.

Версия 0.50 - даёшь GUI!

* .........
* доделать archive recovery, чтоб было не хуже чем в rar

Версия 0.80

* ..........
* Reed-Solomon codes for data recovery

Может есть смысл сразу делать data recovery на основе Рида-Соломона, а не в два этапа ? Потому что на момент появления многотомных архивов в 0.60 уже хотелось бы иметь полноценное восстановление данных.

Цитата:

Потому что на момент появления многотомных архивов в 0.60 уже хотелось бы иметь полноценное восстановление данных.

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

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

Добавлено:

Цитата:

если кто готов готовую схему защиты предложить - реалихзовать её будет несложно

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

Для меня самое главное это SFX! После стабильности конечно же. Чтоб запустил и распаковал, без всяких батников и PeaZIP'ов + возможная проблема несовместимости разных версий.

Цитата:

Для меня самое главное это SFX

к сожалению, у разных людей разные приоритеты

перенёс в планах реализацию кодов Рида-Соломона назад в 0.60. заюзать такую библиотеку - само по себе будет несложно. сложности только в изменении формата recovery record обеспечивающем бронебойное восстановление какая бы часть архива ни была повреждена

Bulat_Ziganshin

Цитата:

Для меня самое главное это SFX

Цитата:

к сожалению, у разных людей разные приоритеты

SFX нужен для продвижения FreeArc в массы, иначе массы крайне не понятливые.

Цитата:

к сожалению, у разных людей разные приоритеты

До конца года с SFX управитесь?


Цитата:

SFX нужен для продвижения FreeArc в массы, иначе массы крайне не понятливые.

Ох... некоторые до сих пор 7-zip'у предпочитают WinRAR, а тут FreeArc. SFX реально нужная вещь. Без него популяризация архиватора пострадает.

Bulat_Ziganshin

Цитата:

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

Первое, что приходит в голову - поступать с управляющей информацией, как когда-то поступала DOS с FAT, т.е. хранить две копии в разных местах. Например, одну вначале архива/тома, а вторую - в конце.

Цитата:

До конца года с SFX управитесь?

надеюсь я думаю, это примерно неделя чистой работы

Добавлено:

Цитата:

т.е. хранить две копии в разных местах

ага. и если повредить два байта, то она тоже окажется ненужной. ероме того, есть ещё вопрос поддержки очень больших архивов - скавжем на архив в 10 гб может сохраняться 100 мб recovery info. сейчас она вся хранится в памяти и записывается в конец архива, а нужно как-то разбивать её на части

В принципе, для надежности, можно дополнительно создавать еще один файл, но ТОЛЬКО с рековери информацией. На манер гибридного режима с коррекционным файлом в WavPack'e

это не имеет никакой приницпиальной разницы по сравнению с сохранением той же информации в архиве

Если в архиве повреждена _только_ управляющая информация кодов восстановления, то ... и восстанавливать, в общем-то, ничего не нужно.
Да и у самих кодов ведь есть предел количества восстановимых ошибок.

Еще, как дополнение к хранению двух копий, можно попробовать генерировать информацию для восстановления самого блока восстанавливающих кодов. Т.е. получится двухуровневая система. И чем выше уровень, тем меньше объем этой самой информации.
Т.е. например при 10% для 100MB можно получить:
- 100MB - data
- 9MB - recovery level 1 (for data)
- 900kB - recovery level 2 (for recovery 1)
- 90kB - recovery level 3 (for recovery 2)
- 9kB - recovery level 4 (for recovery 3)
----
total: ~110MB

И, очевидно, переход к следующему уровню восстановления осуществляется только в том случае, если на предыдущем обнаружены ошибки.

Правда, может, с точки зрения математики, все эти навороты - полная чушь? И никакого особого выигрыша в востановлении не дают?

Bulat_Ziganshin
Архивации большого количества файлов с длинными именами в планах вообще нет - или после 0.8 ?

Цитата:

Если в архиве повреждена _только_ управляющая информация

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


Цитата:

И, очевидно, переход к следующему уровню восстановления осуществляется только в том случае, если на предыдущем обнаружены ошибки.

Правда, может, с точки зрения математики, все эти навороты - полная чушь?

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

насколько я понимаю, основная идея надёжного восстановления данных - мы вам гарантируем восстановление при порче *любых* 1% (к примеру) секторов арзива

Добавлено:

Цитата:

Архивации большого количества файлов с длинными именами в планах вообще нет - или после 0.8 ?

это в планах вероятно на 0.6. у меня в планах несколько сотен пунктов, сюда вынесены только наиболее важные

Цитата:

повреждены эти 10 доп. мегабайт плюс один байт из первых 100 мб

так это ведь выходит уже больше тех самых "любых 10%"
а если точнее, 10% + 1 байт

на самом деле, чтобы сделать архив не подлежащим восстановлению
достаточно повредить некоторый процент + 1 байт на каждом уровне, кроме первого, ну и, соответственно, что-нть в самих данных
что, наверное, будет гораздо меньше 10% в сумме

но, насколько я понимаю, в том же winrar при добавлении 10% избыточности, не гарантируется восстановление при повреждении 10% - т.е. пользователь управляет размером архива, а не "границей восстановимости" (которая будет, очевидно, в несколько раз меньше размера избыточности)

Цитата:

так это ведь выходит уже больше тех самых "любых 10%"

нет. архив 10 гб, инфа для восстановления 111 мб


Цитата:

насколько я понимаю, в том же winrar

в том-то и дело, что rar - не пример для подражания. так, как в rar, у меня уже сделано. надо ориентироваться на программы с RS кодами типа iceecc

Bulat_Ziganshin
Из комментариев на форуме ICE ECC:

Цитата:

100 блоков по 1 метру могут восстановить далеко не каждые 100 мегабайт потерь, а лишь такие ошибки, которые покрываются нужным паттерном, которые можно покрыть 100 отрезками по 1 метру.
стало быть, существуют такие 101 бит (именно бит, а не байт и не мегабайт) которые ECC не восстановит. Заметьте, не сто мегабайт, а 101 бит!!! Так что Рид-Cоломон никаких гарантий не дает.

sabio

Цитата:

Заметьте, не сто мегабайт, а 101 бит!!! Так что Рид-Cоломон никаких гарантий не дает.

Дык ведь задача не в создании "абсолютной" системы восстановления битых архивов. Это невозможно. Достаточно, чтобы в FA было надежнее, чем в WinRAR.

ещё раз повторю - используемая в iceecc схема гарантирует восстановление при потере любых 100 *блоков*. на магнитных носителях летят целые сектора, а не отдельные биты, так что это удовлетворительное решение

Добавлено:

Цитата:

Дык ведь задача не в создании "абсолютной" системы восстановления битых архивов. Это невозможно. Достаточно, чтобы в FA было надежнее, чем в WinRAR.

есть 2 задачи:
1. заюзать РС для увеличения надёжности восстановления. сейчас достаточно запороть всего два блока, находящихся на расстоянии N друг от друга, где N - объём recovery record, чтобы восстановление стало невозможным. afaik та же фигня и в rar. использование РС позволит восстановить сбои в любых N блоках данных

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

ну и ещё есть 0. искать каталоги в сбойных архивах по сигнатуре, чтоб можно было вытянуть хотя бы уцелевшую часть архива. к RR это прямого отнощшения не имеет, но без этого восстановление архивов остаётся больше бумажной фичей

Добавлено:

Цитата:

SFX нужен для продвижения FreeArc в массы

перекинул это назад в планы на 0.50

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

1) добавить многопотчность для распаковки цепочек алгоритмов сжатия типа exe+lzma
2) сделать GUI-версию на чистом win api или какой-то leightweight библиотеке - сейчас есть только консольный sfx

каждая из этих задач при наличии соответствующей кваликации потянет, я думаю, дня на 3

Насчёт новых настроек lzma - потестировал немного, вот что вышло:

Исходные данные: образы игрушки и её же самой, но с аддоном. Разбиты на 6 равных кусков каждая, чтобы полные совпадения практически полностью влезли в словарь на 1000mb. Полный размер - 9 094 430 834 байт.

lzma:1000mb:max:ht4:mc32 - 3 298 916 060 .
Время сжатия - 17634.30 с, скорость 516 кб/с. Полное время - 19077.95 с.
Но при этом rep:128 выдаёт лучшие результаты (время не запомнилось - но оно
наверняка соответствует скоростьям 15-20 Мб/с):

rep:1000mb:128:h27 - 3 298 640 599
rep:1000mb:128:h27++rep:1000mb:128:h27:a99 - 3 121 331 796

Так что либо mc32 тут не хватает, либо rep:128:1000mb+lzma:max:bt4:192mb таки оказывается эффективней. Единственное что несколько мешает этому варианту, так это глюки выделения памяти с tempfile - к сожалению, такая цепочка не проходит, приходится делать двойной архив.

Кстати говоря, интересно, это заморочки 32-битных виндов, или для 64-битных систем что-нибудь вроде rep:1500mb+tempfile+rep:1500mb или rep:1500mb+tempfile+lzma:192mb:max пройдёт?

Далее,
rep:1000mb:128:h27++lzma:192mb:max - 2 679 724 040
rep:1000mb:128:h27++lzma:1000mb:max:ht4:mc32 - 2 568 654 628

(далее для упрощения буду вместо rep:1000mb:128:h27++rep:1000mb:128:h27:a99 писать rep:1000mb:128x2)

rep:1000mb:128x2++lzma:1000mb:max:ht4:mc32 - 2 532 449 817
rep:1000mb:128x2++lzma:192mb:max - 2 531 091 310

Так что выходит, на этих данных (т.е. после одного rep'а) rep:1000mb:128:h27++lzma:192mb:max чуть лучше rep:1000mb:max:ht4:mc32 .

А вот для самой последней версии я поигрался с настройкой :h - вот что вышло:
rep_1000mb_128x2++lzma:64mb:128:max:h1gb :

Compressed 1 file, 3.121.331.796 => 2.536.560.520 bytes. Ratio 81.2%
Compression time 4067.89 secs, speed 767 kB/s. Total 2740.00 secs

rep_1000mb_128x2++lzma:64mb:128:max

Compressed 1 file, 3.121.331.796 => 2.536.562.893 bytes. Ratio 81.2%
Compression time 4594.49 secs, speed 679 kB/s. Total 4615.69 secs

Так что за счёт такого увеличения расходуемой памяти размер хоть и почти не меняется, но ускорение заметное - в районе 13% для одного процессорного ядра, и целых 70% для двух ядер.

В связи с этим вопрос - каким образом выделяется память при использовании :h - нельзя ли сделать возможным выделить к 1 Гб словаря больше 512 mb хэша (ведь выходит, что выделяется dictsize*1.25+hashsize), если свободные блоки памяти - один на 1750 mb, другой - 750 mb? Ведь такая настройка должна заметно ускорить или даже улчшить сжатие при наличии 3 Гб памяти.

Цитата:

встречайте новую альфа-версию! http://www.haskell.org/bz/FreeArc-0.50-win32-alpha-2008-05-15.exe

закинул необходимые для работы win-версии библиотеки от GTK2Runtime (из дистрибутива gtk2-runtime-2.12.9-2008-03-18-ash.exe), получилась практически portable версия. Если кто сможет, сделайте прямую ссылку...
размер 3365 KB
http://rapidshare.com/files/115300834/FreeArc_0.50_win32_alpha_2008_05_15.7z
http://narod.ru/disk/342963000/FreeArc_0.50_win32_alpha_2008_05_15.7z.html

Ghost2004
спасибо за тесты. ht4 больше подходит для быстрых режимов сжатия, даже в -m4 использование его не всегда оправдано.

в принципе, он позволяет добиться высокого сжатия, но при этом очень медленно сжимает. это регулируется параметром mc - попробуй скажем mc256. вот один мой тест:

>arc a a dll700.dll -mexe+delta+lzma:48m:max
Compressed 1 file, 690.514.620 => 177.168.679 bytes. Ratio 25.6%
Compression time 2528.37 secs, speed 273 kb/s. Total 2882.80 secs

>arc a a dll700.dll -mexe+delta+lzma:256m:max:ht4:mc64
Compressed 1 file, 690.514.620 => 168.503.951 bytes. Ratio 24.4%
Compression time 6319.67 secs, speed 109 kb/s. Total 7032.06 secs

>arc a a dll700.dll -mexe+delta+lzma:256m:max:ht4:mc256
Compressed 1 file, 690.514.620 => 169.203.910 bytes. Ratio 24.5%
Compression time 19116.82 secs, speed 36 kb/s. Total 21471.30 secs

конечно, пока это не имеет большого практического значения. в будущем я собираюсь сделать более быстрый matchfinder с тем же протребелнием памяти. тогда -mx во freearc сможет реально использовать словарь в 1гб с приличной скоростью и хорошим сжатием


Цитата:

В связи с этим вопрос - каким образом выделяется память при использовании :h - нельзя ли сделать возможным выделить к 1 Гб словаря больше 512 mb хэша

так делай: -mlzma:1g:h1g. хэш в два гига пока использовать нельзя, но в вбудущем я собираюсь это реализовать


Цитата:

(ведь выходит, что выделяется dictsize*1.25+hashsize),

не совсем так. :max переключает на bt4 match finder, при этом :h регулирует размер звголовка хеша, который по умолчанию =dictsize, т.е. 64mb в данном случае. и ты его увеличил в 16 раз

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