Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc (часть 4)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152

Открыть новую тему     Написать ответ в эту тему

Widok



Moderator-Следопыт
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Часть 1 | Часть 2 | Часть 3


Скачать последний релиз - FreeArc 0.666 от 20 мая 2010 г. Что нового: ускорение работы в 1.5-2 раза благодаря новой технологии многопоточного сжатия, распаковка архивов многих форматов используя технологии 7-zip, запуск файлов из архива, исправлены все проблемы интеграции с Explоrer (подробнее)
Текущая альфа версия: 0.67 - загрузка | список исправлений | блог


Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Планы дальнейшего развития
Что подразумевается под "интеграцией с Explorer"
Старая FreeArc wiki (включая описание формата архива)
Логотип и иконки FreeArc - обсуждение того, как облагородить внешний вид программы


Сторонние оболочки для работы с FreeArc:
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip - менеджер архивов с поддержкой большого количества форматов, для Windows и Linux


Родственные темы:
Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах
ISDone.dll - библиотека распаковки архивов в инсталяторах
REP & SREP
Пережатиe/Pекомпрессия/Oптимизация файлов для лучшего сжатия - "а как сжать ещё лучше?"
FreeArc и Unix - для альтернативно одарённых
• репозиторий FreeArc 'Next на github.com
• тема FreeArc 'Next на форуме encode.su
• раздел FreeArc на форуме krinkels.org

 
Другие архиваторы:
WinRAR
7-zip
PowerArchiver
HaoZip
BandiZip


Всего записей: 24190 | Зарегистр. 07-04-2002 | Отправлено: 11:36 23-11-2010 | Исправлено: Nikolai2004, 21:23 03-02-2021
protman



Advanced Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Bulat_Ziganshin, смените на сайте

Цитата:
FreeArc — планы на будущее
Трекер: список планируемых улучшений по версиям
Версия 0.70 (декабрь 2011)
 •полная поддержка zip, rar, 7z и других архивных форматов

А то время потерял пытаясь найти 0.70 для скачивания. и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

Цитата:
Версия 0.75
 •алгоритм сжатия SREP
•поддержка LZMA со словарём до 1 гб

В версии 0.67 в виде экспериментальных опций включены (работают)?
 
Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..
p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом, лунаскейпом (браузеры) и другими безплатными программами.

----------
ИМХО - Имею Мнение, Хрен Оспоришь
Кривыми должны быть извилины а не руки.

[img]https://nick-name.ru/forum1t4/Protman.gif[/img]

Всего записей: 1382 | Зарегистр. 20-05-2003 | Отправлено: 09:35 03-02-2012 | Исправлено: protman, 09:40 03-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю  

Для lzma:fast и lzma:normal поведение существенно отличается. В последнем fb заметно влияет на скорость.

Цитата:
2. предлагаемые тобой методы сжатия требуют много памяти для распаковки

их можно использовать и с другими размерами rep. Правда, эффективность упадет...
 
Я вообще хочу сказать вот что.
Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая (в последнем тесте 2%), они по-существу выполняют роль дожатия. Очень много зависит именно от rep-а.
1. Поэтому для быстрых методов (-m1) нужен именно быстрый rep.
2. Для более сильного сжатия нужен rep с оптимизацией не на скорость, а на сжатие (если такое возможно), как полноправный метод
3. Для ультра сжатия возможно вот что.
У меня часто бывает так: скопировал из интернета прорамму/книгу/музыку, распаковал и оставил вместе с архивом. Или, допустим файл word-а запаковал, отправил по e-mail, да и оставил оба экземляра.
Короче: у меня на компьютере часто хранятся архивы и они же, но распакованные. Возможно, у других пользователей то же самое.
Зачем сжимать 2 раза одно и то же?
Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.
Время займет немало, но, возможно увеличит степень сжатия.
Кто-нибудь такое уже реализовывал?
 
Добавлено:
Или другими словами, все архивы распаковываются, и используются как словарь.

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 10:27 03-02-2012 | Исправлено: Shuld, 10:32 03-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А то время потерял пытаясь найти 0.70 для скачивания.

спасибо, исправил
 

Цитата:
и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..  

считай, издержки альфы
 

Цитата:
В версии 0.67 в виде экспериментальных опций включены (работают)?  

нет, я это буду делать после выпуска 0.70
 

Цитата:
Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..  

в диалоге settings всё сохраняется
 

Цитата:
p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом,  

согласен но тут и так много недовольных задержкой с выходом 0.70
 
Добавлено:

Цитата:
что-то svn не пашет, или он куда-то переместился?

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

Цитата:
Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая

ты на чём-нибудь кроме своего бэкапа тестировал? вот на первом же нормальном файле:
 
D:\Testing>fazip 4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 31,546,433: 31.55%  Cpu 7 mb/s (13.868 sec), real 36 mb/s (2.647 sec) = 524%
 
D:\Testing>fazip 4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 36,668,388: 36.67%  Cpu 28 mb/s (3.354 sec), real 142 mb/s (0.671 sec) = 500%
 

Цитата:
Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.  

блестящая идея, я лично её раньше не встречал

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 15:45 03-02-2012 | Исправлено: Bulat_Ziganshin, 15:54 03-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
ты на чём-нибудь кроме своего бэкапа тестировал?

 
Я не о том.  
Я о  
rep +tor
rep+lzma
!!!
В том то и дело, что отдельно взятый tor сильно уступает lma, а в связке с rep эта разница становится почти символической.

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 16:03 03-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shuld
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 32,368,300: 32.37%  Cpu 28 mb/s (3.448 sec), real 129 mb/s (0.738 sec) = 467%
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43%  Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%
 
ещё раз - у тебя в бекапах половина уже сжатые данные, их и не сожмёшь ничем после ловли повторов

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 16:06 03-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В первом случае случае (без rep) разница 5%, во втором - вдвое меньше. Вот об этом я говорю.
А если взять rep +xtor:6:4m:h8m?

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 16:21 03-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
во-первых, я считаю разницу от размера сжатых данных. далее - сравни:
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:6:8m dll100.dll   nul
100%: 100,000,000 -> 31,352,957: 31.35%  Cpu 18 mb/s (5.288 sec), real 94 mb/s (1.014 sec) = 522%
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43%  Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:normal:8m dll100.dll   nul
100%: 100,000,000 -> 27,779,433: 27.78%  Cpu 3 mb/s (31.871 sec), real 22 mb/s (4.293 sec) = 742%
 
 
как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов. в третьих, в tor встроен упрощённый аналог delta, lzma же надо использовать вместе с ним, и тогда разница становится ещё больше:
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:tor:6:8m dll100.dll   nul
100%: 100,000,000 -> 31,144,107: 31.14%  Cpu 18 mb/s (5.179 sec), real 72 mb/s (1.325 sec) = 391%
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 28,523,697: 28.52%  Cpu 7 mb/s (13.634 sec), real 40 mb/s (2.357 sec) = 578%
 
D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:normal:8m dll100.dll   nul
100%: 100,000,000 -> 26,980,494: 26.98%  Cpu 3 mb/s (31.637 sec), real 22 mb/s (4.435 sec) = 713%

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 16:41 03-02-2012 | Исправлено: Bulat_Ziganshin, 16:44 03-02-2012
Profrager



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Цитата:
тебя не устраивают исходники, которые я публикую с альфа-версиями?
в svn я мог увидеть разницу между предыдущим и следующим билдом прям в проге, которая показывает различия в исходниках между этими двумя билдами. И при этом ты там пишешь более информативные комменты для конкретного фикса, чем указываешь при релизе альфы.


----------
переехал сюда

Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 18:46 03-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
 

Цитата:
как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов

 
Согласен.
Это и есть примерно мой вариант.
 
Добавлено:
Только шаг в 2 раза слишком большой

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 19:03 03-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Profrager
согласен. собственно, вопрос был в том, нужно ли это кому-нибудь. раз желающий нашёлся, постараюсь сделать фильтрованный репозиторий hg. можно и svn, но там в любом случае будет более бедное, линейное дерево коммитов
 

Цитата:
Это и есть примерно мой вариант.

ну да? ты вроде предлагал заменить lzma:fast на tor:6

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 19:12 03-02-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В основном проблема между методами tor:6 и lzma:fast. Здесь зазор заполнять нечем.
 
Добавлено:
У меня  
84 = rep:1gb+4x4:tor:6:4mb:h8mb
85 = rep:1g+xlzma:4mb:h512k:fast:128:mc8
 
Где я пытался сколько можно ускорить Lzma:fast
 
Добавлено:
Здесь перечислял:
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1260#19

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 19:13 03-02-2012
UriF

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ваше мнение?
http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/3327567
 
The unarchiver project has an implementation of WinZip JPEG compression.
http://code.google.com/p/theunarchiver/source/browse/#hg%2FXADMaster%2FWinZipJPEG

Всего записей: 579 | Зарегистр. 14-06-2004 | Отправлено: 20:42 03-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
UriF
записал в планы на 0.75, заодно и wavpack делать придётся. кстати, имей в виду - там только распаковка

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:08 03-02-2012
vishyakov

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
У меня архив проходит тестирование, но при распаковке происходит ошибка. Это ведь не нормально? (FA 0.67a)

Всего записей: 29 | Зарегистр. 18-03-2009 | Отправлено: 21:27 05-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
vishyakov
а у меня подпольный стук

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:03 05-02-2012
juvaforza

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

Всего записей: 2895 | Зарегистр. 26-11-2005 | Отправлено: 22:57 05-02-2012
iiwgfd34332

BANNED
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
.

Всего записей: 72 | Зарегистр. 22-01-2012 | Отправлено: 00:27 06-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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!

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 00:41 06-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Новая альфа-версия:
  • Опция -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!

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 16:01 06-02-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
i've set up Mercurial repository: http://source.freearc.org:8002/freearc/, although URL may be changed later

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 19:10 06-02-2012
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc (часть 4)


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.Board
© Ru.Board 2000-2020

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru