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

Новости • Файловые архивы
Поиск • Активные темы • Топ лист
Правила • Кто в 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 157 158 159

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

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
Bulat_Ziganshin

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
http://freearc.org/download/testing/fazip02.zip
 
FAZip 0.2:
 

  • исправлена ошибка: программа возвращала код ошибки -9 при распаковке цепочек методов, например rep+tor
  • значительно ускорен REP благодаря идее Жени Шелвина
  • REP получил новый параметр :c, означающий размер хешируемых блоков. Для  
    :l512 по умолчанию :c128, для  :l511..257 по умолчанию :c256 и т.д.
  • по умолчанию размер хеш-таблицы для REP равен min(:b/:c*4,:b/4)

 
Бенчмарки:
 
1. Сжатие с rep:1g  
старый REP: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 364 mb/s (11.872 sec), real 333 mb/s (12.989 sec) = 91%  
новый REP: 4,531,060,447 -> 3,064,484,898: 67.63% Cpu 529 mb/s (8.174 sec), real 1341 mb/s (3.221 sec) = 254%  
 
2. Сжатие с rep:1g+xtor:3  
старый REP: 4,531,060,447 -> 1,283,663,780: 28.33% Cpu 105 mb/s (41.137 sec), real 270 mb/s (16.026 sec) = 257%  
новый REP: 4,531,060,447 -> 1,286,102,352: 28.38% Cpu 87 mb/s (49.671 sec), real 581 mb/s (7.443 sec) = 667%  
 
Для сравнения чистый 4x4:tor:3  
4,531,060,447 -> 1,698,510,452: 37.49% Cpu 83 mb/s (52.260 sec), real 586 mb/s (7.380 sec) = 708%  
 
Т.е. теперь не будет потерь в скорости -m1 от добавления REP, при этом сжатие с REP выше в 1.32 раза
 
 
 
 

  • fixed bug: error -9 was reported when decompressing files with methods like rep+tor
  • improved speed of REP using Eugene Shelwien's idea
  • REP has new parameter :c denoting hashed chunk size. For :l512 default is :c128, for :l511..257 default is :c256 and so on
  • Default hash size for REP is min(:b/:c*4,:b/4)

 
Some benchmarks:
 
1. Compression with rep:1g:513
old REP: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 364 mb/s (11.872 sec), real 333 mb/s (12.989 sec) = 91%  
new REP: 4,531,060,447 -> 3,064,484,898: 67.63% Cpu 529 mb/s (8.174 sec), real 1341 mb/s (3.221 sec) = 254%  
 
2. Compression with rep:1g:513+4x4:tor:3  
old REP: 4,531,060,447 -> 1,283,663,780: 28.33% Cpu 105 mb/s (41.137 sec), real 270 mb/s (16.026 sec) = 257%  
new REP: 4,531,060,447 -> 1,286,102,352: 28.38% Cpu 87 mb/s (49.671 sec), real 581 mb/s (7.443 sec) = 667%  
 
For comparison, pure 4x4:tor:3  
4,531,060,447 -> 1,698,510,452: 37.49% Cpu 83 mb/s (52.260 sec), real 586 mb/s (7.380 sec) = 708%  
 
It means that now REP may be added to the FreeArc -m1 compression method without losing even bit of speed, while compression becomes (in this case) 1.38x tighter
Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 05:14 26-01-2012
Shuld

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
 
Обращаю внимание на 2 вещи, связанные с новым rep-ом и сжатием Rep+tor:3
 
На маленьких объемах данных типична такая ситуация:
Метод Размер Время, с    
2011-12-25 (757,517,055)    
rep:1g+xtor:3:4m:h128k 435,488,268 8.80    
rep:1g+xtor:6:4m:h1m:l2 431 493 374 15.37    
2012-01-11    
rep:1g+xtor:3:4m:h128k 435 614 282 7.04    
rep:1g+xtor:6:4m:h1m:l2 431 709 948 13.97    
2012-01-14    
rep:1g+xtor:3:4m:h128k 435 528 650 6.67    
rep:1g+xtor:6:4m:h1m:l2 431 640 615 13.80

Т.е. метод tor:3 быстр
 
На больших же данных ситуация РЕЗКО меняется (мне кажется, в случае, когда входные и выходные данные не помещаются в ОЗУ):
Метод  Размер Время, с    
2011-12-25 (3,981,167,515)    
rep:1g+xtor:3:4m:h128k 2 414 603 895 113.73    
rep:1g+xtor:6:4m:h1m:l2 2 370 413 084 119.48    
2012-01-11    
rep:1g+xtor:3:4m:h128k 2 415 270 946 112.98    
rep:1g+xtor:6:4m:h1m:l2 2 371 026 944 109.57    
2012-01-14    
rep:1g+xtor:3:4m:h128k 2 414 815 983 116.47    
rep:1g+xtor:6:4m:h1m:l2 2 370 663 249 119.91

