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

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в 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 153 154 155 156

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

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 | Исправлено: Release, 10:58 24-04-2023
vasulpr

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

Цитата:
а что по-твоему означает -lc-?

снимает ограничение в 75% от физической памяти. т.е. с этой опцией ФА будет использовать 100% размера свободного адресного пространства. разве не так?

Всего записей: 126 | Зарегистр. 27-03-2011 | Отправлено: 12:58 03-01-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
vasulpr
не так
 
Добавлено:
это мне вопросы почтой прислали..

Цитата:
2. в файл перевода можно добавлять комментарии, или структура не допускает этого (хотелось бы разместить дату выполнения, под какую версию заточен и другую служебную информацию)?
3. при удалении всего содержимого архива появляется неприятное сообщение об ошибке
4. будет ли реализован drag-n-drop содержимго архива?
5. хотелось бы сохранения последних параметров упаковки (например лень устанавливать флажок защита каждый раз)
6. можно ли менять настройки сжатия меню добавить в arc проводника?
7. русский sfx планируется?

 
2. при сборке файла перевода для новой версии вся его структура берётся из моего arc.russian.txt, а из ваших - только правые части самих переводов. надо бы наверно что-то с этим сделать, а пока эту информацию переводчики традиционно вставляют сюда:
 
0159 Translated by=Peter Bauder alias JangoFat\nbased on 7zip language file\nedited for FreeArc-v0.67 (November 12 2011)
 
4. это очень сложно сделать (нужно низкоуровневое программирование), поэтому вопрос висит в воздухе и уже давно. кстати, это наиболее часто требуемая от меня фича
 
5. а как я определю что сохранять, а что ты только на один раз включил? особенно когда эта опция опасна...
 
6. можно, но только вручную (редактируя lua-скрипт). надо наверно какой-то пример на эту тему нарисовать...
 
7. его можно сделать самому, отредактировав ресурсы исполняемого файла sfx. а лучше - перевести текст в common.rc и бросить мне чтобы я сразу все sfx откомпилял с ним
 
Добавлено:

Цитата:
6. можно ли менять настройки сжатия меню добавить в arc проводника?  

 
да, это проще пареной репы. вот смотри что мы сейчас имеем в ArcShellExt-user.lua:
 

Цитата:
  -- Compression commands
  compression_menu = {
          append (command.add2arc,  {param = arcname,          command = freearc.." a --noarcext "      ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" "   .. filelist}),
          append (command.add2sfx,  {param = sfxname,          command = freearc.." a --noarcext -sfx " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" "   .. filelist}),
          append (command.add2zip,  {param = arcbase..".zip",  command = freearc.." a --noarcext -tzip "..add_options.." -sclUTF-8 -- \"" .. arcbase..".zip\" " .. filelist}),
          append (command.add2_7z,  {param = arcbase..".7z",   command = freearc.." a --noarcext -t7z  "..add_options.." -sclUTF-8 -- \"" .. arcbase..".7z\" "  .. filelist}),
          append (command.add,      {                          command = freearc.." --add-dialog a "    ..add_options.." -- "..filename}),
  }
 

 
так что добавить например сжатие в -m3 можно так:

Цитата:
  -- Compression commands
 
command.add2arc_m3 = {text = "Добавить с -m3 в \"%s\"", help = "Сжать выделенные файлы в -m3 с помощью FreeArc"}
 
  compression_menu = {
          append (command.add2arc_m3,  {param = arcname,          command = freearc.." a --noarcext -m3 "      ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" "   .. filelist}),
          append (command.add2arc,  {param = arcname,          command = freearc.." a --noarcext "      ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" "   .. filelist}),
          append (command.add2sfx,  {param = sfxname,          command = freearc.." a --noarcext -sfx " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" "   .. filelist}),
          append (command.add2zip,  {param = arcbase..".zip",  command = freearc.." a --noarcext -tzip "..add_options.." -sclUTF-8 -- \"" .. arcbase..".zip\" " .. filelist}),
          append (command.add2_7z,  {param = arcbase..".7z",   command = freearc.." a --noarcext -t7z  "..add_options.." -sclUTF-8 -- \"" .. arcbase..".7z\" "  .. filelist}),
          append (command.add,      {                          command = freearc.." --add-dialog a "    ..add_options.." -- "..filename}),
  }
 

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

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Выложил свежий тест
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#4
с архиваторами: WinRAR 4.10b5 (15 дек 2011), 7z 9.22b (18.04.2011), FreeArc 0.67 (25 декабря 2011). Объем сжимаемых данных - 2 ГБ.
Из шокирующих фактов отмечу, что мой метод -m82 сжал быстрее, чем режим  
WinRAR «без сжатия», и при этом сильнее максимального непрерывного режима WinRAR!  
И это без всяких lzma!
 
Bulat_Ziganshin
Вы недооцениваете свои rep и tor!
 
Нет ли в тесте существенных неточностей с вашей точки зрения?

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 15:32 03-01-2012 | Исправлено: Shuld, 15:40 03-01-2012
vasulpr

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

Цитата:
vasulpr  
не так  

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

Всего записей: 126 | Зарегистр. 27-03-2011 | Отправлено: 16:56 03-01-2012
Bulat_Ziganshin

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

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

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

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

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

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

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

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 20:14 03-01-2012 | Исправлено: Shuld, 20:26 03-01-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shuld
а размер процессорного кеша вы учитываете?

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 01:56 04-01-2012
Profrager



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

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

Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 12:04 04-01-2012 | Исправлено: Profrager, 12:06 04-01-2012
Shuld

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

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

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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  
- вообще не кеш, а хеш-таблица
 
я к чему это объясняю - дискуссии, увы, не получится. ваши идеи не бесполезны, но всё это надо смотреть и перепроверять, учитывая эффекты, названия которых вам ничего не говорят. собственно, поэтому, я не комментировал ваши предложения

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 22:15 04-01-2012 | Исправлено: Bulat_Ziganshin, 22:18 04-01-2012
Shuld

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

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

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

Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 13:31 05-01-2012
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
вот ещё результаты тестов:
 
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 пропуск несжимаемых данных

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:13 05-01-2012 | Исправлено: Bulat_Ziganshin, 14:21 05-01-2012
Shuld

Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
using 4x4:tor:3:2mb:h256kb
Compressed 361 files, 430,097,775 => 299,114,442 bytes. Ratio 69.5%        
Compression time: cpu 18.50 secs, real 5.01 secs. Speed 85,877 kB/s
 
rep:16mb+4x4:tor:3:1mb
Compressed 361 files, 430,097,775 => 281,437,322 bytes. Ratio 65.4%        
Compression time: cpu 17.64 secs, real 5.19 secs. Speed 82,866 kB/s
 
 
Добавлено:
using 4x4:tor:3:2mb:h256kb
Compressed 2,905 files, 236,542,287 => 186,087,534 bytes. Ratio 78.6%      
Compression time: cpu 10.14 secs, real 3.23 secs. Speed 73,138 kB/s
 
rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%      
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s
 
Может я чего не учитываю, но разница по времени мала, а сжатие заметно.
 
Добавлено:
В своих тестах я эффекта от rep:32 не заметил
 
rep:16mb+4x4:tor:3:1mb  
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%        
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s
 
rep:16mb:32+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,205,644 bytes. Ratio 75.7%      
Compression time: cpu 12.50 secs, real 5.83 secs. Speed 40,571 kB/s
 
 
Добавлено:
Разве что только на rep:256
 
rep:16mb+4x4:tor:3:1mb  
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%        
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s  
 
rep:16mb:256+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,616,048 bytes. Ratio 75.9%      
Compression time: cpu 11.19 secs, real 3.80 secs. Speed 62,244 kB/s
 
А меньше rep:256 скорее вред, чем польза.

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

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
http://freearc.org/download/testing/fazip01.zip  
 
FAZip is a standalone compression utility like gzip and bzip2.
It doesn't support any cmdline options but features the same great
compression power as FreeArc itself.
 
 
I don't recommend to use it for doing real compression due to it's
lack of CRC checking, file identification and other features common
for Unix compression tools. Consider it as technology demonstration
which may sometimes grow into really useful tool. Compression methods
supported and their parameters are exactly the same as in FreeArc
(so see FreeArc.htm for details). In paricular, it supports CLS external
compressors placed in cls-*.dll and accelerated compression functions
from facompress*.dll
 
 
Usage examples:
 
Fast binary data compression and decompression:
Код:
fazip 4x4:tor:3 example.tar   example.fazip
fazip d         example.fazip example.tar

Fast text data compression:
Код:
fazip grzip:m4 example.tar example.fazip

Maximum binary data compression:
Код:
fazip rep:512m+exe+delta+tempfile+lzma:max:64m example.tar example.fazip

Maximum text data compression:
Код:
fazip dict:p:128m+lzp:64m:105:d1m:s32:h22+ppmd:12:192m example.tar example.fazip

 
Добавлено:

Цитата:
Может я чего не учитываю, но разница по времени мала

не учитываете, что у меня вдвое больше ядер
 

Цитата:
В своих тестах я эффекта от rep:32 не заметил  

так у вас словарь всего 16 мб, поставьте 256 мб

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

Gold Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
В чём отличае fazip.exe  от arc.exe, для чего он нужен ?

Всего записей: 6488 | Зарегистр. 31-08-2008 | Отправлено: 17:26 06-01-2012
PAQer



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

Цитата:
1. freearc is an archiver while fazip is a compressor. for example, fazip can compress to nul or to stdout
2. fazip prints more stats using just one line - it's what i need for benchmarking  

Первый пункт для меня более предпочтителен, ну и главное чтоб еще распаковывал в stdout.

Всего записей: 161 | Зарегистр. 17-12-2007 | Отправлено: 18:32 06-01-2012
vasulpr

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Как дела с финальной версией ФА (0.70)? На оф. сайте висело сообщение что выйдет в декабре. В чем задержка?

Всего записей: 126 | Зарегистр. 27-03-2011 | Отправлено: 14:29 08-01-2012
ndch

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

Цитата:
В чем задержка

Во времени.

Всего записей: 6488 | Зарегистр. 31-08-2008 | Отправлено: 19:32 08-01-2012
vishyakov

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

Цитата:
чтение входных файлов при архивации и запись выходных при распаковке идёт через кеш.  

 
Ну кэши заполняются/сбрасываются в одном потоке (последовательно) или в разных (параллельно)?

Всего записей: 29 | Зарегистр. 18-03-2009 | Отправлено: 08:04 09-01-2012
Bulat_Ziganshin

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

Всего записей: 3401 | Зарегистр. 13-08-2007 | Отправлено: 14:41 09-01-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 153 154 155 156

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


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

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru