» FreeArc (часть 4)

egor23

Цитата:

что-то не заметил gimp-2.6.11.

Да, ты прав

arc l ftp://test.arc
?

Может кто обьяснить почему precomp не все zip архивы распаковывает???


Цитата:

Precomp v0.4.1 - ALPHA version - USE FOR TESTING ONLY
Free for non-commercial use - Copyright 2006-2010 by Christian Schneider

Input file: D:\TRASH\precomp\iw_00.iwd
Output file: D:\TRASH\precomp\iw_00.pcf

Using PACKJPG.DLL for JPG recompression.

--> packJPG DLL v2.4WIP4 (11/06/2008) by Matthias Stirner <--
More about PackJPG here: http://www.elektronik.htw-aalen.de/packjpg

100.0% - New size: 3425029 instead of 3872030

Done.
Time: 2 minutes, 7 seconds

Recompressed streams: 1/1245
ZIP streams: 1/1220
zLib streams (slow mode): 0/25

You can speed up Precomp for THIS FILE with these parameters:
-zl11 -l0

Fast mode does exactly the same for this file, only faster.

В итоге файл получается даже чуть меньше и жмется гораздо хуже чем исходный

loky88

Цитата:

Может кто обьяснить почему precomp не все zip архивы распаковывает?

Цитата:

FreeArc: бесплатный open-source архиватор

Цитата:

В итоге файл получается даже чуть меньше и жмется гораздо хуже чем исходный

Потому что мануал читать нужно.

Добрый день!
Подскажите, пожалуйста, что это за функции stdin/stdout в srep? как ими работать?

juvaforza
Сколько не переключал языки ввода EN-RU-EN-RU... горячие клавиши FA (у меня windows 7, х86, 2 Гб ОЗУ) работают без проблем. Возможно, потому, что я не переключаю раскладку, а языки ввода.

Bulat_Ziganshin
Пришла в голову идея как улучшить работу SREP. Прошу не считать шуткой, но попытаюсь объяснить на примере ежиков. Необходимо сжать кучу файлов-ежиков.
Пускай у первого ежика 2000 иголок, у второго 1999, ежики близнецы. Получается после обработки первого ежика начинается побитовое (поиголочное) сравнение второго ежика с первым. SREP определяет, что 1-я иголка второго ежика такая-же как и 1-я иголка первого ежика, 2-я такая же как и 2-я у первого, 3-я - как 3-я у первого... Т.е. 1999 раз записывается, что иголки одинаковы у обоих ежиков.
Нельзя ли придумать метод или способ записи данных о втором ежике, типа Второй ежик = Первый ежик - (минус) 1 иголка?
Т.е. после полного анализа иголок второго ежика как бы сделать сравнение группы иголок и при обнаружении, что 1999 иголок одинаковы - упустить запись о каждой из иголке, а оставить инф. что все 1999 иголок такие же.

Цитата:

Сколько не переключал языки ввода EN-RU-EN-RU... горячие клавиши FA (у меня windows 7, х86, 2 Гб ОЗУ) работают без проблем. Возможно, потому, что я не переключаю раскладку, а языки ввода

У меня (windows ХР, х86, 4 Гб ОЗУ) и такая роблемае есть при переключении языка ввода (не работает на UA, RU, а работает только на EN)

Spate
Спасибо за подробный ответ.
Сам бы ни когда не догадался.

ruduk
побрей обоих ежиков и сложи все иголки в один мешок, а там уж их и сравнивай (=объеденить 2 файла каким-либо архиватором без сжатия, типа .tar и пустить под srep). И ничего придумывать не надо.

Windows 2003 Server x64 - FreeArc альфа версия: 0.67
1. Запаковал сайт ~ 5 Гб.
2. Пригнал
3. Открыл архив
4. Выделил папки и начал распоковку
5. Распаковка закончилась
6. Окошко первое архиватора продолжает висеть и видно что ест память.

причём ест как-то волнообразно.
набирает до ~ 1800Mб и сбрасывается до 1300Мб и снова начинает расти и так несколько раз.

выгрузился FA только принудительно.

slech

Цитата:

1. Запоковал сайт ~ 5 Гб.

а сколько файлов было?

egor23
Цитата:

а сколько файлов было?

Цитата:

C:\Program Files (x86)\FreeArc\bin>arc x -dpW:\test1 D:\Production.arc *
FreeArc 0.67 (November 17 2010) extracting archive: D:\Production.arc
Extracted 474,295 files, 5,728,620,124 => 7,333,344,101 bytes. Ratio 78.1%
Extraction time: cpu 1369.44 secs, real 6242.61 secs. Speed 1,175 kB/s
All OK

консоль отработала нормально.

Добавлено:
GUI1
6.82 GB (7,333,344,101 bytes)
472,167 Files, 2,120 Folders

GUI2
6.82 GB (7,333,344,101 bytes)
472,167 Files, 2,120 Folders

Console
6.82 GB (7,333,344,101 bytes)
472,167 Files, 2,128 Folders

Т.е. судя по всему отработали одинаково, но GUI при этом ещё и повис.

slech
1. вообщем "особенности" GUI
2. "особенность" работы с большим кол-вом файлов

Bulat_Ziganshin
Вопрос этот уже подымался, но решил ещё сделать несколько тестов

Цитата:

1. Запаковал сайт ~ 5 Гб.
2. Пригнал
3. Открыл архив
4. Выделил папки и начал распоковку
5. Распаковка закончилась
6. Окошко первое архиватора продолжает висеть и видно что ест память.

1. Фейк на 50 000 файлов (5 папок по 10 000 файлов)
2. Упаковал -mrep:10m
3. Открыл архив (памяти отъелось 94МБ)
4. Выделил папки и начал распаковку
Памяти после распаковки отъелось 763МБ, причём в последний момент распаковки 382МБ-763МБ
(arc x 50000_10.arc "начинает" с 63МБ заканчивает распаковку при занятых 470МБ)
правда цифры разняться в одном случае 470МБ, в другом 332МБ - ?! непонятно

Замечание
1. FreeArc GUI не высвободил память, которая была занята во время распаковки.

http://gettyfile.ru/693510/

PS: эксперементы лучше ставить на ram-drive, распаковали раз\два... потом удалили диск.

Profrager

Цитата:

побрей обоих ежиков и сложи все иголки в один мешок, а там уж их и сравнивай

а как их потом распаковать и определить где чья иголка?
Ладно. Вот второй пример. Есть две книги: Первая на 2000 страниц и Вторая на 1999 страниц. SREP проанализировав Вторую книгу пишет отметки на 1-й странице Второй книги типа "Смотри 1-ю страницу Первой книги", на 2-й странице - Смотри 2-ю страницу Первой книги ... и так 1999 раз. Т.е. в итоге выходит 2000 страниц Первой книги + 1999 страниц Второй с ссылками на страницы Первой книги.
По моей идее выгодней хранить всю Первую книгу (2000 страниц) и Вторую книгу с 1 страницей, на которой написано, типа "1999 страниц этой книги повторяют 1999 Первой книги".

Цитата:

По моей идее выгодней хранить всю Первую книгу (2000 страниц) и Вторую книгу с 1 страницей, на которой написано, типа "1999 страниц этой книги повторяют 1999 Первой книги".

Если я правильно понимаю, то это diff (или как-то так)

Цитата:

1999 раз записывается, что иголки одинаковы у обоих ежиков.

Неправда. Если все 1999 иголок идут подряд, то записывается "см. 1999 иголок 2000 иголок назад"

ruduk
все, что ты пишешь - это и есть srep (только эти 2 файла надо слить в один, чтобы получился требуемый эффект) ,или xdelta3 (diff) с размером буфера >=размера файла (что не всегда возможно).

Profrager
да, я знаю как работает LZ77. Вместо значений сжимаемой последовательности SREP вставляет ссылки на ранее обнаруженные такие-же последовательности. Я предлагаю уменьшить количество этих ссылок, тем самым уменьшиться размер файла на выходе. Ведь прочитав команду, как сказал выше Registered User:
Цитата:

"см. 1999 иголок 2000 иголок назад"

, выполнить ее быстрее, чем 1999 раз перечитывать данные вперед-назад по одной иголке. Я подумал раз уж SREP может находить байт-точные совпадения, то можно попробывать осуществить прямое сравнение группы байт. Начать сравнением по 2-байта и как пирамида поднимающаяся вверх дойти до группы из 8 байт.
Это всего лишь идея, поиск возможности улучшить SREP, который (не просто так) все хотят сделать частью FA. Не воспринимайте мою идею или то, как я пытаюсь объяснить ее вштыки. В споре рождается истина.

Цитата:

то можно попробывать осуществить прямое сравнение группы байт. Начать сравнением по 2-байта и как пирамида поднимающаяся вверх дойти до группы из 8 байт.

?

Registered User
Попробую объяснить:

Цитата:

8
4 4 4 . . .
2 2 2 2 2 2 . . .
1 1 1 1 1 1 1 1 11 11 . . .

Если, например, есть последовательность АBCDEFGH...ABCDKLMN (каждый символ по 1 байт), то сравниванием по 1-байт можно определить повторения (совпадения) для А, В, C, D:
(А)(B)(C)(D)EFGH...(A)(B)(C)(D)KLMN
Для первого прохода идет поиск совпадений с элементом, стоящим до и после текущего элемента. Т.е. можно определить повторяющиеся группы АВ и CD:
(АB)(CD)EFGH...(AB)(CD)KLMN
На следующем проходе определить, что после AB идут CD и записать их как одну группу из 4-байт:
(АBCD)EFGH...(ABCD)KLMN
На третьем проходе идет поиск групп по 8-байт (какбы идеальный вариант). Но, наверно, ресурсов будет использовать много.

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 мб, для которых не найдены совпадения.
Т. е. я хочу сказать, что для записи больших повторов в срепе и так требуется относительно мало байт индексных данных.

Profrager
Моя идея свести количество индексных данных к минимуму, для более быстрой распаковки.
Возвращаясь к примеру с книгами, допустим Первая книга уже прочитана и "возвращена в библиотеку" (распакована). Начинаем читать Вторую книгу. На 1-й странице написано "Читай 1-ю страницу Первой книги", кладем книгу на стол, идем в библиотеку, читаем 1-ю страницу Первой книги, возвращаем книгу на полку, идем обратно к второй книге, читаем что написано на 2-й странице - "Читай 2-ю страницу Первой книги" -- кладем книгу на стол, идем в библиотеку . . . И так 1999 страниц.
Лучше один раз прийти в библиотеку и прочитать сразу 1999 страниц, т.е. минимизировать переходы туда-сюда. А сжать/распаковать последующим LZMA 1 ссылку на 1999 страниц будет быстрее/проще, чем сжимать 1999 отдельных ссылок на отдельные 1999 страниц, пускай даже они занимают по 16 байт.
Пускай размер файла уменьшится всего на пару килобайт, но возростет скорость распаковки записанного таким способом файла.

ruduk

Цитата:

Моя идея свести количество индексных данных к минимуму, для более быстрой распаковки.

В твоем случае это просто надо размер буфера с 8 мб увеличить до допустим 512, или же реализовать "запоминание" самых мелких, далеких и часто используемых совпадений в пределах указанной оперативной памяти. Только тогда можно уменьшить обращения в жесткому диску. Хоть в общем то кеширование винды (семерки) в этом и так сильно помогает.

