» FreeArc (часть 4)

Цитата:

две версии тянуть мне тоже неохота, этак оно разрастётся...

И это верно

Цитата:

лучше было бы автора запинать

Эм, а сколько уже попытки длятся?

Цитата:

а как ты собрался настраивать -ds чекбоксами?

"Буквы, задаваемые после –ds, расшифровываются как" (из док-ии) И ставить галочки рядом с нужными буквами. А при наводке мышкой на букву, лицезреть всплывающее окошко с подсказкой.

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

Как-то так

Bulat_Ziganshin
немного статистики распаковки

srep32i.exe -m3f xcmd.TAR.pcf xcmd.TAR.pcf.srep

copy xcmd.TAR.pcf.srep nul

srep32i.exe -d xcmd.TAR.pcf.srep nul
Compression ratio: 3482909069 -> 546455948: 15.69%. Cpu 132.210 mb/sec, real 126.166 mb/sec. Matches 0 109025 1771881, memory 0mb 101mb 1096mb

copy xcmd.TAR.pcf.srep nul

srep32i.exe -d -nomd5 xcmd.TAR.pcf.srep nul
Compression ratio: 3482909069 -> 546455948: 15.69%. Cpu 310.454 mb/sec, real 273.881 mb/sec. Matches 0 109025 1771881, memory 0mb 101mb 1096mb

Цитата:

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

только весь смысл этой опции - в порядке этих букв в общем можно сделать там конструктор с переупорядочиванием этих галочек, но пока мне это представляется весьма второстепенной задачей. занёс в трекер: http://code.google.com/p/freearc/issues/detail?id=279

Цитата:

только весь смысл этой опции - в порядке этих букв

Да? О_о Пора мне значит и экспериментировать

А есть ли возможность добавить soundslimmer? Или будут проблемы с авторами? (Хотя не видно, что проект ещё жив, но как на самом деле, мне не известно)

В GUI вроде теперь всё для счастья есть)

Цитата:

почему альфы идут именно с циферкой *.91 ?

а какой им номер давать? если я собираюсь выпустить версию 3.0, то альфы к ней логично нумеровать как 2.9x


Цитата:

Пик памяти в срепе написано 525мб, в диспетчере задач показывает 700мб+ (потом постепенно уменьшается). Это из-за выделения кусочков оперативки кратной размеру страницы памяти в винде или фрагментации памяти?

фрагментации. кроме того, я добавляю по 16 байт на заголовки блоков памяти - может, этого мало. и ещё я не учитываю память, занимаемую дескрипторами matches (ещё байт по 30)


Цитата:

а при упаковке получитьэту информацию можно?

а зачем? распаковка в nul быстрая..

Добавлено:

Цитата:

Пик памяти в срепе написано 525мб, в диспетчере задач показывает 700мб+

кстати, для таких вещей очень удобно использовать procexp от sysinternals. открываешь окно процесса, по его завершению видишь и макс. память, и даже граф её использования:

Цитата:

А есть ли возможность добавить soundslimmer?

его исходников нет

Bulat_Ziganshin

Цитата:

а зачем? распаковка в nul быстрая..

не факт что будет быстрая на нормальном наборе данных, а нормального набора у меня под рукой нет

srep32i.exe -m3f -l128 xcmd.TAR.pcf xcmd.TAR.pcf_128.srep

copy xcmd.TAR.pcf_128.srep nul

srep32i.exe -d xcmd.TAR.pcf_128.srep nul
Compression ratio: 3482909069 -> 240672545: 6.91%. Cpu 96.205 mb/sec, real 90.177 mb/sec. Matches 0 183001 5766988, memory 0mb 68mb 975mb

copy xcmd.TAR.pcf_128.srep nul

srep32i.exe -d -nomd5 xcmd.TAR.pcf_128.srep nul
Compression ratio: 3482909069 -> 240672545: 6.91%. Cpu 164.022 mb/sec, real 150.756 mb/sec. Matches 0 183001 5766988, memory 0mb 68mb 975mb

Добавлено:

Цитата:

кстати, для таких вещей очень удобно использовать procexp от sysinternals.

а так и делаем...
"...жизнь такая"

Добавлено:

Цитата:

а зачем? распаковка в nul быстрая..

кстати столько требуется памяти на распаковку у LostPlanet2.srep?

Цитата:

1) 22 gb file from LostPlanet2 compressed down to 7 gb and require 2 gb of RAM for decompression. For comparison, REP:2gb compressed the same file only to 8.7 gb - i.e. 20%

Добавлено:
тьфу ты 2ГБ, так ведь понимаете что такое 2ГБ для x86 системы?
придётся делать обычную распаковку

Цитата:

не факт что будет быстрая на нормальном наборе данных

future-lz распаковывает очень быстро, так что всё ограничивается скоростью твоих винтов. при распаковке в nul, соответственно - только скоростью чтения сжатого файла. вот на примере того 22-гигового файла:

Код: G:\>srep.exe lp2.pcf.srep u:\lp2.pcf
Compression ratio: 22069494174 -> 7008860732: 31.76%. Cpu 270.601 mb/sec, real 100.478 mb/sec. Matches 0 174390 1449482, memory 0mb 1798mb 13610mb

G:\>srep.exe lp2.pcf.srep nul
Compression ratio: 22069494174 -> 7008860732: 31.76%. Cpu 272.687 mb/sec, real 180.636 mb/sec. Matches 0 174390 1449482, memory 0mb 1798mb 13610mb

А через консольный api?

Bulat_Ziganshin

Цитата:

Цитата: кстати, для таких вещей очень удобно использовать procexp от sysinternals.

а так и делаем...

так через arc.ini и прикрути - ничего не потеряешь

Цитата:

просто как бы найти способ поточнее подсчитывать память, а то может ведь и в 2 раза отличие быть.Цитата:

пока - только с помощью внешних программ, да и -l32 пока не очень жизнеспособен. это всё же самая первая экспериментальная версия, и распаковщик в ней самый простой и прямолинейный - как new/delete отработает, так и выйдет. я могу сделать собственный аллокатор памяти для этого процесса - он будет более предсказуем


Цитата:

только останется выяснить какие файлы на каком участке будут находится)и как их потом отсортировать в требуемом порядке при заTARивании в архив перед сжатием в srep.

1. несложно - обработать precomp'ом файлы по отдельности и получишь все размеры
2. используя gnu tar:

>tar cvf a.tar -Tlist
srep4.cpp
srep2.cpp
srep1.cpp
srep3.cpp

Так я давно прикрутил, а для массового пользователя

egor23

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

Проблема решилась, но если будут еще вопросы - буду рад ответить

gryhov
Лицензию прочти!

srep 2.91 уже сейчас стоит использовать как оптимизированную версию обычного srep. опять же, на этом 22 гб файле:
-m3: RAM 16 mb, 1152 тысячи чтений из выходного файла
-m3f -m4k: RAM 258 mb, 294 тысячи чтений из выходного файла
-m3f -m128k: RAM 950 mb, 8 тысяч чтений из выходного файла

V2driver
Чью лицензию?

Bulat_Ziganshin

Цитата:

несложно - обработать precomp'ом файлы по отдельности и получишь все размеры

я себе представляю немного другую ситуацию - есть пару сотен (а может и тысяч) файлов в десятках папок, все без сжатия засунуты в любой из архиваторов, затем с помощью srep проводится поиск совпадений. Как тут отсортировать?) arc.exe v data.arc показывает именно ту последовательность, в которой на самом деле и упакованы файлы в arc-архив, или же сортируются перед отображением? Если первый вариант, то возможно как-то найти нужные последовательности, хоть и геморно. Может удастся и автоматизировать подобный процесс сортировки с учетом данных от срепа..

Цитата:

да и -l32 пока не очень жизнеспособен

но бывает иногда стреляет и очень прилично)

экспресс тест (каждая операция проходила после перезагрузки Win7, дабы избежать излишнего кеширования от предыдущего прохода):
data.arc = 3 909 512 074 байт
data1.srep, data2.srep ~ 2 603 705 000 байт

упаковка:
srep -m3 -l32 data.arc data1.srep - 505.37 сек
srep -m3 -l32 -f data.arc data2.srep - 511.08 сек

распаковка
srep -d data1.srep - 95.68 сек
srep -d data2.srep - 97.20 сек

З.Ы. кеширование рулит?

Пик использования памяти при распаковке второго архива в srep 525mb, в диспетчере Peak Private Bytes ~ 650mb

Бесспорно в 2.91 версии распаковка на много эффективнее...но я это могу увидеть только на очень большом объеме данных (типа твоего примера с LostPlanet2), или вынув пару планок оперативки, либо откатившить на WinXP..

Aroyl

Цитата:

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

теперь буду знать еще одну рекомендацию, если у человека не распаковываются архивы)

juvaforza
Sound Genetics Inc.

возможны различные сценарии использования SREP и тут меня интересуют ваши мнения, ваши запросы

на мой взгляд, самый сильный сценарий выглядит так: сжатие напрямую в arc с цепочкой алгоритмов precomp+srep+...+lzma. при этом если srep и precomp будут работать как фильтры при распаковке, то при инсталяции диск не будет загромождаться временными файлами, и скорость инсталяции будет очень высока, порядка 50 мб/с, так что за 5-10 минут можно будет установить любую современную игрушку, даже размером в 10-20 гб

размер используемой памяти можно ограничить таким алгоритмом: скажем пользователь при распаковке разрешает использование 500 мб ОЗУ. когда занятая программой память подходит к этому пределу, программа находит 8 мб "самых будущих" матчей и скидывает их содержимое во временный файл, запоминая где они начинаются. когда распаковка подойдёт к этому моменту, данные считываются из врем. файла одним куском. при этом, если для них нет свободной памяти, то точно так же во временный файл записываются "самые будущие" матчи из нынешнего словаря.

поскольку из всех находящихся в данный момент в памяти данных позже всего нам потребуются именно "самые будущие" матчи, то это де-факто такой интеллектуальный алгоритм своппинга, которые выкидывает в своп-файл именно те данные, которые нам не потребуются дольше всего. при этом чтение/запись этих данных производится кусками по 8 мб, т.е. никаких проблем с seek times и нагрузкой на кеш диска как у обычного srep и обычного своп-файла

оценить эффективность такого подхода можно на примере того же lp2.pcf - в нём на 22 гб данных приходятся 13 гб матчей. если ограничить потребление памяти при распаковке 200 мб, то во временный файл придётся записать (и затем прочитать) 5-10 гб данных, что при скорости диска в 100 мб/с потребует 100-200 сек. учитывая, что процесс распаковки наверняка будет CPU bound, а не I/O bound (т.е. ограничиваться скоростью CPU), этот обмен с диском будет бесплатным (т.е. не увеличит общее реальное время работы), если остальные процессы в цепочке (lzma, precomp) будут работать параллельно с srep

Добавлено:
забыл добавить - размер временного файла на диске при этом будет ограничен теми же 2 гб, просто некоторые 8мб блоки в нём будут несколько раз перезаписываться в ходе работы

Bulat_Ziganshin
Еще один вариант:
1508 Queue operations across multiple FreeArc copies=Если в процессе выполнения операции (упаковки, распаковки...) FreeArc определит, что выполняется еще одна копия FreeArc, то операция будет поставлена в очередь, и будет выполнена после завершения всех предыдущих операций в очереди. Это позволит каждой операции полностью использовать все ресурсы компьютера.

Bulat_Ziganshin

Цитата:

при этом если srep и precomp будут работать как фильтры при распаковке, то при инсталяции диск не будет загромождаться временными файлами, и скорость инсталяции будет очень высока, порядка 50 мб/с, так что за 5-10 минут можно будет установить любую современную игрушку, даже размером в 10-20 гб

Идея отличная, но Вам же её и реализовать.

Лично мне в репаках игр использование srep-а не нравится именно тем, что на диск пишется ОГРОМНЫЙ файл, а потом уже он распаковывается сабжем.

Как конечному потребителю мне это кажется извращением. Я уж лучше еще за 10 минут ещё 1 гиг качну, чем ждать 40 минут всю эту канитель с усиленным дрыганьем винта и прочим бредом по распаковке со srep-ом, в текущем его состроянии.

В сферическом вакууме (если не учитывать время, дополнительное место на винчестере) srep - очень хорошая вещь.

i'm ready to switch to nginx server. before i will bind it to port 80, please test it at http://freearc.org:8008/ - is it compatible with your browser, download manager etc. ancient browsers (i.e. IE6-) are especially interesting

Bulat_Ziganshin

Цитата:

по умолчанию
-m1mb
-m128k
-m4k

??
делали так?

srep32i.exe -nomd5 -d -m4k file.srep nul

а то сходу не сообразил.

Bulat_Ziganshin
Не могу на вашем сайте найти информацию о дате выхода последней альфа версии. Нельзя ли ее добавить на страничку загрузки альфа версией (http://freearc.org:8008/Download-Alpha.aspx) ?

Цитата:

srep32i.exe -nomd5 -d -m4k file.srep nul

ага

Добавлено:

Цитата:

Лично мне в репаках игр использование srep-а не нравится именно тем, что на диск пишется ОГРОМНЫЙ файл, а потом уже он распаковывается сабжем.

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

1) precomp+srep+lzma: тогда на первом проходе мы распаковываем lzma->srep->файл, затем обрабатываем файл precomp'ом. замена srep на rep здесь ничего не изменит

2) srep+lzma: тогда после распаковки lzma->srep мы сразу можем писать выходные файлы, но для работы srep нужен временный файл. т.е. места во время инсталяции нужно больше, но скорость не теряется

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

Добавлено:
SREP 2.92 alpha:

* 1.5x faster compression, on average (especially notable on multi-gigabyte files)

my own tests:
srep32i: 10.468 mb/sec -> 17.587 mb/sec
srep64i: 17.645 mb/sec -> 29.943 mb/sec

This version improves CPU times. In the next version i will try memory-mapped files to significantly improve I/O speeds, too

Windows 7 Pro en x64 sp2
Google Chrome 15.0.874.121 m
Firefox 8.0
Opera 11.52
Вроде всё нормально.
http://freearc.org:8008/Donations.aspx - тут вроде и без Nginx не работает. Всмысле MoneyBookers Donate.

Это типа реверс прокси для IIS ?

Profrager

Цитата:

Бесспорно в 2.91 версии распаковка на много эффективнее...но я это могу увидеть только на очень большом объеме данных (типа твоего примера с LostPlanet2), или вынув пару планок оперативки, либо откатившить на WinXP..

или просто заняв память, например сделав ram-drive, несколько секунд и "лишняяя память" занята

это быстрый www-сервер и реверс-прокси. насчёт букерсов - спасибо


Цитата:

Не могу на вашем сайте найти информацию о дате выхода последней альфа версии. Нельзя ли ее добавить на страничку загрузки альфа версией (http://freearc.org:8008/Download-Alpha.aspx) ?

попробую сделать

Bulat_Ziganshin

Цитата:

размер используемой памяти можно ограничить таким алгоритмом: скажем пользователь при распаковке разрешает использование 500 мб ОЗУ. когда занятая программой память подходит к этому пределу, программа находит 8 мб "самых будущих" матчей и скидывает их содержимое во временный файл, запоминая где они начинаются. когда распаковка подойдёт к этому моменту, данные считываются из врем. файла одним куском. при этом, если для них нет свободной памяти, то точно так же во временный файл записываются "самые будущие" матчи из нынешнего словаря.

будет ждать

кстати нельзя ли улучшить второй проход в -f, чтобы данные по последовательней считывались из исходного файла?