» FreeArc (часть 4)

Bulat_Ziganshin

Цитата:

* compression: unrolled internal loop, unrolling factor is defined by -a option
* compression: memory-mapped file used for match checking

а можно поподробней? А то не понятно ни принципа, ни смысла)

Цитата:

* compression: I/O and md5/sha1 tasks are offloaded to separate thread

а что ж декомпрессию стороной обошел?)

З.Ы. Спасибо за релиз)

Цитата:

а что ж декомпрессию стороной обошел?)

я и так со сжатием достаточно повозился


Цитата:

а можно поподробней? А то не понятно ни принципа, ни смысла)

можешь посмотреть исходники, а ещё лучше - патчи в svn

1. процесс сжатия для каждого байта проверяет, не был ли похожий 512-байтный блок раньше. эта проверка требует обращения к памяти (мимо cpu cache), а это очень дорогая операция - считай мы 5 тактов тратим на все вычисления и 50 на эту проверку. я использовал технику, которая позволяет сократить число этих проверок в 2-16 раз за счёт использования большего объёма памяти

2. одна из причин медлительности сжатия - чтение из сжимаемого файла небольших блоков данных в случайном порядке, что приводит к OS-level call. вместо чтения я отображаю весь файл на память и дальше просто сравниваю участки памяти

Bulat_Ziganshin

Цитата:

вместо чтения я отображаю весь файл на память и дальше просто сравниваю участки памяти

а что если при распаковке создать нечто вроде "списка" с записями типа 1, 2, 3 ,
где 1) - здесь оригинальные данные, к которыйм еще нет совпадений
2) - здесь данные повторяют оригинальные данные из 1)
3) - здесь часть данных (или пару байт) из 1)

и при прочтении списка сразу знать, что нужно прочитать, а потом по этому "списку" в памяти "формировать" готовый участок памяти, пускай даже блоками по 8Мб, типа 1122121232333, который позже брать и писать в файл.
Извини, если недоходчиво изложил идею

Bulat_Ziganshin

Цитата:

Memory usage was also increased (and compression factor decreased a tiny bit). You may restore them back to old values with -a1 option

а чего тогда в 2.93 -a1 памяти требуется больше, чем в 2.92?
и вроде медленней немного работает

[more=лог..]
timer.exe srep293_x64.exe -m3f -a1 -nommap xcmd.TAR.pcf xcmd.TAR.pcf.srep293_a1_m3f1

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
220 mb, -m3f -l512 -c256 -a1
Compression ratio: 3482909069 -> 546450668: 15.69%. Cpu 13.197 mb/sec, real 3.396 mb/sec
Second pass: 100%

Kernel Time = 257.468 = 00:04:17.468 = 21%
User Time = 280.671 = 00:04:40.671 = 23%
Process Time = 538.140 = 00:08:58.140 = 44%
Global Time = 1209.093 = 00:20:09.093 = 100%


timer.exe srep293_x64.exe -m3f -a16 -nommap xcmd.TAR.pcf xcmd.TAR.pcf.srep293_a16_m3f1

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
340 mb, -m3f -l512 -c256 -a16
Compression ratio: 3482909069 -> 547281295: 15.71%. Cpu 12.620 mb/sec, real 3.144 mb/sec
Second pass: 100%

Kernel Time = 261.734 = 00:04:21.734 = 20%
User Time = 292.734 = 00:04:52.734 = 22%
Process Time = 554.468 = 00:09:14.468 = 43%
Global Time = 1278.125 = 00:21:18.125 = 100%


timer.exe srep292_x64.exe -m3f xcmd.TAR.pcf xcmd.TAR.pcf.srep292_m3f1

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
187 mb used for hash, -m3f -l512 -c256
Compression ratio: 3482909069 -> 546450668: 15.69%. Cpu 12.825 mb/sec, real 3.950 mb/sec
Second pass: 100%

Kernel Time = 245.781 = 00:04:05.781 = 24%
User Time = 273.171 = 00:04:33.171 = 27%
Process Time = 518.953 = 00:08:38.953 = 51%
Global Time = 1006.562 = 00:16:46.562 = 100%

[/more]


Цитата:

compression: memory-mapped file used for match checking

Цитата:

Compression made 2-3x faster compared to srep 2.

прирост 2х (-m3f) есть, а воспользоваться на реальных много ГБ данных скорее всего неполучиться, очень жалко HDD, на тестовом подопытном xcmd.TAR.pcf "HDD хрустит прилично", после ~2300МБ infile (столько примерно свободно памяти до начала).

Добавлено:

Цитата:

220 mb, -m3f -l512 -c256 -a1

нет упоминаний про -nommap

а же привел листинг
можно опустить -mlzma это я сделал чтобы сжать данные
а вот -dmlzma можно вводить в поле метода сжатия

может это конечно не совсем правильно использовать программу, но это пока возможно
(сжатие совместно с алгоритмом шифрования наверное тоже не совсем правильно)

Bulat_Ziganshin

Цитата:

slech
не вижу криминала. надо попробовать самому. а ты залей архив на rghost

[more=8 частей по 50 Мб]
http://rghost.net/4506959 - http://rghost.net/download/4506959/d888c3e7c2aa82216c8582520c4686fa7d332964/MS%20Office%202003.7z.001 - MS Office 2003.7z.001
http://rghost.net/4513330 - http://rghost.net/download/4513330/ddb11402513067d27499c35238ac6563ec38bd0c/MS%20Office%202003.7z.002 - MS Office 2003.7z.002
http://rghost.net/4514188 - http://rghost.net/download/4514188/e1efeb450e54278daa5e2a08f3ecb87d182593a2/MS%20Office%202003.7z.003 - MS Office 2003.7z.003
http://rghost.net/4515037 - http://rghost.net/download/4515037/d64c8253811461360cd67f53f5736906fb7890af/MS%20Office%202003.7z.004 - MS Office 2003.7z.004
http://rghost.net/4515054 - http://rghost.net/download/4515054/c0749be62bd44fb180303b5c1b4d4c4d0d89098c/MS%20Office%202003.7z.005 - MS Office 2003.7z.005
http://rghost.net/4515074 - http://rghost.net/download/4515074/deb69bbf2e9af9b0919681a66c6fd895f1bcfd11/MS%20Office%202003.7z.006 - MS Office 2003.7z.006
http://rghost.net/4515086 - http://rghost.net/download/4515086/1bdf84155c4bfce1a264f151ab8f9bc65dcd4fed/MS%20Office%202003.7z.007 - MS Office 2003.7z.007
http://rghost.net/4515106 - http://rghost.net/download/4515106/12fa192aad7fa560b6f077ebf62f79efe636acf6/MS%20Office%202003.7z.008 - MS Office 2003.7z.008
[/more]

да, защиты от дурака в программе нет. я думаю, это не самая важная функция

Bulat_Ziganshin
Где про метод сжатия xtor почитать ? что это такое ?

Цитата:

прирост 2х (-m3f) есть

это на "небольших данных"

программа не может делить архив на тома. автори обещал исправить до конца года.

Скажите, пожалуйста, как сделать автозапуск файлов после самораспакования архива, т.е. чтобы не только распаковывал, но и сразу потом он запускал то что распаковал?
Помогите разработчки софта реализовать данную функцию или может сторонние прогеры знают как сделать это, готов заплатить за данную функцию?

Оставьте контакты для связи (желательно icq)

ndch
xtor - это 4x4:tor
xtor/xlzma/xppmd значит это 4x4:method

Цитата:

т.е. раньше ты давал своё определение precomp (или даже просто использовал встроенное), создавал с ним архивы и теперь эти архивы не распаковываются, поскольку определение поменялось?

Те что запакованы на старой версии распаковываются. Те что запакованы новой - нет.


Цитата:

смотри - если я оставляю своё новое определение precomp=precomp042:t-j, но переношу его в arc.ini, то у тебя появляется возможность его отключить, но тогда у тебя перестанут работать новые галочки Experimental compressors. и более того, ты будешь создавать архивы с методом precomp, т.е. несовместимые с другими пользователями программы. т.е. это решит твою текущую проблему, но создаст ещё больший бардак в будущем

А если просто сделать в анарк.длл перехват обеих названий: precomp (чтоб распаковывались архивы сделаные на старых версиях) и precomp042:t-j, то разве не проще будет?


Цитата:

полноценным решением я вижу признание того, что название precomp уже "захвачено", втч и в настройках arc.ini предыдущих версий freearc, и использование вместо него чего-то нового, скажем unpack

Немного не понял... unpack это вариант названия прекомпа в арк.ини или что-то другое? Вообщем сути не меняет - анарк.длл не распаковывает архивы с прекомпом сделанные на новых версиях. В этом то и вся суть проблемы, как писал выше - добавить в анарк опознание как precomp так и precomp042:t-j.

Цитата:

а чего тогда в 2.93 -a1 памяти требуется больше, чем в 2.92?