1. Различие прежде всего в том, что метод tor:3 перестает демонстировать сколько-нибудь значительное преимущество в скорости! А плохое сжатие остается!
(Подобных данных у меня много, но очень неудобно и долго заполнять форумские таблички.)
Вернемся к ситуации, на маленьких объемах мы получаем преимущество во времени порядка 6 с, на больших объемах - те же 3-6 с, и около -2% в сжатии!  
Где зона использования метода rep+xtor:3???
Чего я не понимаю?
 
2. Rep от 2012-01-14 демонстрирует "нестабильность" в экономии времени. Например, во втором примере (выше) он значительно хуже версии от 2012-01-11.
 
Добавлено:
И чуть хуже существующей! А это куда годится?
 
 
Добавлено:
Примечание по поводу второй таблички:
На разных компьютерах, при разном соотношении скорости процессора и устройств ввода/вывода (винт) различие межу методами rep:1g+xtor:3:4m:h128k и rep:1g+xtor:6:4m:h1m:l2 во времени сжатия может быть больше или, наоборот, отсутствовать! Но смысл останется - на больших объемах нет смысла применять  rep:1g+xtor:3:4m:h128k!
Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 19:13 26-01-2012 | Исправлено: Shuld, 19:19 26-01-2012
egor23



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

Цитата:
FAZip 0.2:

в rep были изменения относительно rep новый2 от 14.01.12?
Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 19:27 26-01-2012 | Исправлено: egor23, 01:34 27-01-2012
Bulat_Ziganshin

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

Цитата:
Чего я не понимаю?  

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

Цитата:
На разных компьютерах, при разном соотношении скорости процессора и устройств ввода/вывода (винт) различие межу методами rep:1g+xtor:3:4m:h128k и rep:1g+xtor:6:4m:h1m:l2 во времени сжатия может быть больше или, наоборот, отсутствовать! Но смысл останется - на больших объемах нет смысла применять  rep:1g+xtor:3:4m:h128k!

 
C:\Testing\rep\017>fazip rep:1g:c256:256+4x4:tor:6:4m:h1m:l2 D:\Testing\dll4g.dll nul
100%: 4,531,060,447 -> 1,161,045,257: 25.62%  Cpu 39 mb/s (109.981 sec), real 292 mb/s (14.821 sec) = 742%
 
C:\Testing\rep\017>fazip rep:1g:c256:256+4x4:tor:3:4m:h128k D:\Testing\dll4g.dll nul
100%: 4,531,060,447 -> 1,278,123,155: 28.21%  Cpu 90 mb/s (48.204 sec), real 608 mb/s (7.103 sec) = 679%
Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 20:53 26-01-2012 | Исправлено: Bulat_Ziganshin, 21:06 26-01-2012
Shuld

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Я не знаю, что такое fazip.
 
 
Добавлено:
Он же не пишет на винт, а отправляет в nul?
Какое это отношение имеет к сжатию данных в реальных условиях?
 
Добавлено:
Загрузка CPU - это только часть процесса. И для быстрых методов не самая большая часть.
 
Добавлено:

Цитата:
ты даже не сообразил, что форумскую табличку можно оставить пустой, а затем редактировать как обычный текст  

Так я делаю.
Но не получается взять целиком Excel-евскую или Word-овскую табличку и вставить. Только по одной ячейке. Застрелиться можно.
Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 22:50 26-01-2012 | Исправлено: Shuld, 22:57 26-01-2012
slech



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

Цитата:
Но не получается взять целиком Excel-евскую или Word-овскую табличку и вставить. Только по одной ячейке. Застрелиться можно.

Может пригодится http://theenemy.dk/table/
Всего записей: 4893 | Зарегистр. 10-11-2004 | Отправлено: 01:10 27-01-2012
Bulat_Ziganshin

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

Цитата:
Он же не пишет на винт, а отправляет в nul?  
Какое это отношение имеет к сжатию данных в реальных условиях?  

а ты не думаешь, что на других машинах соотношение скорости диска и процессора может на порядок отличаться от твоего?
Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 03:02 27-01-2012
snkreg

Full Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Булат, добрый день. А Вы не планируете добавить Оценку Сжатия, как в HaoZIP и поддержку ASCII-комментов, как в WinRAR?
 
Добавлено:
Отлично я написал.."Добрый день" в 03:31))
Всего записей: 586 | Зарегистр. 18-10-2008 | Отправлено: 03:31 27-01-2012
Shuld

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

Цитата:
а ты не думаешь, что на других машинах соотношение скорости диска и процессора может на порядок отличаться от твоего?  

Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).
 
 
Добавлено:
А почему вообще такое происходит - на небольшом объеме данных tor:3 в разы превосходит по скорости, а на больших объемах чуть-чуть (на одном и том же компьютере)?
Что в принципе творится?
 
Добавлено:
slech
 
Спасибо, попробую.
Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 17:38 27-01-2012
Eagle1726



Newbie		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Приветствую.
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?
Всего записей: 5 | Зарегистр. 09-01-2012 | Отправлено: 23:35 29-01-2012
WildGoblin



Ru-Board Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.
Всего записей: 33353 | Зарегистр. 15-09-2001 | Отправлено: 13:56 30-01-2012
Shuld

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
 
1. Понял про разницу во времени маленьких объемов и больших.
При маленьких объемах, похоже, исходные данные хранятся в ОЗУ, и на диск идет только запись. (Я ведь несколько раз подяд прогоняю сжатие).
При больших объемах, данные реально считываются и записываются. Получается две дисковых операции, скоростные методы преимущество теряют.
 
2. При новом rep-е появляется еще интересный скоростной вариант: rep+xtor:3:4m:h64k
Один из примеров, везде rep от 11.01.2012:
 
Без rep-а
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using 4x4:tor:3:4mb:h256kb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 527,930,839 bytes. Ratio 69.6%      Compression time: cpu 27.11 secs, real 7.44 secs. Speed 101,866 kB/s
FreeArc 0.67 (December 25 2011) Updating archive: proba5.arc using 4x4:tor:3:4mb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 532,685,127 bytes. Ratio 70.3%      Compression time: cpu 24.30 secs, real 7.59 secs. Speed 99,825 kB/s
 
С rep-ом
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb
Memory for compression 1171mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 435,592,914 bytes. Ratio 57.5%      Compression time: cpu 24.15 secs, real 6.94 secs. Speed 109,162 kB/s
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb:h64kb
Memory for compression 1170mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 436,406,848 bytes. Ratio 57.6%      Compression time: cpu 22.18 secs, real 6.40 secs. Speed 118,429 kB/s
 
Добавлено:
Внес исправления
Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 18:57 30-01-2012 | Исправлено: Shuld, 19:13 30-01-2012
Bulat_Ziganshin

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

Цитата:
Гипотетически - конечно, да!  
То есть это для таких случаев, если они есть?  
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).  

достаточно ssd и какого-нибудь ультрабучного процессора
 

Цитата:
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?

стандартным, fa сам разберётся  
 

Цитата:
Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.

-mx определяется как -m9, так что вопрос просто в везении. а в чём проблема - в твоей машине иди моей программе, надо разбираться, тестировать сжатие присланных тобой файлов
Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 20:22 30-01-2012
Shuld

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

Цитата:
достаточно ssd

 
Да, я уже так подумал.
 
В ближайшее время (завтра?) выложу вчернове линейку равномерных методов (основных) для FreeArc. Вроде получилось.
Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 22:26 30-01-2012
Bulat_Ziganshin

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
SREP 3.0 released:
  • -m1f..-m3f: Future-LZ compression; -m3f now is the default mode
  • -mem: limit amount of RAM used for Future-LZ decompression
  • -vmfile and -vmblock options fine-tune VM file used in -mem mode
  • -mBYTES: copy matches longer than BYTES directly from outfile
  • 3x faster compression: I/O and MD5/SHA1 tasks were offloaded into separate thread
  • unrolled internal loop, unrolling factor controlled by -a option, -a1 is the slowest but requires least memory
  • -nomd5: don't store/check MD5 checksum of every block
  • -mmap: use memory-mapped file for match checking by I/O
  • when necessary, temporary file is created automatically
  • made stderr always unbuffered (useful for GUIs around srep.exe providing progress indicator)
  • "srep" and "srep -d" commands now work as a filter if stdin and stdout are redirected
  • 64-bit version now can use >4 GB of RAM
  • fixed bug when compressing data from pipe (i.e. producer | srep)
Changes since the latest alpha:
  • files compressed with -nomd5 tagged with special flag in the compressed file header, so that -nomd5 is automatically applied on their decompression with appropriate message to user
  • added date, version, copyright and other exe resources to windows executables
More info at http://freearc.org/research/SREP.aspx
 
 
Релиз SREP 3.0:
  • -m1f..-m3f: Future-LZ сжатие; -m3f теперь - режим по умолчанию
  • -mem: ограничивает объём ОЗУ, используемый для Future-LZ распаковки
  • -vmfile и -vmblock: опции, настраивающие файл подкачки, используемый при ограничении ОЗУ опцией -mem
  • -mBYTES: копировать матчи длиннее BYTES байт напрямую из выходного файла
  • 3-кратно ускорена упаковка: I/O и вычисление MD5/SHA1 вынесены в отдельный тред
  • развёрнут внутренний цикл упаковки, коэф. разворачивания настраивается опцией -a, -a1 - самый медленный режим, но использует чуть меньше памяти
  • -nomd5: не запоминать/проверять MD5 хеши блоков
  • -mmap: использовать отображение файлов в память для проверки матчей через I/O
  • при необходимости временный файл создаётся автоматически (если не указано -temp= без параметра)
  • stderr никогда не буферизуется (полезно для GUI-программ, выводящих индикатор прогресса для srep.exe)
  • "srep" и "srep -d": эти команды теперь работают как фильтр, если stdin и stdout перенаправлены
  • 64-битная версия теперь может использовать >4ГБ ОЗУ
  • исправлена ошибка при сжатии данных, полученных по конвейеру (например, producer | srep)
Изменения с последней альфы:
  • файлы, сжатые с -nomd5, помечаются спецфлагом в заголовке сжатого файла, так что -nomd5 автоматически используется и при их распаковке с выводом соответствующего сообщения пользователю
  • добавлены дата, версия, копирайт и прочие exe-ресурсы в виндовые exe-файлы
Хотите узнать больше? http://freearc.org/research/SREP.aspx
Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 02:32 31-01-2012 | Исправлено: Bulat_Ziganshin, 02:32 31-01-2012
newbie2k6

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Eagle1726
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?
Если эти файлы уже упакованные, то, по идее, от дополнительной компрессии архиватором будет мало пользы. Другое дело — форматы вроде WAV, которые можно сжимать как с потерями данных (англ. "lossy"; например, в формат MP3), так и без потерь (англ. "lossless"; например, в формат FLAC). Без конкретики это, в общем-то, праздный разговор.
Всего записей: 117 | Зарегистр. 05-10-2006 | Отправлено: 08:52 31-01-2012
WildGoblin



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

Цитата:
-mx определяется как -m9, так что вопрос просто в везении.
Действительно, в везении - вчера упаковывал одну игрушку (я не "репакер" - просто файлики у себя в порядок привожу...) и вылетела ошибка уже с -m9.
 

Цитата:
а в чём проблема - в твоей машине иди моей программе, надо разбираться, тестировать сжатие присланных тобой файлов
7z и рар архивы создают без проблем.
P.S. Если надо что-то протестировать для решения проблемы, то я всегда готов!
Всего записей: 33353 | Зарегистр. 15-09-2001 | Отправлено: 09:29 31-01-2012
Shuld

Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
Как и обещал, выложил тест с новой линейкой методов –m81…-m89 здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6
Линейка методов имеет примерно равномерный шаг возрастания времени сжатия от метода к методу и составляет 1,4…1,5.
Расшифровка методов:
 
 
Добавлено:
Метод Расшифровка метода Примерное соответствие стандартному методу    
-m81 8rep+xtor:3:4m:h64k -m1    
-m82 8rep+xtor:6:4m:h512k:l2    
-m83 8rep+xtor:6:4m:h1m -m2    
-m84 rep:1gb+4x4:tor:6:4mb:h8mb    
-m85 rep:1g+xlzma:4mb:h512k:fast:128:mc8 -m3    
-m86 8rep+xlzma:4m:h1m:normal:24:mc8 -m4    
-m87 rep:1gb:h24+4x4:t3:i0:lzma:8mb:h32mb:normal:bt4:128 -mex6    
-m88 rep:1g+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128 -mex9    
-m89 rep:1g+4x4:t1:i0:lzma:128mb:h128m:normal:bt4:128

С каждым методом связана определенная серия тестов.
Так, например, -m3 = rep:96m+xlzma:8m:h1m:fast:8:mc4.
Прежде всего, при увеличении fb8 в моих тестах степень сжатия росла без увеличения времени сжатия (в отличии от lzma:max), особенно на первых шагах: 16, 32. И только при fb256 время чуть-чуть увеличивалась. Поскольку сжатие в последнем случае практически не менялось, то я остановился на 128. Mc4 достаточно хорошо, как и mc8, в отличии от mc2 – время уменьшается мало, а степень сжатия сильно, или mc16 – наоборот, время сильно растет, а степень сжатия не очень. Кроме того h512k в моих тестах оказалось более сбалансированным по эффективности. В результате, xlzma:4mb:h512k:fast:128:mc8 в моих тестах оказалось одновременно быстрее и сильнее по сжатию, чем оригинал.
Также отмечу, что tor:6 в сопоставимых режимах эффективнее, чем tor:5. Под сопоставимыми режимами я имею ввиду: tor:5:l2 - tor:6:l2, tor:5(:l4) - tor:6:l4, tor:5:l8 - tor:6(:l8), где в скобках – значения по умолчанию. Tor:6 тратит примерно столько же времени, как и tor:5, но сжатие всегда сильнее.
Кроме «основных» методов –m81…-m89 у меня есть «промежуточные», с дополнительной третей цифрой:
-m811…-m814, -m821, -m822, -m841…-m843, -m861…-m864, -m871, -m872
Где по времени и степени сжатия понимается ряд –m81, -m811, -m812, …, -m814, -m82, -m821, …
Если возникнет необходимость «сжать» или «растянуть» методы, можно просто переименовать нужные.
Для 4 потоков получился более-менее равномерный ряд. Последние методы дают шаг по времени за счет уменьшения числа потоков. Но на 2-ядерном процессоре эти последние методы «сливаются» в кашу. Если сделать равномерный ряд для 2-ядерного процессора, то для 4 потоков последние методы будут очень разряжены. А еще существуют 8-ядерные процессоры… К сожалению, идеала не существует.
Ну все.
Всего записей: 364 | Зарегистр. 08-12-2010 | Отправлено: 21:07 01-02-2012 | Исправлено: Shuld, 21:20 01-02-2012
Bulat_Ziganshin

Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Shuld
1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю - это может зависеть от типа данных. хотя с другой стороны, я сам это вообще не тестировал, скопировал готовые настройки из однопоточных режимов, оптимизацией которых я занимался ещё на старом cpu
 
2. предлагаемые тобой методы сжатия требуют много памяти для распаковки, что заставляет задуматься о том, как их можно использовать, не создавая проблем. я разные способы передумал, сейчас склонился к тому, чтобы всё же встроить srep в fa, но пока это дело будущего
 
3. на настоящий же момент я оптимизировал rep, добавил его в -m1 и оптимизировал настройки rep в -m2..m4 что повысило сжатие на 1-2% без потерь скорости
 
 
теперь что касается внедрения srep. произойдёт это в лучшем случае в 0.80. в январе я сделал очень важную вещь - реализовал поддержку методов с несколькими выходными потоками (как bcj2 в 7-zip). srep в fa будет сделан на основе нынешнего режима -m1f, но сжатые данные будут записываться в два потока - поток литералов и поток матчей. литералы будут писаться (и сжиматься дальнейшими exe+delta+lzma) сразу, а матчи копиться в памяти, и по окончании данных сортироваться по src и только затем сохраняться в архив. соответственно, при распаковке я смогу читать данные из обоих потоков параллельно и сохранять в памяти/vmfile содержимое будущих матчей
 
итого - и при сжатии, и при распаковке чтение и запись данных будет осуществляться чисто последовательно, при этом будет использоваться объём памяти, примерно равный 10% от объёма сжимаемых данных. при необходимости его можно дальше сократить - при упаковке за счёт увеличения -l, при распаковке - за счёт сохранения содержимого матчей во временном файле. помимо этого, можно ещё выцыганить несколько процентов сжатия, используя после srep обычный rep сч небольшим словарям и размером матча, к примеру rep:96m:32
 
 
кстати, пример распаковки 100 гб файла (со 100 гб словарём!!!) с использованием всего 100 мб памяти:
 
D:\>srep64i -d -mem100m m1f.srep nul
100%: 55,214,690,844 -> 98,420,528,640: 56.10%. Cpu 112 mb/s, real 84 mb/s
Matches 0 68925 39805211, I/Os 0, RAM 0/60, VM 0/8808, R/W 221352/221352
 
Добавлено:
Архиватор Размер словаря    
zip 32 кб    
rar 4 мб    
7-zip 64 мб    
freearc 100 гб
Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 11:30 02-02-2012
Profrager



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin
что-то svn не пашет, или он куда-то переместился?

----------
переехал сюда
Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 21:13 02-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 153 154 155 156 157 158 159

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


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

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

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru