» FreeArc (часть 4)

egor23

Цитата:

косяк, уберите 7z.dll

а профиль по умолчанию жмёт нормально

UriF
записал в планы на 0.75, заодно и wavpack делать придётся. кстати, имей в виду - там только распаковка

Цитата:

косяк, уберите 7z.dll

я ж это в последней альфе поправил. volt_m, у тебя какая версия?


Цитата:

настройки сжатия FreeArcа, чтобы сжимало ОЧЕНЬ хорошо

профиль максимального сжатия. остальное подбирается индивидуально под данные

Добавлено:
Profrager
спасибо, интересная идея

У меня архив проходит тестирование, но при распаковке происходит ошибка. Это ведь не нормально? (FA 0.67a)

Цитата:

профиль максимального сжатия. остальное подбирается индивидуально под данные

Я ставлю ультра. Но всё ровно как-то плохо сжимает =( я в этом новичок. Может покажите скрин своих настроек? как образец будет мне =)

vishyakov
а у меня подпольный стук

vishyakov
Т. е. не молчите, скажите больше существенных (с вашей точки зрения) подробностей: какая ошибка, как часто появляется, как возможно её воспроизвести (подробно), какой архив и можете ли вы его приватно выложить Булату.

Bulat_Ziganshin
666
попробую альфу
--------------------

работает

Цитата:

Я ставлю ультра. Но всё ровно как-то плохо сжимает =( я в этом новичок. Может покажите скрин своих настроек? как образец будет мне =)

А может, покажете, что сжимаете?
Если что-нибудь несжимаемое, то и не получится.

Может быть воспользоваться сверхплотными архиваторами?
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=740#2
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=740#5

new alpha version:

-mc option: new ways to modify compression method by adding/replacing/removing specified algorithms
Compression page: added "Experimental compressors" frame
arc.ini: updated for precomp042/srep3 compatibility
precomp 0.4.2 and srep 3.0 executables added to the FreeArc\bin directory


Цитата:

New syntax of -mc option (backward-compatible with the old one):

-mc[GROUPS][:]OPERATION

where GROUPS may be empty or list of compression groups, where '$default' means the default group. Examples are:

$obj
$default
$default,$obj

Optional ':' is just a syntax sugar

OPERATION may be one of the following:

'-$group' or '$group-' means "remove $group from compression definition"
'-method' or 'method-' means "remove method from compression definition". RAR-compatible shortcuts like -mca- are also supported
'+method' or 'method+' means "add method at the head of every compression chain", f.e. -mc+precomp042:c-
'method1/method2' means "replace method1 with method2", f.e. -mc:rep/srep:mem256mb

GROUPS may be used to limit OPERATION to the specified groups, f.e. -mc$default,$obj:+precomp042:c-

--------------------------------------------------------------------------------------------------------------

Using these options, FreeArc implements "Exprerimental compressor" checkboxes in the following way:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/dispack070
srep: -mc:rep/srep:mem256mb
precomp: -mc$default,$obj:+precomp042:c-:t-j
intense: -mc$default,$obj:+precomp042:c-:intense:t-j
jpeg: -mc$default,$obj:+precomp042:c-
intense+jpeg: -mc$default,$obj:+precomp042:c-:intense

REP speed improvements:

REP: up to 4x faster due to multithreading and anchored hashing proposed by Eugene Shelwien
REP:c sets size of hashed chunks (f.e. rep:256:c256 is a quick-and-dirty replacement for rep:512)
REP: for rep:512..257/256..129/... default is :c128/64/...
REP: default hashsize = min(1/4,16/chunksize)*BlockSize


Цитата:

D:\>old_fazip rep:1g dll4g.dll nul
100%: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 358 mb/s, real 327 mb/s
D:\>new_fazip rep:1g:c256 dll4g.dll nul
100%: 4,531,060,447 -> 3,063,642,637: 67.61% Cpu 482 mb/s, real 1299 mb/s

D:\>old_fazip rep:1g:32 dll4g.dll nul
100%: 4,531,060,447 -> 2,245,307,773: 49.55% Cpu 117 mb/s, real 113 mb/s
D:\>new_fazip rep:1g:32:c16 dll4g.dll nul
100%: 4,531,060,447 -> 2,271,868,087: 50.14% Cpu 182 mb/s, real 274 mb/s

Improved method definitions:

-m1: added REP preprocessing (compression improved by 10-20%, speed remained the same thanks to the new ultra-fast REP engine)
-m1: removed separate $exe group in order to reduce number of disk seeks
-m2..m4: modified REP settings, utilizing new REP implementation in order to improve speed/compression ratio
-m3t/mex3t: modified so that compression runs slower but decompression is faster


Цитата:

D:\>old_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 435,620,877 bytes. Ratio 53.7%
Compression time: cpu 13.10 secs, real 1.76 secs. Speed 459,651 kB/s
D:\>new_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 369,825,442 bytes. Ratio 45.6%
Compression time: cpu 12.68 secs, real 1.84 secs. Speed 441,616 kB/s

D:\>old_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 354,958,875 bytes. Ratio 43.7%
Compression time: cpu 37.72 secs, real 5.41 secs. Speed 149,680 kB/s
D:\>new_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 353,083,639 bytes. Ratio 43.5%
Compression time: cpu 36.54 secs, real 5.11 secs. Speed 158,553 kB/s

D:\>old_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 340,430,540 bytes. Ratio 42.0%
Compression time: cpu 80.15 secs, real 12.00 secs. Speed 67,514 kB/s
D:\>new_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 338,976,484 bytes. Ratio 41.8%
Compression time: cpu 78.91 secs, real 11.33 secs. Speed 71,530 kB/s

D:\>old_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 326,333,902 bytes. Ratio 40.2%
Compression time: cpu 184.19 secs, real 24.19 secs. Speed 33,503 kB/s
D:\>new_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 324,126,352 bytes. Ratio 39.9%
Compression time: cpu 182.58 secs, real 24.01 secs. Speed 33,748 kB/s


D:\>old_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,840,442 bytes. Ratio 25.8%
Compression time: cpu 9.02 secs, real 1.58 secs. Speed 63,488 kB/s
Testing time: cpu 12.03 secs, real 2.14 secs. Speed 46,704 kB/s
D:\>new_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,221,121 bytes. Ratio 25.2%
Compression time: cpu 12.00 secs, real 2.18 secs. Speed 45,869 kB/s
Testing time: cpu 8.42 secs, real 1.61 secs. Speed 61,993 kB/s

Other changes:

CRC in arc/unarc/dll/sfx became 2x faster (500->1000 mb/s); CRC in facompress.dll still runs at 1600 mb/s
I/O: reading files to compress in 1mb chunks (optimized for Vista/Win7)
DICT: fixed bug with error -6 at end of decompression (detectable with -m=bcj+dict -t)
i18n: NEW Portuguese Standard translation by Nuno Rego!

ZEN369

Цитата:

Я ставлю ультра. Но всё ровно как-то плохо сжимает =( я в этом новичок. Может покажите скрин своих настроек? как образец будет мне =)

Для разных файлов разный подход, нет универсальных настроек. С такими вопросами тебе в эту тему http://forum.ru-board.com/topic.cgi?forum=5&bm=1&topic=30239#1

подскажите как изменить надписи
Press Ok button to start extraction.
Use Browse button to select the destination folder.
If the destination folder does not exist, it will be created automatically before extraction.
в sfx архиве на свои

и второй вопрос - какие оптимальные установки для упаковки ISO файлов

Цитата:

подскажите как изменить надписи

редактором ресурсов или опцией -z подцепить другой комментарий в формате RTF

Новая альфа-версия:
Опция -mc: позволяет изменить метод сжатия путем добавления/замены/удаления заданных алгоритмов
Страница сжатия: добавлена вкладка "Экспериментальные алгоритмы"
arc.ini: обновлен для совместимости с precomp042/srep3
Исполняемые файлы precomp 0.4.2 и srep 3.0 добавлены в директорию FreeArc\bin

Цитата:

Новый синтаксис опции -mc (обратно-совместимый со старым):

-mc[ГРУППЫ][:]ОПЕРАЦИЯ

где ГРУППЫ может быть пустым или содержать список групп файлов, причем '$default' означает группу по умолчанию. Примеры:
$obj
$default
$default,$obj

Опциональный символ ':' является разделителем

ОПЕРАЦИЯ может быть одна из следующих:
'-$group' или '$group-' означает "исключить $group при сжатии"
'-method' или 'method-' означает "исключить method при сжатии". RAR-совместимые команды, такие как -mca-, также поддерживаются
'+method' или 'method+' означает " добавить method в начало каждой цепочки сжатия", например -mc+precomp042:c-
'method1/method2' означает "заменить method1 на method2", например -mc:rep/srep:mem256mb

ГРУППЫ могут быть использованы для ограничения ОПЕРАЦИИ определенными группами файлов, например -mc$default,$obj:+precomp042:c-

--------------------------------------------------------------------------------------------------------------

Используя эти опции, FreeArc реализует чекбоксы "Экспериментальных алгоритмов" следующим образом:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/dispack070
srep: -mc:rep/srep:mem256mb
precomp: -mc$default,$obj:+precomp042:c-:t-j
intense: -mc$default,$obj:+precomp042:c-:intense:t-j
jpeg: -mc$default,$obj:+precomp042:c-
intense+jpeg: -mc$default,$obj:+precomp042:c-:intense

Улучшение скорости REP:
REP: ускорен в 4 раза благодаря многопоточности и надежному хешированию предложенному Евгением Шелвиным
REP:c устанавливает размер хешируемых блоков (например, rep:256:c256 это более быстрая, но менее аккуратная замена rep:512)
REP: для rep:512..257/256..129/... значения по умолчанию следующие :c128/64/...
REP: по умолчанию hashsize = min(1/4,16/chunksize)*BlockSize

Цитата:

D:\>old_fazip rep:1g dll4g.dll nul
100%: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 358 mb/s, real 327 mb/s
D:\>new_fazip rep:1g:c256 dll4g.dll nul
100%: 4,531,060,447 -> 3,063,642,637: 67.61% Cpu 482 mb/s, real 1299 mb/s

D:\>old_fazip rep:1g:32 dll4g.dll nul
100%: 4,531,060,447 -> 2,245,307,773: 49.55% Cpu 117 mb/s, real 113 mb/s
D:\>new_fazip rep:1g:32:c16 dll4g.dll nul
100%: 4,531,060,447 -> 2,271,868,087: 50.14% Cpu 182 mb/s, real 274 mb/s

Улучшения методов сжатия:
-m1: добавлен препроцессор REP (сжатие улучшилось на 10-20%, скорость осталась та же благодаря новому супер-быстрому движку REP)
-m1: удалена отдельная группа $exe, чтобы уменьшить кол-во перемещений головки диска при сжатии
-m2..m4: изменены настройки REP, используя возможности нового REP для улучшения скорости/сжатия
-m3t/mex3t: изменен таким образом, что сжатие идет дольше, но распаковка быстрее

Цитата:

D:\>old_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 435,620,877 bytes. Ratio 53.7%
Compression time: cpu 13.10 secs, real 1.76 secs. Speed 459,651 kB/s
D:\>new_arc a a -m1 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 369,825,442 bytes. Ratio 45.6%
Compression time: cpu 12.68 secs, real 1.84 secs. Speed 441,616 kB/s

D:\>old_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 354,958,875 bytes. Ratio 43.7%
Compression time: cpu 37.72 secs, real 5.41 secs. Speed 149,680 kB/s
D:\>new_arc a a -m2 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 353,083,639 bytes. Ratio 43.5%
Compression time: cpu 36.54 secs, real 5.11 secs. Speed 158,553 kB/s

D:\>old_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 340,430,540 bytes. Ratio 42.0%
Compression time: cpu 80.15 secs, real 12.00 secs. Speed 67,514 kB/s
D:\>new_arc a a -m3 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 338,976,484 bytes. Ratio 41.8%
Compression time: cpu 78.91 secs, real 11.33 secs. Speed 71,530 kB/s

D:\>old_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 326,333,902 bytes. Ratio 40.2%
Compression time: cpu 184.19 secs, real 24.19 secs. Speed 33,503 kB/s
D:\>new_arc a a -m4 MsOfficeBCJ.obj
Compressed 1 file, 810,411,321 => 324,126,352 bytes. Ratio 39.9%
Compression time: cpu 182.58 secs, real 24.01 secs. Speed 33,748 kB/s


D:\>old_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,840,442 bytes. Ratio 25.8%
Compression time: cpu 9.02 secs, real 1.58 secs. Speed 63,488 kB/s
Testing time: cpu 12.03 secs, real 2.14 secs. Speed 46,704 kB/s
D:\>new_arc a a -m3t -t enwik8
Compressed 1 file, 100,000,000 => 25,221,121 bytes. Ratio 25.2%
Compression time: cpu 12.00 secs, real 2.18 secs. Speed 45,869 kB/s
Testing time: cpu 8.42 secs, real 1.61 secs. Speed 61,993 kB/s

Остальные изменения:
CRC в arc/unarc/dll/sfx стал в 2 раза быстрее (500->1000 mb/s); для сравнения, CRC в facompress.dll имеет скорость 1600 mb/s
I/O: чтение файлов для сжатия блоками по 1мб (оптимизировано под Vista/Win7)
DICT: исправлен баг с ошибкой -6 в конце распаковки (появлялась при -m=bcj+dict -t)
i18n: НОВАЯ локализация: Португальский Стандартный от Nuno Rego!

(перевод Шегората)

FreeArc0,67а (18 марта 2011) Метод сжатия –mex7 Особенности Улучшения

Ранее я исследовал метод –mex5
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=280#6
Сейчас предлагаю результаты исследования –mex7.

Метод сжатия –mex7 полностью выглядит так:
rep:512mb+exe+delta+4x4:i0:lzma:16mb:normal:bt4:128, $obj => rep:512mb+delta+4x4:i0:lzma:16mb:normal:bt4:128, $text => dict:128mb:80%:l8192:m400:s100+lzp:160mb:92%:145:h23:d1mb+tempfile+4x4:t3:i0:b7mb:ppmd:16:384mb:c7mb, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 1420mb, decompression 1199mb, cache 256kb
(Требования к памяти зависят от процессора, в данном случае Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-
разрядная, ОЗУ 4 ГБ)

1)    Основной способ сжатия: rep:512mb+exe+delta+4x4:i0:lzma:16mb:normal:bt4:128
При этом параметром по умолчанию для LZMA является :h32mb:
2)    Можно его модифицировать в группах exe и $obj, указав :h64m:
rep:512mb+exe+delta+4x4:i0:lzma:16mb:h64m:normal:bt4:128
В моих тестах степень сжатия оставалась такой же, скорость сжатия увеличивалась примерно на 6%, но требуемая память немного увеличивалась, до 1548 МБ
3)    Альтернативное сжатие всех данных одним методом, без деления на группы:
-m7rep+xlzma:16m:h64m:max (что полностью записывается как
-mrep:512mb+4x4:lzma:16mb:h64m:normal:bt4:128)

Результаты сжатия этих трех вариантов, для одного из тестов, а именно http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=80#13 или http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=720#21
Метод    time: cpu  time: real  Размер архива    Memory Memory
for compression for decompression
1)      628 с    184.8 с    846 822 405    1420 mb    1199 mb
2)      588 c    174.9 c    846 822 238    1548 mb    1199 mb
3)      585 c    149.4 c    845 267 002    1604 mb    732 mb
Альтернативное сжатие без деления на группы получилось самым быстрым и самым сильным. (Памяти использует чуть больше из-за исключения параметра :i0:. При желании его можно добавить в строку.)
В стандартном варианете –mex7 деление на группы при сжатии, видимо уменьшает эффективность использования rep! Мне кажется, что деление на группы эффективно только на очень больших объемах данных?!

Подробности.
Справедливы только для метода сжатия lzma:…:bt4 (может задаваться в виде lzma:…:max)
Сокращенная запись lzma:16m означает lzma:16mb:h32mb
Зависимость от параметра «:h» (размер хеша)
для сжатия по методу вида –m7rep+exe+delta+4x4:lzma:16mb:h32m:max
Метод time: cpu  time: real  Размер архива Memory Memory
for compression for decompression
16m:h128m:max    599 с    179 с    845 250 025    1220 mb    740 mb
…:h64m:…     599 с    153 c    845 250 044    1612 mb    740 mb
…:h32m:…     641 c    163 c    845 250 196    1484 mb    740 mb
…:h16m:…     718 c    182 с    845 251 214    1420 mb    740 mb
…:h8m:…     831 c    211 с    845 250 912    1388 mb    740 mb
Отмечу, что при параметре :h128m: (и более) создавался tempfile, что приводило к заметному увеличению реального времени сжатия, при уменьшении требований к памяти. С точки зрения оптимального соотношения время/степень сжатия такие режимы я исследую отдельно, и выложу позже.
Отмечу так же, что строка 2 отличается от метода 3) в первой таблице наличием exe+delta. Это привело к увеличению времени 149 -> 153, но улучшению сжатия на 16 кб.

Общая характеристика метода –mex7
Метод отличается эффективностью, в основных режимах сжатия использует практически всю память и 4 потока, и если только позволяет объем ОЗУ, предпочтительней, чем методы –mex5, –mex6.

Булат
Просьба оценить мои результаты для использования в FreeArc.

i've set up Mercurial repository: http://source.freearc.org:8002/freearc/, although URL may be changed later

Каким параметром включить использование в ФА срепа вместо репа?

Добрый день, Bulat_Ziganshin
freearc.exe при архивировании с удалением файлов, иногда не выдает ошибки (в логе пишет "архив успешно создан"), удаляет что может (могут остаться пустые папки), но не переименовывает freearc1.tmp в "имя_архива.arc".
Возможно ли сделать удаление после переименования и с каким-нибудь прогресс-баром?
Прошу прощения за сумбурное изложение. Версия альфа от 23 ноября и от 5 февраля.

Цитата:

m7rep

на этот параметр ругается чего-то арк...

Bulat_Ziganshin

Экспериментирую с новой версией.

В методе -m1 при замене:
-m1 -mc:rep/rep:96m:64:c64 -mc:4x4/4x4:tor:3:2m:h128k
у меня обычно уменьшается время и улучшается сжатие, например:

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.
Compressed 1,026 files, 758,272,286 => 614,504,948 bytes. Ratio 81.0%
Compression time: cpu 30.90 secs, real 8.75 secs. Speed 86,655 kB/s

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1,026 files, 758,272,286 bytes.
Compressed 1,026 files, 758,272,286 => 613,661,514 bytes. Ratio 80.9%
Compression time: cpu 28.27 secs, real 8.41 secs. Speed 90,147 kB/s

Проверьте на своих данных.

Добавлено:
Вот результат для вашего же файла
http://freearc.org/HFCB.aspx
(мой компьютер примерно в 1,5 раза медленнее)

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h256kb, $wav => mm:d1+4x4:tor:3:2mb:h256kb:t0, $bmp => mm:d1+4x4:tor:3:2mb:h256kb:t0, $compressed => storing
Memory for compression 142mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,295,281,921 bytes. Ratio 30.5%
Compression time: cpu 104.02 secs, real 79.33 secs. Speed 53,500 kB/s

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:128:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,281,669,520 bytes. Ratio 30.1%
Compression time: cpu 100.78 secs, real 79.89 secs. Speed 53,126 kB/s

Здесь время примерно одинаковое.

Добавлено:
Извиняюсь, по ошибке rep:...128:с64.
Привожу для 64:с64

FreeArc 0.67 (February 5 2012) Creating archive: proba5.arc using rep:96mb:64:c64+4x4:tor:3:2mb, $wav => mm:d1+4x4:tor:3:2mb, $bmp => mm:d1+4x4:tor:3:2mb, $compressed => storing
Memory for compression 154mb, decompression 140mb, cache 16mb
Compressing 1 file, 4,244,176,896 bytes.
Compressed 1 file, 4,244,176,896 => 1,278,343,363 bytes. Ratio 30.1%
Compression time: cpu 101.21 secs, real 79.17 secs. Speed 53,605 kB/s

-m7rep
?

alexseb2007
читай внимательно:

Цитата:

-m7rep+xlzma:16m:h64m:max (что полностью записывается как
-mrep:512mb+4x4:lzma:16mb:h64m:normal:bt4:128)

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



Цитата:

В стандартном варианете –mex7 деление на группы при сжатии, видимо уменьшает эффективность использования rep! Мне кажется, что деление на группы эффективно только на очень больших объемах данных?!

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

методы -mex5..9 сделаны как раз для разных объёмов памяти. т.е. если тебе не нравится mex7 - используй mex8 и т.д.

Добавлено:
vasulpr
только ручными настройками. после чего тебе для распаковки нужен будет srep в путях и достаточное место под временные файлы

имеет смысл проверить на промежуточном 128:c128, по отдельности изменения в rep и tor, на большем числе файлов и исключить влияние I/O (в частности слить 1031 файл в один)

Цитата:

У меня архив проходит тестирование, но при распаковке происходит ошибка.

Всё, разобрался. Оказывается, чтобы увидеть сообщение об ошибке, надо раскрыть комбобокс...

а как фриарк включить в скрипт?

Цитата:

имеет смысл проверить на промежуточном 128:c128

Вообще-то я проверяю все, начиная от 256:с256 и до 16:с16, включая 128:с64.
Проверять долго. (На вскидку, крайние варианты: 256:с256 и 16:с16 малоинтересны.
Вариант 128:с128 интересен, скорее всего для самых быстрых tor:3:...:h64k)


Цитата:

по отдельности изменения в rep и tor

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

xanloz
На шапку взгляните:
Цитата:

Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах

1. Качаю архив и выбираю открыть http://www.snort.org/downloads/1416
2. Захожу в FA во второй архив - новое окошко открывается.
3. Выбираю директорию doc - Extract.
4. Получаю ошибку что архива нет.

Добавлено:
Так же есть проблема если это действие выполнить несколько раз
Архив скачивается несколько раз Firefox
snort-2.9.2.1.tar.gz
snort-2.9.2.1.tar-1.gz
snort-2.9.2.1.tar-2.gz

Вложеный архив в первом открывается нормально. В последующих появляется проблема.
Похоже что проблема вызвана пересечением имён и как следствие созданием уникального имени с snort-2.9.2.1.tar-1 который FA незнает как открыть и появляется окошко Windows с предложение выбрать программу для открытия неизвестного типа файла.

juvaforza
я уже пробовал, у меня чёт не выходит, может поможете включить в скрипт?

Bulat_Ziganshin

Цитата:

методы -mex5..9 сделаны как раз для разных объёмов памяти. т.е. если тебе не нравится mex7 - используй mex8 и т.д.

Хотел выяснить Ваше отношение к возникающей здесь проблеме.

Во времена 32-разрядных ОС и одноядерных процессоров все было просто - больше словарь - лучше сжатие.
Но сейчас времена изменились - широко используются многоядерные процессоры.
А доступный объем памяти в 32-разрядных ОС остался на уровне 2 ГБ (Ну 3 ГБ, в специфических случаях).
Поэтому эффективное использование, скажем 4-х ядерных (поточных) процессоров возможно только до предела, когда каждый поток занимает 400 МБ (=2 ГБ - нужды системы/4). При дальнейшем увеличении словаря, для потока нужно больше памяти и приходится уменьшать число потоков до 2 (или 1).

Вот она дилемма:
Или многопоточность (эффективность) <-> или сильное сжатие, но при слабом использовании процессора!!!
В том же -mex9 идет уже только 2 потока! И время резко увеличивается.

Может ли эта проблема быть решена в 64-разрядных ОС? Там для одной задачи все равно ограничение памяти 2 ГБ.
Слышал, что в 64-разрядной 7zip размер словаря увеличен по сравнению с 32-х разрядной.