» FreeArc (часть 4)

Bulat_Ziganshin
При всем моём уважении к вам хочу спросить.
Зачем вы пишите особенности версий по английски?
Я думаю что лучше бы вы писали особенности версий на русском так как:
1) 85% людей использующих среп говорят по русски
2) вы же свободно говорите по русски и для вас не будет трудностью писать по русски
3) Зачем давать повод для того чтоб нубы саз;рали форум.. с разными вопросами потому что они ничего не поняли из особенностей.

PS:Может создать отдельную тему для Srep?

Цитата:

Зачем вы пишите особенности версий по английски?

cross-post с encode.ru

ALExey1995
1. тема есть. я от неё как раз отписался поскольку её зафлудили

2. как показывает опыт, чем лучше разжуёшь, тем хуже. если объяснить понятно для 7-летних детей, то набегут 5-летние которые вообще не умеют читать

slech
не вижу вопроса


Цитата:

пробовал распаковать с помощью unarc.dll и inno

это скрипт Шегората? а ISDone как? ОС какая?

Цитата:

это скрипт Шегората? а ISDone как?

Да, пробовал скрипт от Шегората , в isdone я не разбираюсь.

Bulat_Ziganshin

Цитата:

slech
не вижу вопроса

что за неправильный архив создался, где мои файлы в нём ?

slech
команда создания архива? (записывается в freearc.log)

Bulat_Ziganshin

Цитата:

ОС какая?

Ос - Windows XP x32 SP2 + в ВМ Win 7 x32
Тестовый архив создавался с "-s -msrep:m3f" и с "-s -msrep:m3f+lzma:32mb:ultra"
В arc.ini:
packcmd = srep {options} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = srep -d - - <stdin> <stdout>

ПЫСЫ: с "unpackcmd = srep -d $$arcpackedfile$$.tmp $$arcdatafile$$.tmp" распаковывает нормально.

Bulat_Ziganshin
srep 2.92
а меня FreeArc обидел, не хочет упаковывать\распаковывать с srep, виснет, окошко консольное мелькает и всё, при распаковке появляется консольное окошко, но процесс не идёт
а arc работает нормально

arc a a -msrep:m3f:s250m pdf.TAR.pcf

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} -temp=srep.tmp - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

Добавлено:
плин у arc распаковка не работает
зато динамик PC заливается, и в окошке консольном данные бегут

Sig666
egor23

предполагаю, что дело в GUI-шности - код, запускающий внешние утилиты с stdin/stdout видимо написан так, что он корректно работает только в консольных прогах. как-нибудь посмотрю

Цитата:

плин у arc распаковка не работает
зато динамик PC заливается, и в окошке консольном данные бегут

то работает распаковка, а то не работает
....
замечено

при распаковке, если есть файл с таким же именем, то выдаётся запрос на перезапись, то распаковка проходит нормально, а если нет, то динамик пищит...

Добавлено:

Цитата:

а меня FreeArc обидел,

arc тоже обижает

Цитата:

замечено

при распаковке, если есть файл с таким же именем, то выдаётся запрос на перезапись, то распаковка проходит нормально, а если нет, то динамик пищит...

у FreeArc такой фокус не прокатывает

Добавлено:

Цитата:

замечено

при распаковке, если есть файл с таким же именем, то выдаётся запрос на перезапись, то распаковка проходит нормально, а если нет, то динамик пищит...

кстати, если у 7-zip накосячишь с ком.строкой, то помимо всего, есть такое сообщение
ERROR: Идет закрытие канала.
терзают смутные сомнения, а не требуется ли "время" на открытие\закрытие канала.

Bulat_Ziganshin
может подскажешь что с моим архивом не так ?
вроде всё верно сделал, да и в логе всё впорядке вроде.

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

FreeArc0,67а (17 ноября 2010) Метод сжатия –mex5 Особенности Улучшения
Метод сжатия –mex5 полностью выглядит так:
rep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128, $obj => rep:128mb+delta+4x4:i0:lzma:4mb:normal:bt4:128, $text => dict:64mb:80%:l8192:m400:s100+lzp:64mb:90%:65:h22:d1mb+4x4:b7mb:ppmd:8:96mb:c7mb, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 740mb, decompression 751mb, cache 16mb
(Требования к памяти зависят от процессора, в данном случае Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-разрядная, ОЗУ 4 ГБ)

1)    Основной способ сжатия: rep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128
2)    Предлагаю его модифицировать в группах exe и $obj, добавив :h32m:
rep:128mb+exe+delta+4x4:i0:lzma:4mb:h32m:normal:bt4:128
В моих тестах степень сжатия и требуемая память оставались такими же, а скорость сжатия увеличивалась примерно на 10%
3)    Для сравнения сжатие всех данных одним методом, без деления на группы:
-mrep5+exe+delta+4x4:i0:lzma:4mb:h32m:max (что полностью записывается как
-mrep:128mb+exe+delta+4x4:i0:lzma:4mb:h32m:normal:bt4:128)

Результаты сжатия этих трех вариантов, для одного из тестов, а именно http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=60#16 или http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=720#20
Метод  time: cpu  time: real  Размер архива    Memory Memory
for compression     for decompression
1)     1022 с    281,1 с    1 283 998 727    740mb    751mb
2)     938 c    260.1 c    1 283 998 653    740mb    751mb
3)     969 c    249.0 c    1 282 608 960    460mb    176mb
К слову, сжатие без деления на группы получилось самым быстрым, самым сильным и требует меньше всего памяти.

Подробности
Справедливы только для метода сжатия lzma:…:bt4 (или что то же самое lzma:…:max)
Сокращенная запись lzma:4m означает lzma:4m:h8m
Зависимость от параметра «:h» (что он означает – знает только Булат?)
для сжатия по методу вида -mrep5+exe+delta+4x4:i0:lzma:4mb:h32m:max

Метод     time: cpu    time: real    Размер архива    Memory Memory
for compression    for decompression
4m:h64m:max      961 с    251,4 с    1 282 608 956    588mb    176mb
…:h32m:…     968 c    249.8 c    1 282 608 960    460mb    176mb
…:h16m:…     995 c    259.2 c    1 282 608 850    396mb    176mb
…:h8m:…     1054 c    270,8 с    1 282 609 260    364mb    176mb
…:h4m:…     1153 с    295,0 с    1 282 613 168    348mb    176mb
Результаты тестов повторялись на различных данных.

Общая характеристика метода –mex5
Метод не отличается эффективностью, и если только позволяет объем ОЗУ, лучше пользоваться более эффективными методами –mex6, –mex7 или –mex8.

Булат
Просьба оценить мои результаты для использования в FreeArc.

:h означает размер хеша (на каждый тред сжатия, их в твоём случае создаётся 4). посмотри использование памяти в taskman

потребление памяти согласно показаниям самого freearc не изменяется потому, что текстовое сжатие настроено на использование ещё большего объёма памяти:

C:\!\FreeArchiver\Tests>Arc.exe -mrep:128mb+exe+delta+4x4:i0:lzma:4mb:normal:bt4:128 a a -di
Memory for compression 364mb, decompression 176mb, cache 16mb

C:\!\FreeArchiver\Tests>Arc.exe -mrep:128mb+exe+delta+4x4:i0:lzma:4mb:h32m:normal:bt4:128 a a -di
Memory for compression 460mb, decompression 176mb, cache 16mb

C:\!\FreeArchiver\Tests>Arc.exe a a -di -mex5
Memory for compression 740mb, decompression 751mb, cache 16mb

Добавлено:

Цитата:

lzma:…:bt4 (или что то же самое lzma:…:max)

это не одно и то же. max=normal:128

Да, понимаю.
По памяти мы чуть-чуть выйдем за текстовое сжатие при -mrep5+exe+delta+4x4:i0:lzma:8mb:h64m:max

Метод time: cpu time: real Размер архива Memory Memory
for compression for decompression
8m:h64m:max 999 с 256,1 с 1 276 886 566 748mb 212mb

И это еще эффективней.
Только тогда всю линейку надо сдвигать, так как -mex6 использует подобный режим (а точнее, хуже этого).

Про max=normal:128. Насколько я понимаю, normal - это не bt4. Тогда уж max=normal:bt4:128
(Со всем приходится долго разбираться, поскольку четких описаний нет).

SREP 2.93 alpha:

* compression: unrolled internal loop, unrolling factor is defined by -a option
* compression: I/O and md5/sha1 tasks are offloaded to separate thread
* compression: memory-mapped file used for match checking
* compression: now memory usage printed exactly

Compression made 2-3x faster compared to srep 2.0

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

Memory-mapped files usage may be supressed by -nommap option. Please experiment with it and say whether it may improve speed in some situations

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

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]

Цитата:

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

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

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

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

Цитата:

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

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


Цитата:

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

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


Цитата:

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

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

Добавлено:

Цитата:

лог..

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

Цитата:

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

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

Цитата:

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

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

Добавлено:

Цитата:

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

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

Bulat_Ziganshin

Цитата:

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

А это что?