» FreeArc (часть 4)

Скажите пожалуйста.
Как сделать чтоб после завершения архивирования ОКНО АРХИВИРОВАНИЯ не закрывалось автоматом?
(через опцию, и при использовании командной строки)

Fossius
А какой текст ошибки m80?
(у меня нормально)
-----
Выложил на яндекс диске файл
arc 2014-12-27.rar


Добавлено:
muzf
В методах -m90...-m99 тупо (пока) увеличен размер rep.
Все!


Добавлено:

Цитата:

немного менялись только настройки и параметры частей архиватора в .ini файле

Разве?
Там по-моему, файл ini от 11.07.12!

Shuld
разобрался, просто использовал
Цитата:

-m80
FreeArc 0.67 (December 12 2012) Creating archive: proba5.arc using rep:1gb:256:c256+4x4:lz4b

а надо lz4

Цитата:

Выложил на яндекс диске файл
arc 2014-12-27.rar

чёто не найду, можно ссыль?

Все материалы есть в папках «FreeArc» по ссылке
Архиваторы - http://yadi.sk/d/alBxY9Rl7mOH0

Bulat_Ziganshin

Арихвирую файл длиной 450 398 059 байт.
-----
arc2012-12-12

FreeArc 0.67 (December 12 2012) Creating archive: lzma.arc using 4x4:t1:i0:b510mb:lzma:101mb:normal:bt4:128
Memory for compression 1897mb, decompression 1047mb, cache 1mb
Compressing 1 file, 450,398,059 bytes.
Compressed 1 file, 450,398,059 => 150,414,391 bytes. Ratio 33.3%
Compression time: cpu 229.94 secs, real 129.95 secs. Speed 3,466 kB/s

FreeArc 0.67 (December 12 2012) Creating archive: lzma.arc using lzma:176mb:normal:bt4:128
Memory for compression 1808mb, decompression 176mb, cache 16mb
Compressing 1 file, 450,398,059 bytes.
Compressed 1 file, 450,398,059 => 149,985,707 bytes. Ratio 33.3%
Compression time: cpu 229.66 secs, real 129.35 secs. Speed 3,482 kB/s
-----
arc2014-03-15

FreeArc 0.67 (March 15 2014) Creating archive: lzma.arc using 4x4:t1:i0:b510mb:lzma:101mb:normal:bt4:128
Memory for compression 1897mb, decompression 1047mb, cache 1mb
Compressing 1 file, 450,398,059 bytes.
Compressed 1 file, 450,398,059 => 150,414,391 bytes. Ratio 33.40%
Compression time: cpu 270.97 sec/real 170.36 sec = 159%. Speed 2.64 mB/s

FreeArc 0.67 (March 15 2014) Creating archive: lzma.arc using lzma:176mb:normal:bt4:128
Memory for compression 1808mb, decompression 176mb, cache 16mb
Compressing 1 file, 450,398,059 bytes.
Compressed 1 file, 450,398,059 => 149,985,707 bytes. Ratio 33.30%
Compression time: cpu 271.92 sec/real 171.35 sec = 159%. Speed 2.63 mB/s
-----
Размер архива в новой версии тот же.
А время
129.95 secs -> 170.36 sec
129.35 secs -> 171.35 sec
???
Нужны объяснения.

Добавлено:
При архивировании использовал команды
Arc.exe a lzma proba.arc -m4x4:i0:lzma:256mb:h256m:normal:bt4:128 -di >otchet-lzma0-256-256.txt
Arc.exe a lzma proba.arc -mlzma:256mb:h256m:normal:bt4:128 -di >otchet-lzma256-256.txt

Уже сам архиватор "обрезал" размер словаря.
Как можно задать размер словаря 256mb и больше?
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=2560#13

В последней Альфе(15 мая 2014) на windows xp (сборка Simplix чистая и рабочая) не работают файловые ассоциации и нет контекстного меню.
На Windows 7 x64 проблем нет(по крайней мере с меню)

В версии 0,666 всё пашет на XP.

Мне в принципе без разницы. Какой версией бекапы делать. Для галочки автору исправить недочёт.

Bulat_Ziganshin
Версия FreeArc 0.67 (March 15 2014) имеет неприятный глюк: если архивировать с включенной опцией выключения ПК по завершении операции, то при попытке отменить ахрхивацию, сперва выдет ошибку (вообще ее всегда выдает при отмене операции), а затем все равно выключает комп.

Заменили ini из arc 2014-12-27.rar, получили такую картину:
Оригинал: 548,729,751
-m98: 182,249,123 - 33.21% ~2min
-m99: 182,218,881 - 33.21% ~10min
-mx -s: 152,906,960 - 27.87% ~10min

Как так модифицированные опции с легкостью бьет стоковый сетап?

7-zip (lzma2, 192mb): 152,905,373 - 27.87% ~12min

И почему вдруг 7-zip 9.22b побил arc?

izmerenie
1. время распаковки (точнее тестирования) сравнил? вообще надо lt сразу проверять
2. если сжатие ожинаково то 7z будет чуть меньше ибо у него компактней служеюная инфа

Bulat_Ziganshin
ладно с 7-zip (результат почти равен режиму -mx -s, что по сжатию, что по времени), но почему "-mx -s" жмет лучше -m99 почти на 6% при таких же временных затратах и при меньшем (на 200мб) использовании памяти?

izmerenie
1. Как можно отвечать на ваш вопрос, когда неясно что сжимали?
2. Идеального варианта на все случаи жизни не бывает. Для каждых данных используйте тот вариант, что больше подходит. Вот и все.

Добавлено:
3. Методы -m9х наиболее эффективны для больших размеров данных, 2 Гб и более. Вы сжимали "всего" 548,729,751 байт.
(Для такого объема Вы могли использовать метод -m89 с тем же размером архива, но ОЗУ потребовалось бы меньше.)

Добавлено:
----
Было бы полезно в виде обратной связи, если бы Вы испытали эти методы на своих (разных) данных, а потом бы подробно осветили результаты. Была бы пища для совершенствования.

Shuld
Сжималась папка с конфигурацией для 1С 8. На других данных при случае обязательно попробуем.

Ну что, когда там будет 64 битная версия ? 2015 уже на дворе. 20% прибавки скорости на дороге не валяются.

При установке игры 99% установщик freearc выдает ошибку -7.Что можно сделать с этим и как это исправить?Пожалуйста подскажите или есть какой нибудь патчик для этого!!!

muzf
в конце февраля первая альфа

Более быстрый LZMA.

Resursator
если хочешь, можешь его постестировать на реальных данных и нам рассказать. пока что я знаю - что сжатие хуже, распаковка быстрее. упаковка может распараллеливаться на много яджер, а не только два как у lzma

Bulat_Ziganshin

Цитата:

пока что я знаю - что сжатие хуже

А насколько хуже ?


Цитата:

распаковка быстрее

Это большой плюс.


Цитата:

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

Т.е. на современных 4-х, 6-, 8- и более ядерных CPU он будет заруливать по скорости обычный LZMA в глубокие минуса.


Цитата:

в конце февраля первая альфа

Ждем. Главное, чтобы она в дальнейшем не осталась вечной альфой.

Цитата:

А насколько хуже ?

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

Добавлено:
Nail441
обратись к автору репака или - проще - скачай другой репак. мы тут не поможем

Лучше бы Игорь развивал свой LZMH вместо LZMA2.

возможно такой вопрос уже был, но все же спрошу: сколько ядер использует freearc для компрессии и декомпрессии, так же как и LZMA - 2? или все?
если не все, то планируется ли поддержка многоядерных процессоров?

csf22
максимальное сжатие (а также high/ultra) - два ядра для сжатия, одно при распаковке, собственно как и в lzma. более слабые методы сжатия - многопоточные в обе стороны

Bulat_Ziganshin
не знаю, насколько вам это будет интересно
попался на глаза такой вот супер-быстрый хэш: https://code.google.com/p/xxhash/

csf22
Буквально все архиваторы (алгоритмы), которые используют многопоточность - сжимают хуже! А памяти требуют больше!
Поэтому очень интересный вопрос, нужна ли многопоточность при сжатии.
Видимо, только на очень больших объемах данных, которые сжимать долго.

Shuld

Цитата:

Буквально все архиваторы (алгоритмы), которые используют многопоточность - сжимают хуже!

Если разница в сжатии - считанные проценты, а скорость растет пропорционально количеству потоков, то многопоточность решает.


Цитата:

А памяти требуют больше!

Сегодня даже на компьютерах класса "печатная машинка" стоит минимум 4 Gb памяти.

Алгоритм, архитектурно упирающийся в 2 ядра - это тупик. Именно поэтому будущее за алгоритмами вроде LZHAM, а не за LZMA/LZMA2.

Benchmark
Пользуясь случаем, в продолжение оффтопа как бы, спрошу:
Сколько ж ядер на печатных машинках, что решает многопоточность ?
Есть ли возможность прикрутить LZHAM к 7-Zip—у ? (как Lzmh.dll когда-то)

Цитата:

Есть ли возможность прикрутить LZHAM к 7-Zip—у ? (как Lzmh.dll когда-то)

он прикручен, взгляни на encode.ru/forum


Цитата:

Алгоритм, архитектурно упирающийся в 2 ядра - это тупик. Именно поэтому будущее за алгоритмами вроде LZHAM, а не за LZMA/LZMA2.

думаю что и к lzma это прикручивается, надо просто поработать. не удивлю.сь если игорь именно над этим корпит


Цитата:

супер-быстрый хэш: https://code.google.com/p/xxhash/

в srep гораздо быстрее

Цитата:

он прикручен

x86

Цитата:

x86

а чего тут плохого? не линукс, забивающий лишнюю память 64 битный виндовс 32 битку прекрасно крутит. или про ARM горе?

Цитата:

x86

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