потому что сейчас выводится вся использщуемая память - включая 33 мб I/O буферов. раньше их было 16.5 мб


Цитата:

прирост 2х (-m3f) есть, а воспользоваться на реальных много ГБ данных скорее всего неполучиться, очень жалко HDD

если не хватает озу, то нужно использовать -a1 и/или -m1. кроме того, я нашёл проблему в -m3, в след. версии будет гораздо быстрее, надеюсь что на уровне -m2 -l256


Цитата:

нет упоминаний про -nommap

хочу сделать, но это не так просто - mmap может быть отключен из-за нехватки адресного пространства и происходит это позже печати этой строчки

Добавлено:

Цитата:

лог..

без -nommap будет гораздо быстрее

Есть ли в природе DLL, обладающая функциональностью arc.exe или близко к тому? Если нет, то будет?

Цитата:

без -nommap будет гораздо быстрее

у меня нервы треск HDD не выдержали

vishyakov
для упаковки?
если для упаковки то нет
для распаковки unarc.dll

Цитата:

как сделать автозапуск файлов после самораспакования архива

faq в заголовке темы. причитающущюся мне сумму плиз отправь сразу сюда - http://svp-help.narod.ru/index.html?donation.htm (кстати, это ко всем относится)

Добавлено:

Цитата:

у меня нервы треск HDD не выдержали

ну хотя бы первый гиг дождись пока обработается с этой опцией и без неё. я так делал

kalpak
Жаль. Ну ладно, пусть будет хотя бы декомпрессия.

unarc.dll - это которая из пакета InnoSetup support? Она может распаковать любые архивы FA? А как её использвать-то? Документация на неё и API есть?

QSQ
Заблокируйте у себя картинку в браузере. Ее можно переложить на другой сервис, но на руборд нельзя положить.

Bulat_Ziganshin

Цитата:

http://svp-help.narod.ru/index.html?donation.htm (кстати, это ко всем относится)

А это что?

vishyakov
да, она самая
а зачем документация? )) там всего 1 функция (ну еще одна, которую вряд ли кто то будет использовать)
и она та в скрипте примера распаковки объявлена

уплавнялка фильмов, аналог 100 Гц технологии в тв

juvaforza зачем мне лишнее правило из-за 1 картинки в 1 теме? замените
Код: http://i.pixs.ru/storage/4/3/6/a6be7ecb7c_4393823_4901436.png

vishyakov
дело в том, что dll создавалась как часть проекта InnoSetup support и потому никто её специально не документировал. давай сделаем это прямо сейчас - мне для этого нужен как раз такой свежий человек как ты, который бы мог заметить пропуски в описании

итак: unarc.dll позволяет распаковывать архивы FreeArc. для этого она предоставляет функцию FreeArcExtract, пример использования которой вы можете найти в http://freearc.org/download/testing/unarc2011-09-18.7z

Синтаксис вызова:

errcode = FreeArcExtract(callback, command[1], command[2], command[3], ...);

где errcode - код ошибки (FREEARC_OK=0 при успехе, остальные коды можно найти в Common.h)
command[1]... - команда, которую должен выполнить unarc, список должен завершаться NULL или "". синтаксис поддерживаемых команд можно увидеть, вызвав unarc.exe без параметров
callback - ваша функция, которая будет вызываться из FreeArcExtract, может быть NULL

Пример вызова:

int errcode = FreeArcExtract(callback, "x", "-o+", "--", "a.arc", "*.obj", "*.lib", NULL);

С какими параметрами при этом вызывается callback, можно увидеть, откомпилировав и запустив UnarcDllExample.cpp

egor23
Это Булат о «тяжкой участи» разработчиков. Но ведь наш «всегда восторженный герой
готов ... жертвовать собой»

Цитата:

зачем мне лишнее правило из-за 1 картинки в 1 теме? замените

Ну так если тебе так мешает, не заходи сюда. Зачем тебе лишнее правило из за одной картинки в одной теме???

Bulat_Ziganshin
ссылка на исходники SREP не работает
(The requested URL /freearc/trunk/Compression/REP/srep.cpp was not found on this server)

Насчет идеи (моего сообщения на 15 странице): раз уж извесно кол-во всех совпадений (известной длины), то почему бы не собирать выходной файл в памяти? Или проще много раз маленькими частями, чем один раз писать сразу по 8 Мб (незнаю какой участок памяти можно выделить по максимуму, или подобрать оптимальный размер)?

shrmn я залил, смени ссылку: лень, что-ли?