» FreeArc (часть 4)

Neo7898 лично у меня нету, так как не нужен был. Фотки сдимаю стаффитом.
Но как бы проблемы не вижу, прочтения доки хватило что бы понять как это работает.
И я же говорю - 10 чатлов и всё у Вас будет=)
Гуи или консольный?

Цитата:

Это типа болида спортивного - постоянно что-то совершенствуется - чтобы быть на острие атаки.

Вот я примерно о том и сказал - быть на острие атаки, но не ездить. Тот же Шумахер (и все прочие из Формулы) на болидах только на Формуле и тренировках...
P.S. Кстати, уже не первый год в Формуле искуственные ограничения - на мощность, объём.

V2driver
Гуи
читал, пробовал - но я что-то сильно туплю... у меня не выходит...
и тут еще такая проблема, чтобы это работало в режиме сжатия max, а не только в m9j, который у меня заработал на XP и не получился на семёрке...

4x4:mm+lzma
будет работать многопоточно?

V2driver
StuffIt к сожалению не умеет делать SFX более 2Gb.

Edison007007
mm очень быстрый, так что нет смысла его ставить под 4x4. а в целом ты видимо неправильно интерпретируешь - это означает (4x4:mm)+lzma. т.е. 4x4 - это префикс одного-единственного метода сжатия, а не всей оставшейся цепочки

Neo7898

Цитата:

и тут еще такая проблема, чтобы это работало в режиме сжатия max, а не только в m9j, который у меня заработал на XP и не получился на семёрке...

Нифига не понял, чего Вы хотите?

muzf
Вернулся?
Покажи свой вариант билда

Цитата:

это означает (4x4:mm)+lzma.

Точно ведь *facepalm*. Но если использовать mm+lzma, то каждый файл будет сжат в отдельный блок, а что если сделать многопоточную упаковку/распаковку, т.е. распаковывать/упаковывать несколько блоков одновременно?
* и с tta такой трюк бы прокатил

я хочу сделать например такое:
-maxj - и эта команда сжимает всё файлы в режиме -max и плюс жмёт фотки.

Tornado 0.6 - добавлен оптимальный LZ-парсинг

Сжатие:новые режимы -11..-16 используют оптимальный парсер (-p4)
-fb (FAST BYTES), новый параметр используемый только оптимальным парсером
старый режим -10 удалён, старый -11 я настроил получше и переименовал в -10
опция -s1 теперь означает "64kb hash3 + 4kb hash2", что автоматически немного улучшило сжатие в режимах -5/-6
новые алгоритмы LZ-поиска: chash5..7 (-x15..17) и bt4..7 (-x24..27)
все алгоритмы поиска chash/cchash/bt теперь поддерживают значения -l, не являющиеся степенью 2
все параметры сжатия описаны в manual.txt
Командная строка и индикатор прогресса:опции -slp/-rem, по умолчанию используются большие страницы памяти (2МБ/4МБ)
индикатор прогресса в таскбаре Win7 (зелёная полоска) плюс текст в заголовке консольного окна
программа возвращает уод ошибки 2 при любых проблемах, очищает заголовок окна при ^Break
экран помощи описывает диапазон значение и значение по умолчанию для каждого параметра сжатия
проверка корректности значений параметров сжатия
под Windows, предотвращает одновременную запись нескольких процессов в один и тот же файл
печатает размеры с точностью до байта; скорости измеряются в МиБ/с
индикатор прогресса стал более точен и обновляется не чаще раза в 0.2 секунды
Компиляция:под Windows, compile.cmd поддерживает множество версий GCC/MSVC/ICL
под Linux, compile.sh теперь создаёт исполняемый файл, способный обрабатывать файлы размером больше 2 ГБ

---

Tornado 0.6 - added the optimal parsing

Compression:new -11..-16 predefined modes employing the optimal parser (-p4)
-fb (FAST BYTES), new parameter used only by the optimal parser
old -10 mode was removed, old -11 mode was better tuned and renamed to -10
-s1 option meaning changed to "64kb hash3 + 4kb hash2", slightly improving compression in -5/-6 modes
new chash5..7 (-x15..17) and bt4..7 (-x24..27) match finders
all chash/cchash/bt matchfinders support -l values that is not power of 2
new manual.txt explaining all compression parameters

Command line and progress indicator:-slp/-rem options, large pages are allocated by default
Win7 taskbar progress indication (green bar) plus info in the console window title
returns Errcode 2 on any error, clears the window title on ^Break
prints ranges and default values for each option, checks option correctness
on Windows, prohibits simultaneous writing by several compression processes to the same output file
prints byte-exact filesizes; speeds are measured in MiB/s
progress indicator is more accurate and updated only once per 0.2 seconds
Compilation:on Windows, compile.cmd supports many GCC/MSVC/ICL versions
on Linux, compile.sh now produces executables that can process files larger than 2 GB

Neo7898
Видимо эта mission impossible.

Paramon111 10 чатлов.

Цитата:

а что если сделать многопоточную упаковку/распаковку, т.е. распаковывать/упаковывать несколько блоков одновременно?
* и с tta такой трюк бы прокатил

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

V2driver
Оставь себе, я мультимедийные файлы не жму, у меня их пару гигов на компе максимум.

Когда-же таки будет 0.70 ?
Второго пришествия Христа легче дождаться!

WildGoblin

Цитата:

Это типа болида спортивного - постоянно что-то совершенствуется - чтобы быть на острие атаки.

даже спортивный болид, несмотря на постоянное совершенствование в "конюшнях"
на соревнования допускается в вполне себе финал/ритейл варианте
а тут даже альфы под одним номером, что должен думать потенциальный потребитель ?
Правильно, да ну эти эксперименты с моими данными куда подальше - и будет абсолютно прав !

Цитата:

Когда-же таки будет 0.70 ?
Второго пришествия Христа легче дождаться!

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

Новая альфа:-m5 на бинарных данных теперь работает значительно быстрее за счёт использования всех ядер CPU
-m2..-m4: сжатие на бинарных данных значительно улучшено (исправлена ошибка, появившаяся в версии от 22.08.2012)
-m1..-m5 и все -mex мгновенно обрабатывают уже сжатые данные (см. изменения в 4x4 ниже)
поддерживается выделение памяти Большими Страницами (4МБ), что увеличивает скорость на 10% (но к сожалению, БС обычно доступны только сразу после перезагрузки ОС)LZMA:HT4 теперь поддерживает словари размером до 2 ГБ
увеличена степень сжатия со словарём в 1 ГБ
предвыборка памяти и мульти-сканирование в BT4/HT4 -> увеличение скорости до 20%
для HT4 параметр MaxChain (:mc) по умолчанию теперь равен FastBytes/2 (:fb/2)Tornado:
новые методы сжатия с оптимальным парсингом tor:11..tor:16 и параметры :x :s :fb
поддержка значений :l, не являющихся степенью 2, в режимах tor:5..tor:16
см. сообщение о выходе Tornado 0.6 для доп. информации о новых возможностях4x4:быстрая обработка уже сжатых данных - они просто копируются в выходной файл со скоростью 1 ГБ/с
для этого каждый блок данных сначала проверяется на order-0 сжатие и если его коэффициент >99% - данные передаются без упаковки
настройка: параметр :r0 означает "не проверять и всегда пытаться сжать данные", :r99.5 означает "пропускать упаковку если коэффициент order-0 сжатия >99.5%"

---

New alpha version:-m5 binary compression made much faster by employing all CPU cores
-m2..-m4 binary compression ratio is significatly improved (fixed bug made in the Aug22/2012 version)
-m1..-m5 and -mex modes process incompressible data at 1 GB/sec speed (see 4x4 updates below)
Large Memory Pages (4MB) allocated if possible, improving speed by 10% (unfortunately, LP are usually available only immediately after OS restart)LZMA:HT4 now supports dictionaries up to 2 GB
improved compression ratio for 1 GB dictionary
prefetching and multi-scanning in BT4/HT4 matchfinders - up to 20% faster
default MaxChain (:mc) for HT4 now is FastBytes/2 (:fb/2)Tornado:new tor:11..tor:16 optimal compression modes and :x :s :fb parameters
support for :l values that is not power of 2 in the tor:5..tor:16 modes
see Tornado 0.6 release notes for details4x4:already compressed data now are quickly copied at the 1GB/s speed, because compression of the next block is automatically skipped if order-0 compression ratio of the block is >99%
tunable with :r parameter: :r0 means "always try to compress", :r99.5 means "compress if order-0 ratio is >99.5%"

SREP 3.1 (23 февраля 2013 г.)-m1f -a4 теперь режим сжатия по умолчанию, он обеспечивает быстрое сжатие. Используйте опции -m3f -a1 для максимального сжатия
32-битная версия работает в 1.5 раза быстрее, чем в SREP 3.0
gcc64 версия: srep64g.exe. srep32i/srep64i - по прежнему самые быстрые компиляции
багфикс: было невозможно выделить больше 4 гигабайт для bitarr[]
багфикс: 32-битная версия по умолчанию теперь использует только 1.5 гб для распаковки future-lz (раньше было 4гб-1, что слишком много)
Изменения в выводе статистики:время CPU теперь обозначает *СУММАРНОЕ* время, затраченное всеми тредами программы
выводится время CPU и реальное время работы, плюс для обоих - скорость в МиБ/с
при распаковке future-lz статистика по I/O и VM выводится только когда они реально задействованы
опция -pc выводит внутренние счётчики производительности (performance counters)
В отличии от 32-битного SREP 3.01, использовавшего один 32-битный хэш, что давало выигрыш в скорости в большинстве случаев, но замедляло обработку огромных файлов (десятки гигабайт) и работу в режиме -m3, теперь 32-битная версия использует два 32-битных хэша, делая её работу в любой ситуации более быстрой, чем версия 3.0. 64-битная версия по прежнему использует один 64-битный хеш, что делает её около 1.5 раз быстрее 32-битной версии




SREP 3.1 (February 23, 2013)-m1f -a4 now is default compression mode, for quick and dirty compression. Use -m3f -a1 for maximum compression
32-bit version became 1.5x faster than in SREP 3.0
gcc64 version: srep64g.exe. srep32i/srep64i still are the fastest executables
bugfix: it was impossible to allocate more than 4 gb for bitarr[]
bugfix: 32-bit version now uses only 1.5 gb for future-lz decompression by default (instead of 4gb-1 that's too much)
Changes in the printed stats:cpu time displayed now is the sum of times spent in *ALL* threads
cpu/global times and speeds are printed, with speeds measured in MiB/s
on future-lz decompression, I/O and VM stats are printed only when they are non-zero
-pc option displays performance counters
Unlike 32-bit SREP 3.01 that used one 32-bit hash resulting in degraded speed on huge files and in -m3 mode, now 32-bit version uses two 32-bit hashes, making compression both fast and accurate. 64-bit version still employs single 64-bit hash, making it up to 1.5x faster than 32-bit code.

Как новая альфа? Чего интересного?

Bulat_Ziganshin
Может все таки стоит научить SREP работать с папками?

egor23
опцию -slp пока не реализовал, поскольку надо её передавать в 7z.dll и facompress.dll. по большому счёту она интересна только бенчмаркерам. а описание - да, надо поправить

vasulpr
не хочу этим заниматься, поскольку это повлечёт множество других вопросов. да и зачем? неужели не exdupe/zpaq, ни shar+srep, ни freearc+srep не устраивают?

Bulat_Ziganshin
Не устраивает упаковка в архив без сжатия чтобы потом срепом обработать, из-за чего зартачаеться больше времени и ресурсов на упаковку и распаковку. Все-таки вы бы лучше над этим подумали, если хотите тесно интегрировать среп в ФА.

Bulat_Ziganshin

Здравствуйте
Как я понимаю Вы автор ?
Скажите пожалуйста почему при достаточном количестве изменения номер версии (пусть это даже альфа) - не меняется ?
Спасибо

Всем привет. Подскажите как через ком. строку распаковать файл *srep в нужной папке? Батник: srep ./DiscContentPC/ -d data.cab data.srep

vasulpr
пакуй freearc с опцией -mc:rep/srep. или галочку в gui просто отметь. так устраивает?

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

WiperX
srep -d inputDir/data.srep outputDir/data.cab

Bulat_Ziganshin
Лично я пакую сначала срепом, а затем ФА, это позволяет переупаковывать звено ФА (подбор параметров) без перепаковкы срепа.

Чтобы в ФА использовать среп нужно много свободного места на диске для промежуточного файла при упаковке да и там беда с прогресбаром.

Меня в срепе все устраивает кроме отсутствия работы с папками и отсутствия хелпа, если какую-то опцию надо, то приходится километры текста перекапывать чтобы найти, было бы хорошо чтобы вместе с срепом в комплекте шел хелп с десятком основных опцый

Булат, спасибо за помощь А есть дока для srep c параметрами ком. строки? И еще вопрос, можно ли при распаковке через unarc отобразить ход выполнения как в Arc (время и проценты)?