» FreeArc (часть 4)

Ложное срабатывание?
у всех сразу что ли?
или я чет пропустил? хз

Цитата:

vasulpr
не так

тогда объясните как. ибо с вашей документации функции этой опции не совсем ясны.

Еще один вопрос: непрерывный блок адресного пространства 2Гб (win7 64), а для упаковки используется 1811Мб, так должно быть, или это опять какое-то ограничение?

blydovoz
да, действительно - выглядит обескураживающе. а вот что происходит после распаковки upx'ом: http://www.virustotal.com/file-scan/report.html?id=d0cb38028354aa9dc40728ec91bd10348d0d2c1581be328cce3596a4a5364128-1313312868

Добавлено:
а после повторной упаковки с теми же параметрами (upx --lzma -9) вирус в файле не обнаруживается. очень странно. но пока скорее похоже что вирус действительно есть

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

//Перешел в эту тему из FreeArc под Linux/Unix, тут более подходящая, тем более те же люди.
//лучше было бы и в саппорт написать, но учитывая что создатели и здесь, а мой английский очень simple вывод на лицо:

Поставил на архивирование 1 млн. файлов (меньше 2кб с сортировкой по размеру и удалением после архивации)
Как закончилась архивация не увидел. (В прошлый раз ооочень долго удаляло, сейчас как-то быстро, что не заметил, правда архив в 2.5 раза меньший).
Оказалось удалились не все файлы. Почему-то начиная с больших.
http://i43.fastpic.ru/big/2012/0929/c0/65772e0a6ac65445beec0fbc71ed69c0.png
Слева отсортированный по имени список из "unarc l". Посередине GUI FreeARC, справа то что есть Windows Explorer.
К примеру файлы 880, 881 не удалились, а 882, 883 удалились (они более большие по размеру).
Странно, архивация от меньшего к большему, а удаление наоборот.

Ошибки в конце я не видел. Просто прога закрылась. Могло нехватить памяти.

//З.Ы.По списку из unarc попробовал удалить через bat, findstr уже пол часа думает, ничего не удалило и прочитало с винта только 112кбайт (текстовый файл размером 22Мб)

Цитата:

тогда объясните как

опции -m задают метод сжатия. он может требовать например 10 гб озу. затем этот метод обрезается под память, заданную в -lc. -lc- просто отключает эту обрезку

если вам нужно использовать 100% озу, то пишите -lc100%. разумеется, это бессмысленно, поскольку тогда не останется места под ОС и программы

обрезание под макс. блок непрерывной памяти происходит отдельно, но оно также отключается при задании -lc-


Цитата:

непрерывный блок адресного пространства 2Гб (win7 64), а для упаковки используется 1811Мб, так должно быть, или это опять какое-то ограничение?

попробуйте -lc- -m=rep:2000m

вообще если вы начали воевать с ограничениями памяти, то проще всего использовать -lc- и вручную конструировать цепочки алгоритмов сжатия

Freearc есть srep. Если есть какие алгоритмы нужна писать.

v16 - http://freearc.org/download/testing/progress/FreeArc16.exe :



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

Добавлено на http://freearc.org/download/testing/progress/

Bulat_Ziganshin

Я бы в методе -m1 предложил бы все цепочки
4x4:tor:3:2mb:h256kb
заменить на
rep:16m+xtor:3:1m:h256k
Объем памяти не должен увеличиться, степень сжатия должна вырасти (на пол-дистанции до -m2), а время - чуть увеличиться (практически незаметно по сравнению с дистанцией до -m2).
Если бороться именно за время, можно сделать h128к - чуть быстрее, но менее сильное сжатие. (но оно нужно - воевать в одностороннем порядке только за время?!)
Рассмотрите, пожайлуста, этот вариант.

Добавлено:
В методе -m2
должно быть улучшение как по скорости, так и по степени сжатия при замене
xtor:5:8m:h2m
на
xtor:6:8m:h1m

Provizor54
нету

Замечание к прогрессу: (в текущей версии 0.666)
% вычисляется через количество файлов а не объем ими занимаемый (по крайней мере при сортировки по размеру это очень заметно)
Из это следует 3 беды:
- собственно % очень оптимистичный
- время выполнения почти постоянно увеличивается или стоит на месте
- ну и предполагаемый объем архива очень оптимистичный (я сначала так радовался)

Добавлено:
Только что помогал админу настроить резервное копирование.
От сюда Идея!

Сделать опцию "архивировать только файлы которые изменились за последние n дней"

Shuld
а размер процессорного кеша вы учитываете?

автор 7z не собирается добавлять (если он вообще в курсе) MF HT4 ?

Цитата:

От сюда

пишется слитно


Цитата:

Сделать опцию "архивировать только файлы которые изменились за последние n дней"

Суперидея - прочесть доку


Цитата:

% вычисляется через количество файлов а не объем ими занимаемый (по крайней мере при сортировки по размеру это очень заметно)

и то и другое. попробуй жать не кучу мелких файлов, а пару крупных


Цитата:

- ну и предполагаемый объем архива очень оптимистичный (я сначала так радовался)

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

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

Bulat_Ziganshin

Ну такой вид, так такой.
Достаточно неплохо. Однозначно лучше текущего.

Bulat_Ziganshin
Есть предложение, чтобы в консольном arc.exe (хотя бы при упаковке) убрать спаминг процентов при запуске внешнего компрессора, иначе эти 10% все остальные циферки перекрывают. Оставить только изменение времени в заголовке окна и хватит.

ну ладно чужого не добавляй, но ведь можно создать свой вариант МФ, который хотя бы будет требовать меньше памяти чем hc4

Булат, а не мог бы ты добавить ключик на запуск в свёрнутом (background) режиме? При чём, чтобы фокус не перебивался: кнопка на таскбаре просто появляется и всё.

Запуск при помощи "start /min" ворует фокус.

З.Ы. Если уже есть такое - извиняю, подскажите.

Bulat_Ziganshin

Цитата:

а размер процессорного кеша вы учитываете?

Нет, не учитывал.
Он до метода -mex6 вкл. 16 МБ, а свыше 256 КБ.

А вот что я не учел - на одноядерном процессоре размер памяти увеличится.
(Я мыслил своим 4-поточным).
Да и пожалуй, я поторопился с кэшем h256kb для метода -m1, все же h128kb лучше будет.
А размер памяти для
rep:16m+xtor:3:1m:h128k
при четырех потоках 41-38-16MB (упаковка-распаковка-кэш)
при двух потоках 33-29-16MB

На вашем сайте со статистикой есть пользователи с ОЗУ 128 МБ.
Интересно, сколько памяти для упаковки им доступно?

Рассуждения о rep-е.
Если посмотреть в моих тестах на любой график для FreeArc-а, то он извилист.
Причем извилины повторяют rep. (объем данных я всегда тестировал большой).
Начиная с метода -m1 "горб" вверх - у него нет rep-а.
Далее полочка с методами -m2...-m4 - у них одинаковый rep:96m.
Далее опять идет спуск вниз - у последующих методов rep растет.
Хорошо это или плохо, но связь прослеживается.
(на маленьких объемах данных зависимости от rep-а не должно быть).

kalpak
думаю, для него это не очень существенно

народ, я собираюсь выпустить SREP 3.0. есть какие-нибудь пожелания к нему или недоделанные вещи?

coolerru
а как это сделать?


Цитата:

Поставил на архивирование 1 млн. файлов (меньше 2кб с сортировкой по размеру и удалением после архивации)
Оказалось удалились не все файлы.

можно снова выполнить ту же операцию над оставшимися файлами, а затем слить два архива. другой вариант - дать команду "arc lb archive" и затем отредактировать её вывод, добавив команды del

Добавлено:
перевод инфы по последней альфе, выполненный ruduk (с моими исправлениями):

Новая альфа-версия:

Управление памятью для сжатия: теперь FreeArc знает, что 4x4/grzip может использовать больше или меньше памяти, в зависимости от числа потоков, без потери совместимости с уже сжатыми данными. Это усложняет управление памятью:При сжатии, информация "Память для упаковки 747mb, распаковки 96mb" теперь сообщает, сколько памяти использовано именно сейчас для упаковки и минимальный объем памяти, который потребуется в дальнейшем для распаковки
Диалог Сжатия показывает те же объёмы для стандартных методов сжатия
АркИнфо/lt команды показывают минимальный объём памяти, необходимый для упаковки и распаковки выбранного архива
При сжатии, -lc ограничивает использование памяти, сначала добавляя "tempfile" между методами, затем уменьшая параметры :t:i в 4x4/grzip и, в последнюю очередь, снижая объем памяти, используемый каждым потоком
При сжатии, -ld ограничивает минимальный объем памяти, который потребуется позже для распаковки (т.е. с "tempfile" между методами и настройками :t1:i0 в 4x4/grzip)
При распаковке, -ld ограничивает использование памяти, сначала добавляя "tempfile" между методами, затем уменьшая параметры :t:i в 4x4/grzip; в частности, вы можете использовать -ld1, чтобы использовать миниммально возможный объём памяти
Снижено использование памяти для xlzma распаковки на 9%; ppmd упаковки и распаковки на 14 МБ для каждого потока
LZMA: -di/lt показывают реальный размер хеша в :h (он может быть меньше, чем указано в команде, потому что каждый блок (:mc) должен содержать 2^n значений)
Исправлено множество ошибок и сделано много улучшений в управлении памятью для сжатия, теперь все показанные объемы памяти должны отражать реальное использование памяти
Остальные улучшения:Новая схема диалога прогресса, разработанная sabio и ruduk
Заглавие диалога прогресса теперь "xx% hh:mm:ss | Команда ..." вместо "{xx% hh:mm:ss} Команда ..."
i18n: полный перевод на Португальский Стандартный от Nuno Rego!
i18n: укорочены сообщения 0018, 0086, 0433, 0435, 0300, 0437, 0438, 0439, 0440, 0441, 0382, 0383, 0384, 0301, 0302. Если вы поддерживаете перевод, пожалуйста, попробуйте сделать то же самое
7z.dll: более точное вычисление dict/mem для bcj2-сжатых архивов в АркИнфо/lt
Unarc/DLL/large SFX: добавлена распаковка LZ4
Unarc.dll: добавлен C# пример использования, разработанный Mohammad Khalifa
lzma:fastest сделан набором действительно самых быстрых настроек
Осталось доделать:
Небольшие улучшения в Диалоге Прогресса
Управление памятью в Tornado и Unarc

Bulat_Ziganshin
Что бы SREP находил повторы в битовых строках)

Shuld
насчёт добавления rep в -m1. думаю, эти данные всё объясняют:

Цитата:

I:\>arc a a -mrep
Compressed 1 file, 810,411,321 => 629,317,667 bytes. Ratio 77.6%
Compression time: cpu 2.89 secs, real 2.39 secs. Speed 339,633 kB/s

I:\>arc a a -mxtor:3
Compressed 1 file, 810,411,321 => 440,306,287 bytes. Ratio 54.3%
Compression time: cpu 11.11 secs, real 1.55 secs. Speed 522,142 kB/s

I:\>arc a a -mrep+xtor:3
Compressed 1 file, 810,411,321 => 372,309,603 bytes. Ratio 45.9%
Compression time: cpu 9.39 secs, real 2.69 secs. Speed 300,804 kB/s

вот если бы rep сделать многопоточным...



Цитата:

Есть предложение, чтобы в консольном arc.exe (хотя бы при упаковке) убрать спаминг процентов при запуске внешнего компрессора, иначе эти 10% все остальные циферки перекрывают. Оставить только изменение времени в заголовке окна и хватит.

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

Добавлено:

Цитата:

а размер процессорного кеша вы учитываете?

Нет, не учитывал.
Он до метода -mex6 вкл. 16 МБ, а свыше 256 КБ.

что такое процессорный кеш - можно посмотреть в гугле. эти 16мб/256кб - дисковый кеш в моей программе. а вот это:
Цитата:

я поторопился с кэшем h256kb

- вообще не кеш, а хеш-таблица

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

V2driver
а это реально кому-то нужно?

а что такое битовые поля ?

Bulat_Ziganshin

Цитата:

всё это надо смотреть и перепроверять

Был бы счастлив, если бы у Вас нашлось время на это. (но его, наверное, нет).

Эффектов, которые я не понимаю, действительно много.
Вот даже сравнение
rep:16m+xtor:3:1m:h128k
и
rep:16m+xtor:3:1m:h256k

- на маленьком объеме данных (до 700 МБ) вариант с хеш-таблицей 256k сжимает предсказуемо сильнее и дольше.
- на больших объемах (свыше 700 МБ) начинают твориться чудеса. На одном и том же компьютере, но на разных данных у меня случалось: сжимали одинаково, но h256k на 5% дольше. В другом случае время одинаково, но h256k сжал заметно сильнее. И были случаи, когда xtor:3 сжимал медленнее (и хуже) чем xtor:5.

Я до конца не уверен, но идея такова, что стартовать надо приложение без видимой формы, точнее флаг видимости формы должен быть выключен, затем нужно свернуть последнюю, а затем уже показать. Вот примеры для винды:
http://stackoverflow.com/questions/4380575/how-to-launch-console-application-using-createprocess-with-minimized-main-window
http://stackoverflow.com/questions/7622052/creating-a-minimized-overlapped-window-win32

Там также описаны проблемы того, что фокус воруется иногда (если не свернуть два раза). То есть надо поиграться с кодом.

Но насколько я понял, FreeArc на GTK написан, так что надо будет через его вызовы это делать. Может в нём даже есть свой специальный, нативный способ?..


Кстати, не мог бы ты убрать плюсик и вытащить галочку (поверх всех окон) на его место в диалоге архивации? А то не ясно, зачем её прятать вообще, да и к тому же при нажатии на минус спойлер не сворачивается обратно, что не есть красиво.



А ещё: не знаю, у всех ли так или это "by design" вообще, но у меня при отмене архивации, запущенной из консоли, вываливаются ошибки (на билде от 27 сентября):

1)
---------------------------
freearc
---------------------------
write: invalid argument (Bad file descriptor)
---------------------------
ОК
---------------------------

2)
---------------------------
freearc
---------------------------
CompressionLib_dbHm: interrupted
---------------------------
ОК
---------------------------

А раньше было что-то про зациклившуюся (или прерванную) нить (thread).

Уважаемый Булат. Вы не планируете часом реализовать более гибкую настройку SFX модулей? Иногда проще сделать в самом архиваторе, нежели прибегать к InnoSetup.

вот ещё результаты тестов:

I:\>arc a a -mrep:64m D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,520,453,511 bytes. Ratio 77.6%
Compression time: cpu 16.49 secs, real 14.17 secs. Speed 319,723 kB/s
I:\>arc create a -mrep:256m D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,325,476,638 bytes. Ratio 73.3%
Compression time: cpu 17.00 secs, real 14.39 secs. Speed 314,814 kB/s
I:\>arc create a -mrep:1g D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,046,406,590 bytes. Ratio 67.2%
Compression time: cpu 17.74 secs, real 15.35 secs. Speed 295,262 kB/s
I:\>arc create a -mrep:2040m -lc- -ld- D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,081,247,699 bytes. Ratio 68.0%
Compression time: cpu 19.75 secs, real 20.10 secs. Speed 225,402 kB/s

I:\>arc create a -mrep:1g:32 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 2,245,307,762 bytes. Ratio 49.5%
Compression time: cpu 42.49 secs, real 40.07 secs. Speed 113,072 kB/s

I:\>arc create a -mxtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,696,917,637 bytes. Ratio 37.4%
Compression time: cpu 56.35 secs, real 7.49 secs. Speed 604,833 kB/s
I:\>arc create a -mexe+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,627,609,136 bytes. Ratio 35.9%
Compression time: cpu 55.07 secs, real 7.96 secs. Speed 569,268 kB/s
I:\>arc create a -mrep:1g+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,283,372,701 bytes. Ratio 28.3%
Compression time: cpu 46.02 secs, real 16.62 secs. Speed 272,611 kB/s
I:\>arc create a -mrep:1g:128+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,221,256,024 bytes. Ratio 26.9%
Compression time: cpu 49.31 secs, real 23.43 secs. Speed 193,409 kB/s
I:\>arc create a -mrep:1g:32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,151,854,135 bytes. Ratio 25.4%
Compression time: cpu 64.23 secs, real 40.51 secs. Speed 111,850 kB/s
I:\>arc create a -mrep:1g:d1m:s32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,184,277,470 bytes. Ratio 26.1%
Compression time: cpu 74.40 secs, real 49.73 secs. Speed 91,108 kB/s

I:\>timer exdupe D:\Testing\dll4g.dll a
COMPRESSED 4,531,060,447 bytes in 1 file(s) into 1,861,014,750 bytes
Kernel Time = 1.934 = 00:00:01.934 = 19%
User Time = 50.497 = 00:00:50.497 = 505%
Process Time = 52.431 = 00:00:52.431 = 525%
Global Time = 9.984 = 00:00:09.984 = 100%
I:\>arc create a -mxtor:3 a
Compressed 1 file, 1,861,014,750 => 1,665,934,654 bytes. Ratio 89.5%
Compression time: cpu 37.75 secs, real 5.03 secs. Speed 369,888 kB/s

I:\>arc create a -mrep:512m+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,309,468,532 bytes. Ratio 28.8%
Compression time: cpu 46.43 secs, real 16.13 secs. Speed 280,945 kB/s
I:\>arc create a -mrep:512m:128+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,249,238,776 bytes. Ratio 27.5%
Compression time: cpu 49.17 secs, real 23.01 secs. Speed 196,931 kB/s
I:\>arc create a -mrep:512m:32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,181,619,756 bytes. Ratio 26.0%
Compression time: cpu 63.34 secs, real 39.06 secs. Speed 115,996 kB/s

в общем, надо
1. сделать rep многопоточным
2. в идеале - найти способ реализовать rep:32 таким же быстрым, как rep:512
3. опционально - интегрировать его в tor:3 (в основном это имеет смысл если удастся сделать быстрый rep:32)
4. добавить в tor:3 пропуск несжимаемых данных

snkreg
нет. нельзя объять необъятное и я считаю, что эту область можно пока не трогать