» FreeArc (часть 4)

Здраствуйте подскажити как зделать-распаковку FreArc затем PreComp затем Srep затем 7zip архивов и что бы распакованные архивы удалялись с игровой папки ВОТ Скрипт http://rghost.ru/35622051

SREP 2.94 alpha:

* compression made about 20% faster
* -a4 now is the default, memory usage is the same as with -a8 in 2.93
* "-nommap" is printed when this option is active


Добавлено:

Цитата:

объясните плиз поэтапно как это сделать?

нет, спасибо. может кто другой тебе поможет

egor23
1. улучшения в -m3 пока не удалось реализовать. по большому счёту, если тебе не хватает памяти для кеширования всех необходимых частей файла, то остаётся только стиснуть зубы и ждать либо использовать -m1. собственно, улучшения в -m3 лишь приблизят ситуацию к -m2, так что если у тебя и он тормозит...

2. в моих тестах оптимальные результаты (в 2.94) даёт либо -a4, либо -a8, -a16 почему-то уже медленней - разумеется если хватает памяти. если начинается трешинг, то a1/a2 может быть оптимальным поскольку оставляет больше памяти для кеширования

3. потетстируй с -m1/2/3, с и без -nommap. особенно меня интересует окончательная разница в сжатии (после lzma) результатов -m1 vs -m3

MAKLAI1994

тебе сюда --> http://forum.ru-board.com/topic.cgi?forum=5&topic=36421&start=3020#lt

Bulat_Ziganshin

Цитата:

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

Булат, нужны отображения иконок в файл-менеджере и атрибуты файлов.
перечисляю 50$ - так ?

Парни ещё вопрос что нужно зделать в скрипте что бы Сначала Распаковывались файлы bin. а из них уже RAR-SREP-Arc и т.д мне главное что бы все архивы были в файлах bin вот скрипт попробуйте похимичить
http://rghost.ru/35642435

о влиянии mmap. первый тест, на небольшом файле (т.е. целиком влезающем в кеш):

410 mb, -m1 -l512 -c512 -a4. Cpu 57.892 mb/sec, real 57.397 mb/sec
410 mb, -m1 -l512 -c512 -a4 -nommap. Cpu 57.780 mb/sec, real 57.208 mb/sec
202 mb, -m2 -l512 -c512 -a4. Cpu 59.331 mb/sec, real 58.857 mb/sec
202 mb, -m2 -l512 -c512 -a4 -nommap. Cpu 58.222 mb/sec, real 56.708 mb/sec
372 mb, -m3 -l512 -c256 -a4. Cpu 49.165 mb/sec, real 48.620 mb/sec
372 mb, -m3 -l512 -c256 -a4 -nommap. Cpu 46.588 mb/sec, real 40.100 mb/sec

в -m1 mmap не используется, потому и результаты неизменны. -m2 выигрывает от него несколько процентов, -m3, производящий 13 миллионов сравнений матчей (по сравнению с 500 тыщами в -m2) получает от mmap значительный выигрыш

Добавлено:

Цитата:

Булат, нужны отображения иконок в файл-менеджере и атрибуты файлов.
перечисляю 50$ - так ?

я бы сам перечислил первое сделать очень сложно. второе - что именно отображать?

Быстрое сжатие больших объемов

«Философия»
Подход к линейке методов сжатия для архиваторов консервативен. Для FreeArca – это методы –m1, -m2, … , -m9 (-mex9). Хочешь быстро – используй –m1, хочешь сильно сжать – используй –m9 (-mex9). Но такая линейка «одномерна» и не очень хороша, поскольку учитывает размер файлов однобоко. Например, нет оптимального метода для «быстрого» сжатия большого объема. Конечно, можно воспользоваться –m1 (-m2), но результат будет далек от идеала. Причина – обработка больших массивов данных заложена только в «старших» (медленных) методах (большой rep). Я вижу выход в «двухмерном» подходе.

От слов к делу
Например, для быстрого сжатия больших объемов можно взять большой rep (от m8, mex8) и быстрый алгоритм (подобный –m2). Под «большими объемами» в таком случае будут пониматься данные размером примерно 1GB (и выше).
Я долго тестировал варианты и предлагаю два «оптимальных». Эти методы по «двухмерной» идеологии я назвал –m81 и –m82. Здесь 8 означает большой объем сжимаемых данных (8rep = rep:1gb), а цифры 1 и 2 – «скоростной» и «быстрый» метод. Деление файлов на группы отсутствует.

Вот результаты сравнения с методами –m2 и –mex8, отсортировано по увеличению реального времени работы:

Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-разрядная, ОЗУ 4 ГБ
Консольная версия FreeArc 0.67 от 25 декабря 2011
Метод time: cpu time: real Размер архива Memory for compression Memory for decompression

Цитата:

Q: Возможно ли в arc реализовать запуск файла из архива после распаковки этого архива?

A: freearc-installer.sfx извлекает архив во временный каталог, запускает setup.exe и после его выполнения стирает все временные файлы. freearc-installer-nodelete.sfx делает то же самое кроме стирания

откуда взять эти модули freearc-installer.sfx и freearc-installer-nodelete.sfx
где их скачать или где они лежат?

1. было бы хорошо видеть запакованный размер файла, атрибуты, скрытый, системный и т.д.
2. было бы хорошо видеть тип файла - как в WinRar.
3. очень удобная штука в 7zip - show grid lines.
4. выделение файлов мышью в файл менеджере архиватора
5. мега фича WinRar - просмотрщик фалов.
6. в адресной строке видеть размер - правда незнаю лучше чего, архива или размер распакованного.
7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.

Shuld
тут есть тег "таблица" (после x2) - может переоформишь с ним?

Цитата:

откуда взять эти модули freearc-installer.sfx и freearc-installer-nodelete.sfx
где их скачать или где они лежат?

лежат в том же каталоге, что и arc.exe

Булат
1. Переоформил
2. Почему при Memory for compression более 1444mb из-под консоли методы сжатия работают без темп-файла, а под оболочкой (GUI) - с темп-файлом (во всяком случае время становится примерно в 2 раза больше)?

Bulat_Ziganshin
прошу извинить меня, С++ для меня как инжекторный двигатель... при более тщательном просмотре все же нашел, то что хотел узнать
" -d: decompression (requires only 16 mb of memory besides of OS I/O buffers)\n"

Цитата:

ссылку на сайте поправил

да, я говорил об этой ссылке, спасибо


andhunt

Цитата:

объясните плиз поэтапно как это сделать?

при Упаковке своих файлов в FreeArc GUI на вкладке "Основное" отмечаешь галочку напротив "Сделать ЕХЕ",
и вместо "Графический для Windows: freearc.sfx" прописываешь, например, freearc-installer.sfx

Если сжимаешь первый раз, то время 140 с. При повторных сжатиях – около 25 с.

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

Цитата:

7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.

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

Что это значит?
Это же не ОЗУ, в чем разница?
(Все ОЗУ 2 ГБ, причем архиватор использует почти 1,5 ГБ)

SerJantX

Цитата:

и кнопка тест тоже не соответствует

я смотрю у всех Test однотипный - книжки, буквы - тест проходим.
вроде нормально.

Shuld

Цитата:

В методе –m1 по времени стоят вопросы из-за совсем странного (для меня) поведения. Если сжимаешь первый раз, то время 140 с. При повторных сжатиях – около 25 с.

Цитата:

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

используйте ram-drive, тогда не будет узкого места ввиде диска, для быстрых методов
и будет минимизировано разница между первым и последующим тестами на одном наборе данных.

а можно сделать следующее в FreeArc.

в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:
1. setup.exe
2. primer.exe
3. primer.txt

я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

Цитата:

arc l "E:\MS Office 2003.arc"
Цитата:
71 files, 96,929,246 bytes, 0 compressed
All OK

arc l "E:\MS Office 2003.7z
Цитата:
155 files, 419,766,875 bytes, 405,828,536 compressed
All OK

arc l "E:\MS_Office_2003.arc
Цитата:
155 files, 419,766,875 bytes, 377,402,843 compressed
All OK


похоже что проблема в имени архива ARC с пробелами, или это всём давно известно ?

Цитата:

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

а нафига ты мне прислал архив 7z, если проблема в архиве arc? да ещё и упакованный в ppmd

проблем в листинге архивов с пробелом в имени нет:

D:\Downloads\!!!>arc l "a b.arc" |tail
2003-10-13 00:36:32 38,479 SevaSoftware\Locana\doc\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:54 38,479 SevaSoftware\Locana\doc\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 38,479 SevaSoftware\Locana\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 6,547 SevaSoftware\Locana\tst\images\flower1.jpg
2003-10-18 11:31:56 6,950 SevaSoftware\Locana\tst\images\flower2.jpg
2003-10-18 11:31:56 8,165 SevaSoftware\Locana\tst\images\flower3.jpg
2003-10-18 11:31:56 6,896 SevaSoftware\Locana\tst\images\flower4.jpg
2003-08-11 23:19:16 764,836 ProgrammingRuby.chm
----------------------------------------
7,498 files, 62,861,163 bytes, 9,174,197 compressed

C:\!\FreeArchiver\Tests>arc l ruby.arc |tail
2003-10-13 00:36:32 38,479 SevaSoftware\Locana\doc\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:54 38,479 SevaSoftware\Locana\doc\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 38,479 SevaSoftware\Locana\screen_shots\img_locana_tk_event_monitor.jpg
2003-10-18 11:31:56 6,547 SevaSoftware\Locana\tst\images\flower1.jpg
2003-10-18 11:31:56 6,950 SevaSoftware\Locana\tst\images\flower2.jpg
2003-10-18 11:31:56 8,165 SevaSoftware\Locana\tst\images\flower3.jpg
2003-10-18 11:31:56 6,896 SevaSoftware\Locana\tst\images\flower4.jpg
2003-08-11 23:19:16 764,836 ProgrammingRuby.chm
----------------------------------------
7,498 files, 62,861,163 bytes, 9,174,197 compressed

Добавлено:
отбой. сархиваировал твои файлы в arc - те же чудеса. буду разибраться

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

D:\Downloads\!!!>Arc.exe lt ms
FreeArc 0.67 (February 2 2011) listing archive: ms.arc

Archive type: Cab
Total bytes: 96,929,246
Compressed bytes: 0
Ratio: 0.0%

Directory blocks: 0
Directory, bytes: 0
Directory, compressed: 0
Solid blocks: 0
Avg. blocksize: 92 mb

Compression memory: 0 b
Decompression memory: 0 b
Dictionary: -

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
71 files, 96,929,246 bytes, 0 compressed

Прочитал про ram-drive.
Во времена компьютера "Поиск" (ХТ) у меня был "электронный диск". Это оно и есть?

Но тогда такие эксперименты полностью "игнорируют" поведение реальных жестких дисков. Это хорошо для абстрактной скорости, но трудно соотнести с быстродействием "реального" компьютера (он неидеален, есть задержки времени на выполнение различных операций, таких как обращение к винту).
А у меня цель - получить оптимальное соотношение время / степень сжатия для реального компьютера.
Я не ставлю цели "максимальное быстродействие".

Вот, например, я вижу, что данные по затратам чисто процессорного времени имеют о-очень отдаленную связь с реальным временем. Поэтому я в будущем буду похоже процессорное время игнорировать.

Цитата:

разобрался. ты напоролся на известную багу в arc - если в архиве arc можно найти несжатый архив другого формата, то он откроет именно внутренний архив:

а что значит несжатый ?
т.е. если я упакую cab - то потом данные свои распоковать не смогу ?

Добавлено:
хм, а как же создание архива ARC без пробелов в имени и успешном листинге ?

Цитата:

arc l "E:\MS_Office_2003.arc
Цитата:
155 files, 419,766,875 bytes, 377,402,843 compressed
All OK

Shuld

Цитата:

Но тогда такие эксперименты полностью "игнорируют" поведение реальных жестких дисков. Это хорошо для абстрактной скорости, но трудно соотнести с быстродействием "реального" компьютера

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

PS: Реальные условия это не только HDD \ SSD, но и объём RAM, + объём исходных данных, т.е. под всё не подстроиться, главное в тестах чтобы условия проведения были обинаковые: скорость диска, загруженность CPU, свободное кол-во RAM. Результаты на разных типах дисках (HDD \ SDD \ RAM-drive) важны например для алгоритма srep, особенно в метода m2, m3.

Bulat_Ziganshin, мог бы дать ответ или может кто-то из мемборов сможет мне помочь, если необходимо готов заплатить.


можно сделать следующее в FreeArc.

в архиваторе есть модуль freearc-installer.sfx, который запускает setup.exe , но если в архиве были еще файлы то он их не распаковывает в текущую папку.
нужно чтобы работало следующим образом, у меня есть к примеру три файла:
1. setup.exe
2. primer.exe
3. primer.txt

я их архивирую через модуль freearc-installer.sfx , а когда уже распаковываю эти файлы setup.exe должен запуститься сам автоматически и удалиться, а оставшиеся файлы primer.exe и primer.txt должны распаковаться в текущую папку как обычно?(т.е. setup.exe после запуска удаляется , а primer.exe и primer.txt должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?

после архивации ( вызов из контекстного меню - архивация с диалооговым окном), если в диалоге добавить галку на тестирование после архивации, то после архивации окно просто висит. По отдельности операции отрабатываются нормально.

Aroyl

Цитата:

Разархивировал .arc, попробовал напрямую srep -d, то же самое - ошибка, прекращение распаковки.

Цитата:

Вопрос с установкой решился. Вроде бы помогло увеличение объема файла подкачки (Win7x86, родные 4Гб, своп поставил "рекомендовано системой").

Цитата:

Ещё возможная проблема (подсмотрел на сайте где брал) - кеширование антивирусом распаковываемого файла

может проблема всё таки в памяти? проверьте её, а то очень сомнительно, что антивирус косячит, кэширует то он скорее всего на HDD.

Цитата:

главное в тестах чтобы условия проведения были обинаковые: скорость диска, загруженность CPU, свободное кол-во RAM

в этот список нужно обязательно добавить пункт "содержимое системного кэша".

Вообще, чтобы условия при каждом запуске были сколь-нибудь равноценные, надо выполнять перезагрузку перед каждым запуском архиватора.


Цитата:

такие эксперименты полностью "игнорируют" поведение реальных жестких дисков.

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

Bulat_Ziganshin
В самом деле, как в FA организован ввод-вывод? Он читает очередной байт (блок) как только он понадобится, и записывает очередной байт в архив как только он будет готов?

Benchmark measuring effect of -nommap option on system with 8Gb RAM:

First test, 5.5 gb file compressed down to 4.4 gb:
Cpu 57.299 mb/sec, real 56.471 mb/sec -m1
Cpu 57.263 mb/sec, real 56.599 mb/sec -m1 -nommap
Cpu 58.545 mb/sec, real 57.968 mb/sec -m2
Cpu 57.594 mb/sec, real 56.189 mb/sec -m2 -nommap
Cpu 48.428 mb/sec, real 48.010 mb/sec -m3
Cpu 46.168 mb/sec, real 39.404 mb/sec -m3 -nommap

As you see, memory-mapped files (i.e. lack of -nommap option) has no effect on -m1 (in fact, MMF not used at all in -m1), there is a small improvement of 3-4% in -m2, and 20% in -m3

MMF files are used to retrieve matches to compare, that explains the result: -m1 doesn't do it at all (it verifies matches by SHA1 hash). -m2 retrives only small amount of real matches (500 thousands here), and -m3 retrives huge amount of match candidates (13 millions for this file) that is much faster with direct memory access instead of read call


Second test, 22gb file compressed down to 7gb:
Cpu 76.367 mb/sec, real 73.785 mb/sec -m1
Cpu 91.401 mb/sec, real 52.799 mb/sec -m2
Cpu 91.136 mb/sec, real 56.497 mb/sec -m2 -nommap
Cpu 72.282 mb/sec, real 36.478 mb/sec -m3
Cpu 68.879 mb/sec, real 35.693 mb/sec -m3 -nommap

Here we see about 10% speed improved in -m2 without MMF. srep is memory-hungry here, and may be it is the effect of larger OS memreqs to support MMF operation. but actually i don't know the reason, only had to say that i've tested several times and results were the same


Third test, the same 22gb file placed to Intel SSD 120 gb disk, that is 2x faster on linear reads, and has 100x smaller access time:
Cpu 77.116 mb/sec, real 75.453 mb/sec -m1
Cpu 92.865 mb/sec, real 56.718 mb/sec -m2
Cpu 90.861 mb/sec, real 73.738 mb/sec -m2 -nommap
Cpu 73.316 mb/sec, real 45.534 mb/sec -m3
Cpu 68.548 mb/sec, real 45.869 mb/sec -m3 -nommap

Here, memory-mapped files degrade -m2 performance even more

Bulat_Ziganshin

Цитата:

Here, memory-mapped files degrade -m2 performance even more

а обратили внимание на счётчик, например в Диспетчере задач, Mem Use, что со временем памяти показывается вся доступная.
На что это оказывает влияние это уже другой вопрос, на который я не могу ответить.

Добавлено:
Aroyl

Цитата:

Вот ссылка на репак: Dragon Age Origins - Diamond Edition
Нужен только первый образ - DAODE_RusEng_RePack_DVD1.iso
Файл с которым я мучался называется Daodata1.arc, лежит в каталоге Data.
Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб), каждый из которых содержит внутри множество файлов. Я распаковывал последовательно и проблема была практически на ка

У меня проблем с распаковкой Daodata1.arc и daomain.dat не возникло.

Цитата:

Внутри него daomain.dat - обработаный srep'ом архив, содержащий 2 файла - daotemp1.arc (19Гб) и daotemp2.arc(5Гб)

про это не понял после daomain.dat получаю daomain.arc 18.5ГБ (без сжатия) внутри которого два архива arc без сжатия, точно уже непомню примерно 5ГБ и 13.5ГБ.
зачем было так делать мне непонятно.

Немного тестов на распаковку с -mXXX

srep294.exe -m1f daomain.arc daomain.arc.srep294_m1f

srep294.exe -d daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 129.241 mb/sec, real 48.617 mb/sec. Matches 0 371681 4110533, I/Os 0, MiBs 0 1415 6140

srep294.exe -d -nomd5 -m128k daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 357.891 mb/sec, real 50.095 mb/sec. Matches 0 371681 4110533, I/Os 3998, MiBs 0 436 2967

srep294.exe -d -nomd5 -m512k daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 311.145 mb/sec, real 46.650 mb/sec. Matches 0 371681 4110533, I/Os 1436, MiBs 0 475 3627

srep294.exe -d -nomd5 -m2m daomain.arc.srep294_m1f nul
Compression ratio: 19913271662 -> 12259186550: 61.56%. Cpu 302.217 mb/sec, real 46.532 mb/sec. Matches 0 371681 4110533, I/Os 414, MiBs 0 781 4659

Bulat_Ziganshin
Что за глюк? при активации опции -lc- ФА выбивает user error
win 7 sp1 64bit, 4Gb, макс свободный блок адресного пространства 2042Mb
аналогично и на win XP sp3 32bit, 3.25Gb, макс свободный блок адресного пространства 1400Mb