» FreeArc (часть 4)

Snoopak96
1. я так понял, что unarc.dll завершает работу, хотя подпроцессы распаковки ещё не завершились. наверно та же фигня будет и с arc.exe/unarc.exe. запишу, подумаю
2. если указать большой -ld и достаточно физ. памяти (или попробуй -ld-) - то должно всё в памяти распаковываться
3. как только займусь толком работой над ним

Bulat_Ziganshin

Цитата:

MultiArc: плагин к Total Commander теперь везде использует ANSI-кодировку имён файлов

Т.е. в файле freearc.addon UTF-8 исправлено на ANSI и все?

Bulat_Ziganshin
Cabal не забудьте собрать

Skif_off
да. так что в русской винде с новым addon русские имена файлов в архиве должны полностью поддерживаться. а в какой-нибудь литовской - соответственно литовские


Цитата:

drag'n'drop

я считаю что это самый большой недостаток нынешнего GUI. но в gk2hs его поддержки нет вообще, а на уровне gtk что-то наполовину сделанное, насколько я помню

Как заставить использовать например 3,5 гиг ОЗУ при имеющихся 4 гиг? что бы я не выставлял параметром -lcXXXXmb больше 2700м не используется. меньше, без проблем. пробовал даже -lc85p тоже выше 2700 не поднимается. при параметре -lc- сразу ошибка "невозможно выделить память".

FYI
Как пропатчить 32-битную WinXP, чтобы получить доступ к 4+ ГБ памяти - http://habrahabr.ru/post/202406/

Paramon111
это сложно. самый простой вариант - использовать внешние (64-битные) компрессоры

Bulat_Ziganshin

Цитата:

я считаю что это самый большой недостаток нынешнего GUI. но в gk2hs его поддержки нет вообще, а на уровне gtk что-то наполовину сделанное, насколько я помню

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

Если бы существовала отдельная фриарковская библиотека (по аналогии с 7zip), её бы уже давно добавили в утилиты вроде PeaZip, PowerArchiver и т.д., т.е. в отлаженные и "вылизанные" полнофункциональные GUI.


Цитата:

FreeArc 0.70

FreeArc 0.70 is expected to be released in October.

Булат, ну хоть укажи, в октябре какого года

sabio

Цитата:

Как пропатчить 32-битную WinXP, чтобы получить доступ к 4+ ГБ памяти

Там в выводах прекрасное:

Цитата:

Примечание 1. Поскольку в методике используется dll из первого сервиспака, есть вероятность, что в ней имеются какие-либо уязвимости, закрытые последующими сервиспаками. Я не изучал этот вопрос.

Со времен SP1 закрыта тонна уязвимостей.

Цитата:

Примечание 2. Некоторые драйверы в пропатченой Windows XP могут вызывать BSOD. Впрочем, их крайне мало в природе.

Боюсь, автор понятия не имеет, сколько в природе таких драйверов и, главное, где и когда они могут встретиться.

Цитата:

Примечание 3. В первоисточнике ценных знаний сообщают, что на некоторых системах имеются проблемы с USB при использовании данной методики.

Следствие из п.2 - можно поиметь проблемы с новым драйвером или железом в любой момент и даже не сразу понять, в чем причина BSOD'ов.

Короче, методика для экстремалов. Проще поставить Win2k3 Server, если уж так хочется сидеть на старой 32-битной системе и использовать 4+ Гб памяти.

Bulat_Ziganshin
Вот еще вопрос есть по поводу памяти. Взял один файл 399mb, упаковал -mx -mc:exe/dispack070, посмотрел солид-блок. Он был такой: rep:403mb+dispack070+delta+lzma:177mb:normal:bt4:128 Ввел эти данные в метод сжатия добавив в конце -lc-, сжатие пошло. Методом подбора определил максимальное lzma:194mb при котором упаковка еще идет без ошибки. Сжатие в конечном итоге стало больше естественно. И мой вопрос: Почему -mx определил что lzma можно максимально задать 177mb а не 194mb? Может это можно исправить в будущих версиях?

Цитата:

Почему -mx определил что lzma можно максимально задать 177mb а не 194mb? Может это можно исправить в будущих версиях?

1. потому что я пользуюсь упрощённой эвристикой 2. нельзя

вообще советую вставлять tempfile между методами, например rep:403mb+dispack070+delta+tempfile+lzma:177mb:normal:bt4:128

Bulat_Ziganshin
Я понял. Тогда так к слову скажу что этот же файл на методе -m9x использует те же 177mb. Хотя без rep:403mb уже максимально я подобрал lzma:253mb, что уже существенно отразилось на сжатии.

Benchmark

Цитата:

Боюсь, автор понятия не имеет, сколько в природе таких драйверов и, главное, где и когда они могут встретиться.

ЕМНИП, Intel'овские видео и/или сетевые не дружат с PAE.

Цитата:

Если бы существовала отдельная фриарковская библиотека (по аналогии с 7zip)

Для распаковки есть unarc.dll (unarc.exe?), а с упаковкой - с трудом представляю, как уложить в один-два файла (как в 7z):
минимум arc.exe, arc.groups, arc.ini
+ facompress.dll и facompress_mt.dll для скорости/многопотока
+ минимум srep.exe и precomp042.exe (необязательно, если вычеркнуть –m5p..–m9p)

Bulat_Ziganshin
Боюсь надоесть, но снова хочу поднять тему ОЗУ. Сравнил 7-zip и FreeArc.
Взял все тот же файл 399mb. В 7-zip упаковал так: lzma:192mb:ultra:bt4:8, посмотрел потребляемую память при упаковке, было 3050mb.
Результат сжатия был 104 610.
Потом стал паковать FreeArc`ом. Задача была в том чтобы был тот же алгоритм как -mx и потребление памяти 3050mb. В результате подбора вышло: rep:403mb+dispack070+delta+lzma:153mb:ultra:bt4:8
Результат сжатия был 94 569.

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

Сейчас 7-zip в некоторых случаях сжимает эффективней только за счет использования 100% ОЗУ+файл подкачки. Наш же архиватор 100% ОЗУ (-lc-) без файла подкачки.

C:\>fazip.exe lzma:3g:max:hc4:a0 z:\4g z:\4g-lzma3g
100%: 4,531,060,447 -> 868,432,143: 19.17% Cpu 3 mb/s (1637.667 sec), real 3 mb/s (1646.831 sec) = 99%

C:\>fazip.exe lzma:2g:max:hc4:a0 z:\4g z:\4g-lzma2g
100%: 4,531,060,447 -> 877,949,487: 19.38% Cpu 3 mb/s (1367.396 sec), real 3 mb/s (1375.032 sec) = 99%

C:\>fazip.exe lzma:1g:max:hc4:a0 z:\4g z:\4g-lzma1g
100%: 4,531,060,447 -> 889,336,360: 19.63% Cpu 3 mb/s (1262.235 sec), real 3 mb/s (1268.332 sec) = 100%

this means that support of dictionaries up to 4GB was in LZMA code for a years (i just removed a few checks). unfortunately, it's limited to hc4 and a0, making it pretty useless. decompression works fine and restored files are byte-identical

Paramon111
Чего? Какой ещё файл подкачки при >2 гигах оперативки???
Срочно отключи эту каку!
Подкачка существует для того, чтобы выгружать память, если её не хватает. А когда её реально много (>2ГБ) - она начинает только всё тормозить бесполезной выгрузкой...
Эх...

Bulat_Ziganshin
Есть такой у меня вопрос по поводу сжатия.
Есть некий набор из нескольких файлов по 300-400 мбайт, различающихся примерно на 10-16 мбайт, а остальные данные одинаковы (разные по наполнению портативные версии программ в ThinApp контейнерах).
При этом каждый из файлов по отдельности реально жмётся до размера ~80…100 мбайт, а при наличии уникальных данных всего на 10-16 мбайт в каждом из файлов, результат должен получиться порядка 130…160 мбайт (НЕ больше).
Однако, по факту я не получаю такого сжатия, поскольку максимально обрабатываемый словарь (при "-m9x -lc- -ld-") всего 256 мбайт, что заметно меньше даже самого "мелкого" файла.
Немного порадовали обещания srep'а по ужиманию огромных массивов данных при мизерном расходе памяти (т.е., влепить 1-2 гигов словарь и вообще красота при расходе в ~200 мбайт), но похоже, что он не находит общее в разных файлах (не работает в solid-режиме). Совать всё в tar или прочую ерунду - глупо, ибо доступ к файлам нужен крайне быстрый без бесполезных распаковок и прочего.
Как вариант - можно пожать тем же 7z со словарём 384 или 512 мбайт, но хотелось бы иметь всё-таки ARC-архивчик.
Вопрос: что можно сделать в данной ситуации?

И второй вопрос - планируется ли х64 версия?

LZMA is fine. it was problems of my HT4-enabled code. i'm going to fix it. the only real LZMA problem is dictionary >=2GB wiith BT4


Код: C:\>fazip.exe lzma:max:2000m:ht4 z:\4g m:\1200
dict=2000mb: buf=2252mb head=1536mb son=0mb
100%: 4,531,060,447 -> 805,786,088: 17.78% Cpu 2 mb/s (2216.774 sec), real 3 mb/s (1683.414 sec) = 132%

C:\>fazip.exe lzma:max:2000m:ht4:h3g z:\4g m:\1200
dict=2000mb: buf=2252mb head=3072mb son=0mb
100%: 4,531,060,447 -> 805,196,672: 17.77% Cpu 2 mb/s (2003.989 sec), real 3 mb/s (1482.672 sec) = 135%

C:\>fazip.exe lzma:max:2000m:ht4:h4095m:mc240 z:\4g m:\1200
dict=2000mb: buf=2252mb head=3840mb son=0mb
100%: 4,531,060,447 -> 797,307,062: 17.60% Cpu 1 mb/s (6574.428 sec), real 1 mb/s (5963.810 sec) = 110%

C:\>fazip.exe lzma:max:2000m:hc4 z:\4g m:\1200
dict=2000mb: buf=2502mb head=1024mb son=8000mb
100%: 4,531,060,447 -> 805,324,025: 17.77% Cpu 1 mb/s (4527.274 sec), real 1 mb/s (3902.200 sec) = 116%


C:\>fazip.exe lzma:max:2000m:bt4 z:\4g m:\1200
dict=2000mb: buf=3002mb head=1024mb son=16000mb
100%: 4,531,060,447 -> 789,564,045: 17.43% Cpu 2 mb/s (2162.330 sec), real 3 mb/s (1559.318 sec) = 139%

C:\>fazip.exe d m:\1200 m:\4g
100%: 789,564,045 -> 4,531,060,447: 17.43% Cpu 104 mb/s (41.418 sec), real 99 mb/s (43.568 sec) = 95%

C:\>fc /b Z:\4g m:\4g
Comparing files Z:\4g and M:\4G
FC: no differences encountered

insorg
может заюзать REP?

Bulat_Ziganshin, а как же правила форума глава VI Соглашения по использованию?

Edison007007
Как конкретно?
Я, в основном, обхожусь вариантом "-m9x -lc- -ld-" без тщательной установки параметров.
Если есть конкретные пожелания (с примером) какие конкретно параметры можно задать - буду благодарен, ибо времени на изучение мануалов по каждому из них катастрофически нету.

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

Paramon111
нет, проблема в том что все эти тонкости с использованием памяти плохо документированы, поэтому ты просто не понимаешь что там происходит


Цитата:

Как вариант - можно пожать тем же 7z со словарём 384 или 512 мбайт, но хотелось бы иметь всё-таки ARC-архивчик.
Вопрос: что можно сделать в данной ситуации?

использовать lzma-x64, я уже объяснял как - пару страниц назад. или использовать srep, как описано в faq

Bulat_Ziganshin
Просто я полагаю, Вы английский знаете весьма неплохо, русский тоже; под тэгом "код" перевод по определению не полагается, а перевести 4,5 строки (и 2 строки в предыдущем сообщении) Вам никаких затруднений не составило бы (что подтверждает сообщение о новой альфа-версии на странице до этой)
Цитата:

тебя кстати действительно так интересует то чем я занимаюсь?

Что до этого - меня больше интересует результат, в подробности вдаваться - это свыше моих возможностей (да и потребностей). Ну, а раз я регулярно слежу за этой темой, получается, что FreeArc меня интересует достаточно, чтобы держать его в числе трёх используемых (и вообще установленных) архиваторов.
Цитата:

пока я получил всего два отклика и оба на английском форуме

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

Bulat_Ziganshin
а без сторониих упаковщиков, чтобы обойтись одним unarc.exe - никак?

insorg
я файл подкачки больше 1 гига не ставлю, знаю что будет тормозить. Скоро поставлю 8 гигов ОЗУ, думаю проблема с -lc- решится для файлов до 500-600 Мбайт.

Добавлено:
Bulat_Ziganshin
У метода -mx при любом размере файла и любом размере ОЗУ потолок lzma:256mb?

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

insorg
lzma-x64 совместим со встроенным lzma


Цитата:

У метода -mx при любом размере файла и любом размере ОЗУ потолок lzma:256mb?

если не использовать lzma-x64 и ht - то да

для всех лентяев на первых порах можно наверное вот такое решение внедрить

http://translate.google.com/translate?sl=en&tl=ru&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fforum.ru-board.com%2Ftopic.cgi%3Fforum%3D5%26topic%3D35164%26start%3D2460%232&act=url

Bulat_Ziganshin
Добавил я содержимое arc-lzma-x64-filter.ini в arc.ini, что-то не пошло, при любом методе выбивает ошибку "ошибка записи (диск полон?)", вернулся обратно. может что не так сделал?

Новая альфа-версия:
Опция -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!

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

slech
Такой перевод, IMHO, надо ещё на нормальный русский переводить. Хотя, для лентяев, может и пойдёт. Но, опять же, им на фиг не надо это даже и на русском. А кому надо, кто этим серьёзно занимается - и без перевода понимают.