Добавлено:
И в реальных условиях редко очень бывает последовательно одинаковые данные больших размеров. Обычно крошится на много-много мелких кусков в разных частях файла. Это тоже самое что надо различные страницы в разных книгах искать по всей библиотеке, а на столе умещается только определенное количество книг. Все равно за другими бегать придется, всю библиотеку на стол не уместить.

При упаковке ФА в режиме "Без сжатия" файлы которые добавляются в архив упорядочиваются или добавляются в случайной последовательности???

Profrager

Цитата:

И в реальных условиях редко очень бывает последовательно одинаковые данные больших размеров

режим по-умолчанию -m3 в SREP никто не отменял, он будет работать во всех случаях. Целью создания SREP было создание препроцессора для обработки больших файлов, и в Huge Files Compression Benchmark он показал себя с лучшей стороны. В некоторых случаях, отдельные файлы все-же будут максимально похожи друг на друга (например, текстура окна и текстура окна с маленькой форточкой внутри какого-нибудь *.gcf или *.pack игрового файла). Тогда на них можно будет дополнительно определить совпадения большей длинны.
ЗЫ. Не думал что будет такое бурное обсуждение, это же идея, ее можно проверить если попробовать реализовать

VasulNoz
читай документацию: этот раздел
Цитата:

... задайте опцию –dsgerpn (или какой порядок вам нужен) явно.

ruduk

Цитата:

... задайте опцию –dsgerpn (или какой порядок вам нужен) явно

Что и где надо прописать в arc.ini чтобы это опция была по умолчанию, объясните подробно.

ruduk
Я все это и так знаю. Я тебе говорю, что совпадения длиной больше размера буфера очень редко встречаются. Я тебе алгоритм работы как раз режима -m3 парой постов раньше описал. Ты посмотри вовнутрь алгоритма и внутрь среднестатистического среп-файла, длины совпадений размером хотя бы в буфер я еще не встречал.
Ты говоришь теоретически, не представляя как все это есть сейчас и как это можно реализовать программно. Я тебе примеры возможной реализации уже описал.
Плюс ты не понимаешь, что 99% потери времени занимает доступ к мелким совпадениям, а не крупным (они и так будут читаться блоками по 8мб, и ускорения от убирания границ 8-ми мегабайтного буфера будут микросекунды на гигабайтном файле).

Profrager
мы с тобой говорим, как-будто я хочу испортить SREP. Это ведь только идея. Ты считаешь, что она плохая. Нужно узнать, что думает по этому поводу Булат.

VasulNoz
если через Arc.ini, то в раздел [Default options] в самом верху, или в строку упаковки.
если через GUI, то просто выбрать желаемую сортировку на закладке "Архив"

Цитата:

При упаковке ФА в режиме "Без сжатия" файлы которые добавляются в архив упорядочиваются или добавляются в случайной последовательности???

они идут в том порядке, в котором записаны в каталоге на диске. для ntfs это сортировка по каталогу и имени файла получается

и прочти наконец доку. раздел с описанием arc.ini там есть

Добавлено:
ruduk
на мой взгляд тут обсуждать даже нечего

но глядя на этот флейм я вроде допёр как улучшить сжатие связки (s)rep+lzma. если мы при запуске srep знаем с каким словарём будет lzma, то надо просто пропускать тело совпадений при дистанции меньше lzma:dict - поскольку точно известно что их и lzma cожмёт, причём куда эффективней

правда, при очень больших совпадениях эффект от уменьшения файла и соответственно дистанций для lzma всё же перевесит. т.е. получается что оптимальным может быть такой вариант:
при дистанции <64 мб и длине совпадения <4 кб - пропускаем эти данные на выход (не ища в них других совпадений!)
при дистанции <64 мб и длине совпадения >4 кб - кодируем
при дистанции >64 мб и длине совпадения >32 байт - кодируем


Добавлено:
правда копирование по 32 байта на больших дистанциях будет тем ещё цирком - даже если хватит памяти для сжатия...

Какой тип сортировки посоветуете? (GUI)