Widok Moderator-Следопыт Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Часть 1 | Часть 2 | Часть 3   Бесплатный open-source архиватор для Windows и Linux, сочетающий высокую степень сжатия и большой набор возможностей Официальный сайт (домен просрочен ~2017.03) | Скриншоты | Лента новостей | Документация на консольную версию | Документация на GUI версию Сообщество пользователей FreeArc | Вики | Трекер (рассылка по ошибкам) | Проект на SourceForge.net | SVN-репозиторий Поддержка InnoSetup | Поддержка NSIS | Обсуждение на encode.su (англоязычное) | FAQ по FreeArc Скачать последний релиз - 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

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ruduk ну srep ведь прекомпрессор,и низкие значения искомых строк могут ухудшить последующее сжатие более мощным алгоритмом. В любом случае в srep есть минимальная длина искомых строк,меньше которой совпадения не будут обрабатываться, а если встретится блок бОльшего размера вплоть до размера буфера, схожий с каким-либо предыдущим большИм блоком, он будет обрабатываться как один единый блок,т.е. на него отведется всего 16байт (может и ошибаюсь с циферкой,пишу по памяти). Т.е. ворачиваясь к ежикам, можно объяснить так, допустим имеются 2 ежика, у которых по 2000 иголок, но у второго 1992 иголок такие же как у первого, а 8-другие. Представим это в виде файлов. Имеем 2 файла с практически одинаковым содержимым размером по 2000мб, у второго 8 последних мегабайт отличаются от данных первого файла. Объединим файлы в один, чтобы среп их оба последовательно обработал. Допустим что в первом файле пересекающиеся данные не встречаются, т.е. среп в них не нашел схожие блоки, и т.к. размер буфера в среп 8 мб, то на выходе будем иметь 2000мб+ (2000/8)*16 байт на оглавление среп-файла (плюс еще пару десятков байт на блок, но суть не в этом). т.е. 2000мб+4000байт( ну мож 8кб если посчитать некоторые не указанные тут данные). При начале сканирования второго файла в потоке, среп увидит, что данные схожи с первым, при чем схожесть будет блоками размером с буфер (8мб), т.е. за записи 1992мб схожих с предыдущими понадобится (1992/8)*16 байт=3984байта (как и в предыдущем случае на самом деле будет чуть меньше 8кб) + оставшиеся 8 мб, для которых не найдены совпадения.   Т. е. я хочу сказать, что для записи больших повторов в срепе и  так требуется относительно мало байт индексных данных. ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 11:40 09-02-2011 | Исправлено: Profrager, 11:45 09-02-2011

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ruduk Цитата: Моя идея свести количество индексных данных к минимуму, для более быстрой распаковки. В твоем случае это просто надо размер буфера с 8 мб увеличить до допустим 512, или же реализовать "запоминание" самых мелких, далеких и часто используемых совпадений в пределах указанной оперативной памяти. Только тогда можно уменьшить обращения в жесткому диску. Хоть в общем то кеширование винды (семерки) в этом и так сильно помогает.   Добавлено: И в реальных условиях редко очень бывает последовательно одинаковые данные больших размеров. Обычно крошится на много-много мелких кусков в разных частях файла. Это тоже самое что надо различные страницы в разных книгах искать по всей библиотеке, а на столе умещается только определенное количество книг. Все равно за другими бегать придется, всю библиотеку на стол не уместить. ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 16:47 09-02-2011 | Исправлено: Profrager, 16:54 09-02-2011

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ruduk Я все это и так знаю. Я тебе говорю, что совпадения длиной больше размера буфера очень редко встречаются. Я тебе алгоритм работы как раз режима -m3 парой постов раньше описал. Ты посмотри вовнутрь алгоритма и внутрь среднестатистического среп-файла, длины совпадений размером хотя бы в буфер я еще не встречал. Ты говоришь теоретически, не представляя как все это есть сейчас и как это можно реализовать программно. Я тебе примеры возможной реализации уже описал. Плюс ты не понимаешь, что 99% потери времени занимает доступ к мелким совпадениям, а не крупным (они и так будут читаться блоками по 8мб, и ускорения от убирания границ 8-ми мегабайтного буфера будут микросекунды на гигабайтном файле). ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 10:42 10-02-2011 | Исправлено: Profrager, 10:44 10-02-2011

Bulat_Ziganshin Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: При упаковке ФА в режиме "Без сжатия" файлы которые добавляются в архив упорядочиваются или добавляются в случайной последовательности??? они идут в том порядке, в котором записаны в каталоге на диске. для ntfs это сортировка по каталогу и имени файла получается   и прочти наконец доку. раздел с описанием arc.ini там есть   Добавлено: ruduk на мой взгляд тут обсуждать даже нечего   но глядя на этот флейм я вроде допёр как улучшить сжатие связки (s)rep+lzma. если мы при запуске srep знаем с каким словарём будет lzma, то надо просто пропускать тело совпадений при дистанции меньше lzma:dict - поскольку точно известно что их и lzma cожмёт, причём куда эффективней   правда, при очень больших совпадениях эффект от уменьшения файла и соответственно дистанций для lzma всё же перевесит. т.е. получается что оптимальным может быть такой вариант: при дистанции <64 мб и длине совпадения <4 кб - пропускаем эти данные на выход (не ища в них других совпадений!) при дистанции <64 мб и длине совпадения >4 кб - кодируем при дистанции >64 мб и длине совпадения >32 байт - кодируем     Добавлено: правда копирование по 32 байта на больших дистанциях будет тем ещё цирком - даже если хватит памяти для сжатия... Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 14:11 10-02-2011 | Исправлено: Bulat_Ziganshin, 14:22 10-02-2011

ruduk Junior Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Bulat_Ziganshin Цитата: глядя на этот флейм я вроде допёр как улучшить сжатие связки (s)rep+lzma ежики незря, значит, приснились . Правду говорю Всего записей: 123 | Зарегистр. 08-02-2009 | Отправлено: 16:12 10-02-2011 | Исправлено: ruduk, 22:44 10-02-2011

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Bulat_Ziganshin Цитата: правда копирование по 32 байта на больших дистанциях будет тем ещё цирком - даже если хватит памяти для сжатия...   32 еще куда ни шло) а вот 16 или 8 длина поиска - это да) на 4 гб файле у меня часа 2 винт будет мучить)   P.S. на сколько увеличивается скорость обработки подобного большого файла с маленьким размером строки поиска, если hdd сменить на ssd? Стоит ли оно того? Помню ты писал чего-то про ssd, но уже не помню какая разница была.   Цитата: если мы при запуске srep знаем с каким словарём будет lzma, то надо просто пропускать тело совпадений при дистанции меньше lzma:dict - поскольку точно известно что их и lzma cожмёт, причём куда эффективней гуд идея, но по-моему ты уже где-то писал пободное) Цитата: получается что оптимальным может быть такой вариант: ... хорошо, если можно было бы все эти параметры условий задавать вручную,а не юзать статичную модель. ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 16:25 10-02-2011

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Bulat_Ziganshin Цитата: что касается hdd->ssd, то чтение маленьких блоков данных быстрее примерно на два порядка. но ради одного srep я не вижу смысла на ssd переходить - ибо у тебя-то упакуется быстро, а вот потом как распаковывать? достаточно иметь озу на 2-4 гига больше чем у своих пользователей загрузка винды/основных прог + своп-файл + srep = ssd Оперативки 8 гб. Винда кеширует 4гига где-то) Все равно мало)   По теме топика. Возможно ли реализовать фильтр в ФА с динамически меняющимся размером блока? Т.е. на входе надо детектить необходимый заголовок и соответственно подстраивать текущий блоксайз. А то с постоянной его величиной геморно как-то создать задуманное) З.Ы. мож это все и расписано в исходниках, но я тока мельком реп смотрел, так что сильно не бить! ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 00:02 11-02-2011

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: вообще в srep есть что улучшить. я например знаю как увеличить скорость сжатия в несколько раз, но кому и зачем это нужно? ну в общем то не особо нужно, но полезно Цитата: например, у меня была такая идея - если сделать srep первым алгоритмом в цепочке сжатия, то при распаковке он будет последним. тогда получится что временный файл при распаковке не нужен Ну сейчас в основном пакуют rep(.arc)->srep->lzma, дабы снизить многократные рандомные обращения к винту в момент распаковки srep убрав излишки rep'ом. Цитата: тогда получится что временный файл при распаковке не нужен - можно данные копировать напрямую из ранее распакованных файлов. проблем две - первое, тогда из архива нельзя распаковать только часть файлов (или можно, записывая данные пропускаемых файлов всё же во временный файл). второе - цепочка srep+precomp+lzma жмёт хуже, нежели precomp+srep+lzma тож думал об этом, только проблем таковых не видел) Да и не вижу сейчас 1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все. 2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу. Цитата:  сейчас precomp, как и положено LZ, записывает откуда из истории надо скопировать данные на текущее место наверное ты имел ввиду srep. Цитата: при декодировании данных сразу будут определяться места в выходном файле куда их надо записать. эта идея должна была разрешить проблемы с нагрузкой на кеш диска при распаковке тока пакер будет небось раз в 10 сложнее текущего) Цитата: архиватор при распаковке обычно считает crc распаковываемых файлов для проверки целостности, здесь это придётся делать отдельным проходом нда, реально проверочный проход был бы лишним.. Цитата: во-вторых, при кусках данных в 512 байт запись такого куска в выходной файл, я боюсь, может потребовать сначала чтения целого кластера (4кб, а на ssd и все 128 кб) так и вижу анти-рекламу: srep - убийца ssd В текущей реализации lz винда будет кешировать запись, а там уже фигушки на таких расстояниях..)   Цитата: я не понял твоего вопроса фильтр=еще один алгоритм, типа delta, rep и т.д. Хочу алгоритм оптимизации dds'ок попробовать вделать.   ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 00:32 11-02-2011 | Исправлено: Profrager, 00:35 11-02-2011

Bulat_Ziganshin Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: По теме топика. Возможно ли реализовать фильтр в ФА с динамически меняющимся размером блока? Т.е. на входе надо детектить необходимый заголовок и соответственно подстраивать текущий блоксайз да, конечно. на уровне API, предоставляемого FA, есть просто операции "прочитать N байт из входного потока" и "записать N байт в выходной поток". и вообще проще написать прогу, работающую с stdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит   Цитата: 1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все   ну а как инсталяции, где можно установить то или это?   Цитата: 2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.   проблема в том, что можно srep интегрировать в fa чтобы при распаковке не создавать временных файлов. но только с этими двумя ограничениями. без них - только так, как уже сейчас работает, только exe-шник внещний вызываться не будет   Добавлено: Цитата: тока пакер будет небось раз в 10 сложнее текущего) нет. можно даже сейчас реверсировать файл и сжать его нынешним srep - тогда ссылки на "прошлое" автоматом станут ссылками на будущее  ну а затем "реверсировать" выходной файл srep и готово   а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла   если же буфер переполнился, то из него выкидывается *содержимое* наиболее далёких и длинных LZ строк (в надежде что на практике будут выкидываться только строки с длиной >>4кб), при этом:   - если у нас есть физический выходной файл (не stdout) и строка достаточно велика (N*128kb), то мы её сразу на нужное местои записываем - если у нас есть физический входной файл, то строку просто выкидываем - потом скопируем из него - иначе - скидываем строку в temp file   ну и вместо самой строки делаем отметочку как мы с ней поступили. когда дело дойдёт до декодирования этого места - поступаем соответственно этой отметке   что тут действительно имеет нехилую логику - так это декодер. зато реализуется вековая мечта человечества - распаковка с 10 гб словарём с буфером в 500 мб     хотя может всё это и не TRUЪ, а правильно - разбить данные на 128 кб куски, посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 01:06 11-02-2011 | Исправлено: Bulat_Ziganshin, 13:58 11-02-2011

Profrager Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: ну а как инсталяции, где можно установить то или это? Обычно где есть выбор либо то, либо это устанавливать, архив(ы) с этими файлами на выбор не на столько велики, чтобы для них использовать srep, rep'а хватает. Не знаю, мне пока такое не требовалось на больших объемах данных Цитата: проблема в том, что можно srep интегрировать в fa чтобы при распаковке не создавать временных файлов. но только с этими двумя ограничениями. в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать Цитата: без них - только так, как уже сейчас работает, только exe-шник внешний вызываться не будет и то хорошо Цитата: и ссылки на них хранятся в отсортированном по destination offset виде. представляю сколько времени надо будет декодеру отсортировывать список каждую итерацию..особенно где нить в конце, когда уже записей под несколько десятков тысяч. Тормозить же будет не хило Цитата: а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла подобная идея у меня родилась давно, но даж боюсь браться за такое Цитата: а правильно - разбить данные на 1228 кб куски а почему именно эта цифра? Цитата: посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?   Добавлено: Цитата: и вообще проще написать прогу, работающую сstdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит кстати заметил такую штуку: lzma_x64 (или как его там) в виде внешнего фильтра один раз из 10 вешает упаковку на 0%. При чем он как бы чего то ждет, не отъедая % от проца. Закрываешь, запускаешь заново - норм отрабатывает. ---------- переехал сюда Всего записей: 888 | Зарегистр. 22-05-2010 | Отправлено: 10:22 11-02-2011

lorents Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Не обращаем внимания ---------- Image Catalyst - оптимизация изображений без потери качества Всего записей: 3299 | Зарегистр. 30-12-2007 | Отправлено: 23:57 13-02-2011 | Исправлено: lorents, 17:15 14-02-2011

Страницы: 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)

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование