Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: Bulat_Ziganshin
Дата сообщения: 03.01.2012 09:45
Если кто переводил с русского - там была небольшая ошибка в 1509: "требуют много памяти" вместо "требуют много времени"

Добавлено:
vasulpr
а что по-твоему означает -lc-?


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

чтение входных файлов при архивации и запись выходных при распаковке идёт через кеш. его размер 256 кб при распаковке и обычно 8-32 мб при упаковке. опция --cache. а -di печатает это размер

Добавлено:

Цитата:
Почему при Memory for compression более 1444mb из-под консоли методы сжатия работают без темп-файла, а под оболочкой (GUI) - с темп-файлом


потому что память более фрагментирована. в заголовке "2гб" поищи


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


не подтверждаю. может дело в каких-то специфичных опциях или других условиях. тестировал ес-но на последней альфе
Автор: Bulat_Ziganshin
Дата сообщения: 27.02.2011 20:59

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

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

вот из моего расследования:
U:\>fc /b lp2.pcf.srep-r G:\lp2.pcf.srep-r
Сравнение файлов lp2.pcf.srep-r и G:\LP2.PCF.SREP-R
91DDA103: 2B 6B
BD1C6103: 9C DC

потом объясню. но по похожим адресам и номеру бита похоже на конкретную микросхему памяти
Автор: egor23
Дата сообщения: 27.02.2011 21:54
Bulat_Ziganshin

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

для меня выходом будет stdin/stdout но там сейчас не доделки, и хотелось бы чтобы у FreeArc\Arc\unarc был полноценный stdin/stdout.

Цитата:
compression made about 20% faster


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

1. Подопытный Nero-9.2.6.0_trial.tar 1883МБ, srep294_x64.exe \ srep293_x64.exe

[more=Результаты..]
srep294_x64.exe
Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 44.383 mb/sec, real 27.736 mb/sec -m1f -a1
Compression ratio: 1974371328 -> 550257240: 27.87%. Cpu 57.646 mb/sec, real 32.215 mb/sec -m1f -a2
Compression ratio: 1974371328 -> 550609420: 27.89%. Cpu 66.365 mb/sec, real 34.859 mb/sec -m1f -a4
Compression ratio: 1974371328 -> 550972564: 27.91%. Cpu 65.573 mb/sec, real 34.517 mb/sec -m1f -a8
Compression ratio: 1974371328 -> 551412320: 27.93%. Cpu 61.014 mb/sec, real 33.182 mb/sec -m1f -a16

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 55.251 mb/sec, real 38.371 mb/sec -m2f -a1 -nommap
Compression ratio: 1974371328 -> 550257240: 27.87%. Cpu 74.593 mb/sec, real 46.822 mb/sec -m2f -a2 -nommap
Compression ratio: 1974371328 -> 550609420: 27.89%. Cpu 88.861 mb/sec, real 52.172 mb/sec -m2f -a4 -nommap
Compression ratio: 1974371328 -> 550972564: 27.91%. Cpu 89.808 mb/sec, real 51.446 mb/sec -m2f -a8 -nommap
Compression ratio: 1974371328 -> 551412320: 27.93%. Cpu 78.048 mb/sec, real 48.029 mb/sec -m2f -a16 -nommap

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 48.303 mb/sec, real 33.788 mb/sec -m3f -a1 -nommap
Compression ratio: 1974371328 -> 506648001: 25.66%. Cpu 60.344 mb/sec, real 39.296 mb/sec -m3f -a2 -nommap
Compression ratio: 1974371328 -> 506368182: 25.65%. Cpu 65.778 mb/sec, real 41.099 mb/sec -m3f -a4 -nommap
Compression ratio: 1974371328 -> 506046268: 25.63%. Cpu 60.867 mb/sec, real 39.451 mb/sec -m3f -a8 -nommap
Compression ratio: 1974371328 -> 506086777: 25.63%. Cpu 52.410 mb/sec, real 35.309 mb/sec -m3f -a16 -nommap

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 55.155 mb/sec, real 41.736 mb/sec -m2f -a1
Compression ratio: 1974371328 -> 550257240: 27.87%. Cpu 74.725 mb/sec, real 52.050 mb/sec -m2f -a2
Compression ratio: 1974371328 -> 550609420: 27.89%. Cpu 90.516 mb/sec, real 59.269 mb/sec -m2f -a4
Compression ratio: 1974371328 -> 550972564: 27.91%. Cpu 88.798 mb/sec, real 58.401 mb/sec -m2f -a8
Compression ratio: 1974371328 -> 551412320: 27.93%. Cpu 79.622 mb/sec, real 54.392 mb/sec -m2f -a16

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 49.846 mb/sec, real 38.536 mb/sec -m3f -a1
Compression ratio: 1974371328 -> 506648001: 25.66%. Cpu 62.710 mb/sec, real 45.758 mb/sec -m3f -a2
Compression ratio: 1974371328 -> 506368182: 25.65%. Cpu 68.082 mb/sec, real 48.649 mb/sec -m3f -a4
Compression ratio: 1974371328 -> 506046268: 25.63%. Cpu 63.402 mb/sec, real 46.188 mb/sec -m3f -a8
Compression ratio: 1974371328 -> 506086777: 25.63%. Cpu 53.588 mb/sec, real 40.582 mb/sec -m3f -a16


srep293_x64.exe
Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 39.487 mb/sec, real 25.627 mb/sec -m1f -a1
Compression ratio: 1974371328 -> 549655828: 27.84%. Cpu 48.788 mb/sec, real 29.296 mb/sec -m1f -a2
Compression ratio: 1974371328 -> 549804900: 27.85%. Cpu 49.866 mb/sec, real 29.706 mb/sec -m1f -a4
Compression ratio: 1974371328 -> 550104920: 27.86%. Cpu 42.247 mb/sec, real 26.812 mb/sec -m1f -a8
Compression ratio: 1974371328 -> 550462548: 27.88%. Cpu 30.940 mb/sec, real 21.729 mb/sec -m1f -a16

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 50.322 mb/sec, real 35.912 mb/sec -m2f -a1 -nommap
Compression ratio: 1974371328 -> 549655828: 27.84%. Cpu 69.658 mb/sec, real 44.501 mb/sec -m2f -a2 -nommap
Compression ratio: 1974371328 -> 549804900: 27.85%. Cpu 78.778 mb/sec, real 48.540 mb/sec -m2f -a4 -nommap
Compression ratio: 1974371328 -> 550104920: 27.86%. Cpu 72.872 mb/sec, real 45.830 mb/sec -m2f -a8 -nommap
Compression ratio: 1974371328 -> 550462548: 27.88%. Cpu 60.517 mb/sec, real 40.697 mb/sec -m2f -a16 -nommap

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 45.032 mb/sec, real 32.006 mb/sec -m3f -a1 -nommap
Compression ratio: 1974371328 -> 506624945: 25.66%. Cpu 56.944 mb/sec, real 37.609 mb/sec -m3f -a2 -nommap
Compression ratio: 1974371328 -> 506363370: 25.65%. Cpu 57.202 mb/sec, real 38.023 mb/sec -m3f -a4 -nommap
Compression ratio: 1974371328 -> 506079623: 25.63%. Cpu 49.148 mb/sec, real 33.963 mb/sec -m3f -a8 -nommap
Compression ratio: 1974371328 -> 506113814: 25.63%. Cpu 37.110 mb/sec, real 27.593 mb/sec -m3f -a16 -nommap

Compression ratio: 1974371328 -> 549575868: 27.84%. Cpu 52.475 mb/sec, real 40.153 mb/sec -m2f -a1
Compression ratio: 1974371328 -> 549655828: 27.84%. Cpu 71.551 mb/sec, real 50.395 mb/sec -m2f -a2
Compression ratio: 1974371328 -> 549804900: 27.85%. Cpu 80.076 mb/sec, real 54.672 mb/sec -m2f -a4
Compression ratio: 1974371328 -> 550104920: 27.86%. Cpu 73.551 mb/sec, real 51.224 mb/sec -m2f -a8
Compression ratio: 1974371328 -> 550462548: 27.88%. Cpu 61.911 mb/sec, real 45.383 mb/sec -m2f -a16

Compression ratio: 1974371328 -> 506471682: 25.65%. Cpu 46.320 mb/sec, real 36.544 mb/sec -m3f -a1
Compression ratio: 1974371328 -> 506624945: 25.66%. Cpu 59.463 mb/sec, real 43.992 mb/sec -m3f -a2
Compression ratio: 1974371328 -> 506363370: 25.65%. Cpu 60.430 mb/sec, real 44.560 mb/sec -m3f -a4
Compression ratio: 1974371328 -> 506079623: 25.63%. Cpu 50.544 mb/sec, real 38.975 mb/sec -m3f -a8
Compression ratio: 1974371328 -> 506113814: 25.63%. Cpu 37.992 mb/sec, real 31.027 mb/sec -m3f -a16


Дожатие LZMA

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m1f_a1.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m1f_a1
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m1f_a1.arc
Compressed 1 file, 550,249,940 => 208,237,262 bytes. Ratio 37.8%
Compression time: cpu 714.16 secs, real 718.73 secs. Speed 766 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m3f_a1.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m3f_a1
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m3f_a1.arc
Compressed 1 file, 506,463,502 => 204,878,047 bytes. Ratio 40.4%
Compression time: cpu 663.89 secs, real 665.47 secs. Speed 761 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m1f_a4.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m1f_a4
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m1f_a4.arc
Compressed 1 file, 551,279,632 => 208,328,827 bytes. Ratio 37.7%
Compression time: cpu 718.45 secs, real 723.58 secs. Speed 762 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m3f_a4.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m3f_a4
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m3f_a4.arc
Compressed 1 file, 506,359,874 => 204,878,513 bytes. Ratio 40.4%
Compression time: cpu 664.78 secs, real 666.84 secs. Speed 759 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m1f_a16.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m1f_a16
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m1f_a16.arc
Compressed 1 file, 552,068,596 => 208,342,870 bytes. Ratio 37.7%
Compression time: cpu 720.98 secs, real 724.55 secs. Speed 762 kB/s
All OK

arc.exe a Nero-9.2.6.0_trial.tar.srep294_m3f_a16.arc -mlzma:128m:bt4:128 Nero-9.2.6.0_trial.tar.srep294_m3f_a16
FreeArc 0.67 (November 17 2010) creating archive: Nero-9.2.6.0_trial.tar.srep294_m3f_a16.arc
Compressed 1 file, 506,059,929 => 204,863,352 bytes. Ratio 40.4%
Compression time: cpu 667.92 secs, real 672.72 secs. Speed 752 kB/s
All OK


Распаковка SREP

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a1 nul
Compression ratio: 1974371328 -> 550253040: 27.87%. Cpu 456.172 mb/sec, real 339.629 mb/sec. Matches 0 43298 168801, I/Os 0, MiBs 0 359 1217

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a2 nul
Compression ratio: 1974371328 -> 550932144: 27.90%. Cpu 426.891 mb/sec, real 103.853 mb/sec. Matches 0 42933 168237, I/Os 0, MiBs 0 369 1216

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a4 nul
Compression ratio: 1974371328 -> 551288832: 27.92%. Cpu 426.891 mb/sec, real 109.521 mb/sec. Matches 0 43065 169346, I/Os 0, MiBs 0 370 1214

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a8 nul
Compression ratio: 1974371328 -> 551650704: 27.94%. Cpu 438.749 mb/sec, real 111.386 mb/sec. Matches 0 43196 169019, I/Os 0, MiBs 0 371 1215

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m1f_a16 nul
Compression ratio: 1974371328 -> 552092176: 27.96%. Cpu 467.999 mb/sec, real 115.355 mb/sec. Matches 0 42807 169475, I/Os 0, MiBs 0 370 1212

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a1 nul
Compression ratio: 1974371328 -> 506474882: 25.65%. Cpu 435.723 mb/sec, real 122.378 mb/sec. Matches 0 41955 172483, I/Os 0, MiBs 0 380 1241

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a2 nul
Compression ratio: 1974371328 -> 506651057: 25.66%. Cpu 408.931 mb/sec, real 122.757 mb/sec. Matches 0 41436 172576, I/Os 0, MiBs 0 384 1240

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a4 nul
Compression ratio: 1974371328 -> 506371254: 25.65%. Cpu 418.410 mb/sec, real 123.105 mb/sec. Matches 0 41443 172875, I/Os 0, MiBs 0 384 1237

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a8 nul
Compression ratio: 1974371328 -> 506049292: 25.63%. Cpu 437.231 mb/sec, real 123.797 mb/sec. Matches 0 41399 173040, I/Os 0, MiBs 0 387 1239

srep294_x64.exe -d -nomd5 Nero-9.2.6.0_trial.tar.srep294_m3f_a16 nul
Compression ratio: 1974371328 -> 506089673: 25.63%. Cpu 412.940 mb/sec, real 115.477 mb/sec. Matches 0 41332 173304, I/Os 0, MiBs 0 387 1235
[/more]
Автор: vasulpr
Дата сообщения: 03.01.2012 10:58

Цитата:
а что по-твоему означает -lc-?

снимает ограничение в 75% от физической памяти. т.е. с этой опцией ФА будет использовать 100% размера свободного адресного пространства. разве не так?
Автор: Bulat_Ziganshin
Дата сообщения: 03.01.2012 11:06
vasulpr
не так

Добавлено:
это мне вопросы почтой прислали..

Цитата:
2. в файл перевода можно добавлять комментарии, или структура не допускает этого (хотелось бы разместить дату выполнения, под какую версию заточен и другую служебную информацию)?
3. при удалении всего содержимого архива появляется неприятное сообщение об ошибке
4. будет ли реализован drag-n-drop содержимго архива?
5. хотелось бы сохранения последних параметров упаковки (например лень устанавливать флажок защита каждый раз)
6. можно ли менять настройки сжатия меню добавить в arc проводника?
7. русский sfx планируется?


2. при сборке файла перевода для новой версии вся его структура берётся из моего arc.russian.txt, а из ваших - только правые части самих переводов. надо бы наверно что-то с этим сделать, а пока эту информацию переводчики традиционно вставляют сюда:

0159 Translated by=Peter Bauder alias JangoFat\nbased on 7zip language file\nedited for FreeArc-v0.67 (November 12 2011)

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

5. а как я определю что сохранять, а что ты только на один раз включил? особенно когда эта опция опасна...

6. можно, но только вручную (редактируя lua-скрипт). надо наверно какой-то пример на эту тему нарисовать...

7. его можно сделать самому, отредактировав ресурсы исполняемого файла sfx. а лучше - перевести текст в common.rc и бросить мне чтобы я сразу все sfx откомпилял с ним

Добавлено:

Цитата:
6. можно ли менять настройки сжатия меню добавить в arc проводника?


да, это проще пареной репы. вот смотри что мы сейчас имеем в ArcShellExt-user.lua:


Цитата:
-- Compression commands
compression_menu = {
append (command.add2arc, {param = arcname, command = freearc.." a --noarcext " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" " .. filelist}),
append (command.add2sfx, {param = sfxname, command = freearc.." a --noarcext -sfx " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" " .. filelist}),
append (command.add2zip, {param = arcbase..".zip", command = freearc.." a --noarcext -tzip "..add_options.." -sclUTF-8 -- \"" .. arcbase..".zip\" " .. filelist}),
append (command.add2_7z, {param = arcbase..".7z", command = freearc.." a --noarcext -t7z "..add_options.." -sclUTF-8 -- \"" .. arcbase..".7z\" " .. filelist}),
append (command.add, { command = freearc.." --add-dialog a " ..add_options.." -- "..filename}),
}


так что добавить например сжатие в -m3 можно так:

Цитата:
-- Compression commands

command.add2arc_m3 = {text = "Добавить с -m3 в \"%s\"", help = "Сжать выделенные файлы в -m3 с помощью FreeArc"}

compression_menu = {
append (command.add2arc_m3, {param = arcname, command = freearc.." a --noarcext -m3 " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" " .. filelist}),
append (command.add2arc, {param = arcname, command = freearc.." a --noarcext " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" " .. filelist}),
append (command.add2sfx, {param = sfxname, command = freearc.." a --noarcext -sfx " ..add_options.." -sclUTF-8 -- \"" .. arcname .. "\" " .. filelist}),
append (command.add2zip, {param = arcbase..".zip", command = freearc.." a --noarcext -tzip "..add_options.." -sclUTF-8 -- \"" .. arcbase..".zip\" " .. filelist}),
append (command.add2_7z, {param = arcbase..".7z", command = freearc.." a --noarcext -t7z "..add_options.." -sclUTF-8 -- \"" .. arcbase..".7z\" " .. filelist}),
append (command.add, { command = freearc.." --add-dialog a " ..add_options.." -- "..filename}),
}
Автор: Bulat_Ziganshin
Дата сообщения: 27.02.2011 22:37
SREP 2.95 alpha:

* -mem option limits amount of RAM used for future-LZ decompression
* -vmfile and -vmblock options fine-tunes VM file used in -mem mode

Tests with the same 22gb->7gb file:

Код: : Cpu 211.560 mb/sec, real 165.110 mb/sec. Matches 0 174390 1449482, I/Os 0, RAM 0/1919, VM 0/0, R/W 0/0
-mem1g : Cpu 203.116 mb/sec, real 151.955 mb/sec. Matches 0 174390 1482625, I/Os 0, RAM 0/983, VM 0/1000, R/W 1560/1560
-mem500: Cpu 193.556 mb/sec, real 136.138 mb/sec. Matches 0 165382 1621776, I/Os 0, RAM 0/460, VM 0/1656, R/W 3768/3768
-mem200: Cpu 146.510 mb/sec, real 99.487 mb/sec. Matches 0 70888 2376056, I/Os 0, RAM 0/160, VM 0/2136, R/W 12120/12120
-mem100: Cpu 76.815 mb/sec, real 54.448 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760
Автор: egor23
Дата сообщения: 27.02.2011 23:14
srep295.exe -d -mem128m -vmfile=vmfile_temp Nero-9.2.6.0_trial.tar.srep294_m3f_a4 - | 7z.exe x -si -ttar

Ratio: 1974371328 -> 506371254: 25.65%. Cpu 94.158 mb/sec, real 28.186 mb/sec. Matches 0 15102 286644, I/Os 0, RAM 0/88, VM 0/320, R/W 1160/1160

Everything is Ok

Folders: 57
Files: 1052
Size: 1973508786
Compressed: 568320

работает
Автор: egor23
Дата сообщения: 28.02.2011 01:46
Bulat_Ziganshin
ну вот приехали
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data

s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8

Добавлено:

Цитата:
ну вот приехали
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data

s-so123_512.srep делался 01.12.2009 скорее всего версией 0.8

s-so123_512.srep распакован версией 0.8
при повторной попытке c srep295.exe распаковка прошла удачно
Автор: egor23
Дата сообщения: 28.02.2011 14:26
Bulat_Ziganshin
Подопытный s-so123.tar 22427МБ, srep295_x64.exe

Упаковка
Compression ratio: 23516088832 -> 13137073412: 55.86%. Cpu 21.334 mb/sec, real 16.087 mb/sec -m1f -a1
Compression ratio: 23516088832 -> 13137263784: 55.87%. Cpu 38.879 mb/sec, real 24.641 mb/sec -m1f -a4

[more=Лог..]

timer.exe srep295_x64.exe -m1f -a1 s-so123.tar s-so123.tar.srep295_m1f_a1_l512

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1403 mb, -m1f -l512 -c512 -a1
Compression ratio: 23516088832 -> 13137073412: 55.86%. Cpu 21.334 mb/sec, real 16.087 mb/sec
Second pass: 100%

Kernel Time = 94.406 = 00:01:34.406 = 4%
User Time = 1405.250 = 00:23:25.250 = 65%
Process Time = 1499.656 = 00:24:59.656 = 69%
Global Time = 2152.750 = 00:35:52.750 = 100%


timer.exe srep295_x64.exe -m1f -a4 s-so123.tar s-so123.tar.srep295_m1f_a4_l512

Timer 3.01 Copyright (c) 2002-2003 Igor Pavlov 2003-07-10
1595 mb, -m1f -l512 -c512 -a4
Compression ratio: 23516088832 -> 13137263784: 55.87%. Cpu 38.879 mb/sec, real 24.641 mb/sec
Second pass: 100%

Kernel Time = 99.218 = 00:01:39.218 = 6%
User Time = 904.062 = 00:15:04.062 = 54%
Process Time = 1003.281 = 00:16:43.281 = 60%
Global Time = 1648.062 = 00:27:28.062 = 100%
[/more]

Распаковка
srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp -s s-so123.tar.srep295_m1f_a1_l512 nul
Ratio: 23516088832 -> 13137548864: 55.87%. Cpu 154.378 mb/sec, real 39.751 mb/sec. Matches 0 12626 120042, I/Os 0, RAM 0/1759, VM 0/1568, R/W 2752/2752

srep295_x64.exe -d -mem1800m -vmfile=vmfile_temp -s s-so123.tar.srep295_m1f_a4_l512 nul
Ratio: 23516088832 -> 13137759232: 55.87%. Cpu 155.478 mb/sec, real 44.838 mb/sec. Matches 0 9531 124168, I/Os 0, RAM 0/1759, VM 0/1504, R/W 2600/2600

Добавлено:
Bulat_Ziganshin
для -m1 многопоточность сделать возможно?
Автор: Shuld
Дата сообщения: 03.01.2012 13:32
Выложил свежий тест
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#4
с архиваторами: WinRAR 4.10b5 (15 дек 2011), 7z 9.22b (18.04.2011), FreeArc 0.67 (25 декабря 2011). Объем сжимаемых данных - 2 ГБ.
Из шокирующих фактов отмечу, что мой метод -m82 сжал быстрее, чем режим
WinRAR «без сжатия», и при этом сильнее максимального непрерывного режима WinRAR!
И это без всяких lzma!

Bulat_Ziganshin
Вы недооцениваете свои rep и tor!

Нет ли в тесте существенных неточностей с вашей точки зрения?
Автор: Engaged Clown
Дата сообщения: 28.02.2011 14:41
Позволил себе наглость поправить шапку.
Что сделал:

1) Добавил тему по Rep и Srep. Шапка там включена, можно развить тему.
2) Добавил в архиваторы PowerArchiver и HaoZip.

Backup под

Версия для ОС Linux:

инсталлятор
[/more]

2
[more=FAQ по FreeArc]Q: (консольная версия) Как мне распаковать архив не в текущий каталог, а в заданный?
A: Воспользуйтесь параметром -dp=каталог.

Q: (консольная версия) Как использовать параметр -ag для автогенерации имени архива?
A: Пример:arc a -ag%Y%m%d MyArc_.arc *.txt --> MyArc_20091020.arc
Полный список опций можно посмотреть тут - Автоматическая генерация имени архива

Q: Есть ли поддержка многотомности (разбиение архива на части)?
A: Пока нет, но планируется. Дешёвая и сердитая реализация типа 7-zip'овской признана нецелесообразной.

Q: Я пользуюсь precomp прямо в FreeArc (кто не понял FreeArc сразу сжимает с подключением к сжатию precomp) Так вот чтобы потом архив распаковать надо какието параметры писать и файлики лополнительные.
A: Файлы - каталог max из freearc power pack. эти файлы должны быть во время упаковки в текущем каталоге или каталоге, доступном по PATH, за исключением arc.ini, который должен лежать в c:\
Если это сделать, то обычный скрипт распаковки freearc архивов всё как надо сделает. Но при этом у тебя будет кривой прогресс-бар и окошко precomp будет светиться на экране

Q: Хочу распаковать архивы в подкаталоги перед упаковкой в arc чтобы добиться максимального сжатия
A: Готовый батник для этого здесь

Q: Поддерживает ли зашифрованные архивы SFX/unarc.exe/unarc.dll?
A: Да, в альфа версии 0.67

Q: Возможно ли в arc реализовать запуск файла из архива после распаковки этого архива?
A: freearc-installer.sfx извлекает архив во временный каталог, запускает setup.exe и после его выполнения стирает все временные файлы. freearc-installer-nodelete.sfx делает то же самое кроме стирания[/more]

3
[more=Почему он сжимает лучше и быстрее, чем 7-zip/rar...] Почему он сжимает лучше, чем 7-zip/rar: поддерживаются алгоритмы lzma, ppmd и multimedia-сжатие с автоматическим выбором подходящего алгоритма по расширению файла
для улучшения сжатия используются фильтры dict (словарная замена), rep (находит повторы на расстоянии до 1Гб), delta (улучшает сжатие таблиц в бинарных файлах), bcj (EXE-фильтр), lzp (устраняет повторы в текстовых файлах)
в режиме максимального сжатия алгоритмы сжатия работают не параллельно, а последовательно, выгружая промежуточные данные на диск, что позволяет каждому из них использовать весь объём ОЗУ компьютера
если вам мало встроенных алгоритмов - вы можете использовать внешние: от препроцессора сжатых данных precomp до алгоритмов максимального сжатия ccmx/lpaq/durilca/uda/paq
плюс к этому производится интеллектуальная сортировка файлов, группирующая вместе одинаковые/похожие файлы и различные версии одного и того же файла
Почему быстрее упаковывает: для текстовых файлов используется ppmd, который работает куда быстрее чем lzma
использование фильтров уменьшает размер фактически сжимаемых данных
в быстрых режимах сжатия (-m1/-m2) используются специально разработанные быстрые алгоритмы - tornado и grzip
чтение сжимаемых данных идёт параллельно сжатию в специальный большой буфер, поэтому задержки дисковых операций не сказываются на процессе упаковки[/more]

4
[more=Результаты тестов, подтверждающие его крутизну...]

обсуждение на форуме www.compression.ru

Тестирование maximumcompression.com на 46 типах файлов (510 файлов, 301 Мб). FreeARC 0.51 занял первые 4 места по эффективности из 246 тестировавшихся архиваторов+режимов!
SqueezeChart 2009
Monster of compression 2009 (MOC 2009)
Squxe Archivers Chart (2007)[/more]

5
[more=Что подразумевается под "интеграцией с Explorer"]родные виндовые диалоги выбора файлов/каталогов (реализовано в 0.51)
контекстное меню на архивах .arc и других файлах, а также каталогах, с возможностью сделать его каскадным и выбором из большого набора команд (реализовано в 0.52)
отображение стандартного контекстного меню эксплорера в самом FreeArc
отображение иконки файла в списке файлов и диалоге перезаписи файла
колонка "тип файла", отображающая описание типа, полученное от Windows
drag&drop между freearc и explorer, а также между двумя экземплярами FreeArc
кнопка "фоном" должна минимизировать диалог прогресса в system tray[/more]
===== конец СПИСКА МОРЕЙ =====[/#]
[/#]
Автор: vasulpr
Дата сообщения: 03.01.2012 14:56

Цитата:
vasulpr
не так

тогда объясните как. ибо с вашей документации функции этой опции не совсем ясны.

Еще один вопрос: непрерывный блок адресного пространства 2Гб (win7 64), а для упаковки используется 1811Мб, так должно быть, или это опять какое-то ограничение?
Автор: Bulat_Ziganshin
Дата сообщения: 03.01.2012 17:18

Цитата:
тогда объясните как

опции -m задают метод сжатия. он может требовать например 10 гб озу. затем этот метод обрезается под память, заданную в -lc. -lc- просто отключает эту обрезку

если вам нужно использовать 100% озу, то пишите -lc100%. разумеется, это бессмысленно, поскольку тогда не останется места под ОС и программы

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


Цитата:
непрерывный блок адресного пространства 2Гб (win7 64), а для упаковки используется 1811Мб, так должно быть, или это опять какое-то ограничение?


попробуйте -lc- -m=rep:2000m

вообще если вы начали воевать с ограничениями памяти, то проще всего использовать -lc- и вручную конструировать цепочки алгоритмов сжатия
Автор: egor23
Дата сообщения: 28.02.2011 16:49
Bulat_Ziganshin

Цитата:
-mem100: Cpu 76.815 mb/sec, real 54.448 mb/sec. Matches 0 29368 4950862, I/Os 0, RAM 0/60, VM 0/2360, R/W 36760/36760

хи, получается ~100ГБ total R/W HDD
Автор: andhunt
Дата сообщения: 28.02.2011 22:57
Кто сможет помочь за отдельную плату осуществить такое в архиваторе?

можно сделать следующее в 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 должны просто распаковаться)
как такое реализовать, если такого нет могли бы за отдельную плату подредактировать этот модуль?
Автор: Shuld
Дата сообщения: 03.01.2012 18:14
Bulat_Ziganshin

Я бы в методе -m1 предложил бы все цепочки
4x4:tor:3:2mb:h256kb
заменить на
rep:16m+xtor:3:1m:h256k
Объем памяти не должен увеличиться, степень сжатия должна вырасти (на пол-дистанции до -m2), а время - чуть увеличиться (практически незаметно по сравнению с дистанцией до -m2).
Если бороться именно за время, можно сделать h128к - чуть быстрее, но менее сильное сжатие. (но оно нужно - воевать в одностороннем порядке только за время?!)
Рассмотрите, пожайлуста, этот вариант.

Добавлено:
В методе -m2
должно быть улучшение как по скорости, так и по степени сжатия при замене
xtor:5:8m:h2m
на
xtor:6:8m:h1m
Автор: V2driver
Дата сообщения: 01.03.2011 03:11
andhunt сколько $?
Автор: Bulat_Ziganshin
Дата сообщения: 03.01.2012 23:56
Shuld
а размер процессорного кеша вы учитываете?
Автор: Bulat_Ziganshin
Дата сообщения: 01.03.2011 08:35
V2driver
и ты туда же? нельзя молча игнорировать тролля?
Автор: Profrager
Дата сообщения: 04.01.2012 10:04
Bulat_Ziganshin
Есть предложение, чтобы в консольном arc.exe (хотя бы при упаковке) убрать спаминг процентов при запуске внешнего компрессора, иначе эти 10% все остальные циферки перекрывают. Оставить только изменение времени в заголовке окна и хватит.
Автор: slech
Дата сообщения: 01.03.2011 09:13
Bulat_Ziganshin
а почему троля ?
ты сам говорил о поддержке проекта.
Автор: Shuld
Дата сообщения: 04.01.2012 19:37
Bulat_Ziganshin

Цитата:
а размер процессорного кеша вы учитываете?

Нет, не учитывал.
Он до метода -mex6 вкл. 16 МБ, а свыше 256 КБ.

А вот что я не учел - на одноядерном процессоре размер памяти увеличится.
(Я мыслил своим 4-поточным).
Да и пожалуй, я поторопился с кэшем h256kb для метода -m1, все же h128kb лучше будет.
А размер памяти для
rep:16m+xtor:3:1m:h128k
при четырех потоках 41-38-16MB (упаковка-распаковка-кэш)
при двух потоках 33-29-16MB

На вашем сайте со статистикой есть пользователи с ОЗУ 128 МБ.
Интересно, сколько памяти для упаковки им доступно?

Рассуждения о rep-е.
Если посмотреть в моих тестах на любой график для FreeArc-а, то он извилист.
Причем извилины повторяют rep. (объем данных я всегда тестировал большой).
Начиная с метода -m1 "горб" вверх - у него нет rep-а.
Далее полочка с методами -m2...-m4 - у них одинаковый rep:96m.
Далее опять идет спуск вниз - у последующих методов rep растет.
Хорошо это или плохо, но связь прослеживается.
(на маленьких объемах данных зависимости от rep-а не должно быть).
Автор: CDK
Дата сообщения: 01.03.2011 09:36
Попробовал freearc-installer.sfx. Он при запуске начинает тупо распаковывать в temp без каких либо запросов. Попробовал с -s0 (по аналогии с -s2) - тогда уже не запускает в конце setup.exe. Я так понимаю что вариант с запросом куда распаковать не предусмотрен или дело не в лыжах?
ЗЫ: чего-то я rtfm никакого по freearc-installer.sfx не нашел
Автор: Bulat_Ziganshin
Дата сообщения: 04.01.2012 20:15
Shuld
насчёт добавления rep в -m1. думаю, эти данные всё объясняют:

Цитата:
I:\>arc a a -mrep
Compressed 1 file, 810,411,321 => 629,317,667 bytes. Ratio 77.6%
Compression time: cpu 2.89 secs, real 2.39 secs. Speed 339,633 kB/s

I:\>arc a a -mxtor:3
Compressed 1 file, 810,411,321 => 440,306,287 bytes. Ratio 54.3%
Compression time: cpu 11.11 secs, real 1.55 secs. Speed 522,142 kB/s

I:\>arc a a -mrep+xtor:3
Compressed 1 file, 810,411,321 => 372,309,603 bytes. Ratio 45.9%
Compression time: cpu 9.39 secs, real 2.69 secs. Speed 300,804 kB/s

вот если бы rep сделать многопоточным...



Цитата:
Есть предложение, чтобы в консольном arc.exe (хотя бы при упаковке) убрать спаминг процентов при запуске внешнего компрессора, иначе эти 10% все остальные циферки перекрывают. Оставить только изменение времени в заголовке окна и хватит.


сам от этого страдаю проблема в том, что это совершенно разные части программы и надо ещё сообразить как протащить между ними информацию

Добавлено:

Цитата:
а размер процессорного кеша вы учитываете?

Нет, не учитывал.
Он до метода -mex6 вкл. 16 МБ, а свыше 256 КБ.


что такое процессорный кеш - можно посмотреть в гугле. эти 16мб/256кб - дисковый кеш в моей программе. а вот это:
Цитата:
я поторопился с кэшем h256kb
- вообще не кеш, а хеш-таблица

я к чему это объясняю - дискуссии, увы, не получится. ваши идеи не бесполезны, но всё это надо смотреть и перепроверять, учитывая эффекты, названия которых вам ничего не говорят. собственно, поэтому, я не комментировал ваши предложения
Автор: Bulat_Ziganshin
Дата сообщения: 01.03.2011 12:07
CDK
1. а зачем там спрашивать? идея именно в том, чтоб предоставить распакованные файлы для setup.exe, а он уж дальше как нужно разбросает. и вообще лучше использовать IS
2. rtfm нет поскольку в нём нечего описываать
Автор: egor23
Дата сообщения: 01.03.2011 12:11
Bulat_Ziganshin

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


Цитата:
srep295.exe -d s-so123_512.srep s-so123.tar
Ratio: 16735272960 -> 9873103080: 59.00%. Cpu 187.707 mb/sec, real 20.837 mb/sec
ERROR! Checksum of decompressed data is not the same as checksum of original data

Мысля:
Проблема в том что данные получаются битые? или в том что подсчёт md5 сбоит?
можно для тестирования сделать билд, который не прерывает распаковку?
Автор: Shuld
Дата сообщения: 05.01.2012 11:31
Bulat_Ziganshin

Цитата:
всё это надо смотреть и перепроверять

Был бы счастлив, если бы у Вас нашлось время на это. (но его, наверное, нет).

Эффектов, которые я не понимаю, действительно много.
Вот даже сравнение
rep:16m+xtor:3:1m:h128k
и
rep:16m+xtor:3:1m:h256k

- на маленьком объеме данных (до 700 МБ) вариант с хеш-таблицей 256k сжимает предсказуемо сильнее и дольше.
- на больших объемах (свыше 700 МБ) начинают твориться чудеса. На одном и том же компьютере, но на разных данных у меня случалось: сжимали одинаково, но h256k на 5% дольше. В другом случае время одинаково, но h256k сжал заметно сильнее. И были случаи, когда xtor:3 сжимал медленнее (и хуже) чем xtor:5.
Автор: Bulat_Ziganshin
Дата сообщения: 01.03.2011 12:53
slech
тролль - потому что повторяет своё сообщение, разве не очевидно? соответственно, помогая таким людям, вы может и улучшите своё материальное положение, но способствуете засиранию темы и превращению её в такой же отстойник как и темы по is, рекомпрессии и пр.

Engaged Clown
имхо лучшая тема по srep - та, в которой никак не упоминается его название. иначе и в неё набегут пионеры


Цитата:
можно для тестирования сделать билд, который не прерывает распаковку?

-nomd5

Добавлено:

Цитата:
7. может иконку кнопки Add заменить на основную FA ? по аналогии с WinRar.
тогда не мешало бы и кнопку извлечь переделать, а то какой то плейер получается


иконки такие потому, что это стандартные иконки из gtk - там есть набор для плеера, для редактора текстов, а вот для арзиватора как-то нету по идее вещей надо делать на платной основе


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

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


если он не упакуется, то извлечь можно будет с помощью 0.60 или убрав 7z.dll из каталога программы


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

случайное совпадение. от версии архиватора зависит, ибо 0.666 сжимает несколько иначе, сохраняя as-is несжавшиеся блоки
Автор: Bulat_Ziganshin
Дата сообщения: 05.01.2012 12:13
вот ещё результаты тестов:

I:\>arc a a -mrep:64m D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,520,453,511 bytes. Ratio 77.6%
Compression time: cpu 16.49 secs, real 14.17 secs. Speed 319,723 kB/s
I:\>arc create a -mrep:256m D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,325,476,638 bytes. Ratio 73.3%
Compression time: cpu 17.00 secs, real 14.39 secs. Speed 314,814 kB/s
I:\>arc create a -mrep:1g D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,046,406,590 bytes. Ratio 67.2%
Compression time: cpu 17.74 secs, real 15.35 secs. Speed 295,262 kB/s
I:\>arc create a -mrep:2040m -lc- -ld- D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,081,247,699 bytes. Ratio 68.0%
Compression time: cpu 19.75 secs, real 20.10 secs. Speed 225,402 kB/s

I:\>arc create a -mrep:1g:32 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 2,245,307,762 bytes. Ratio 49.5%
Compression time: cpu 42.49 secs, real 40.07 secs. Speed 113,072 kB/s

I:\>arc create a -mxtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,696,917,637 bytes. Ratio 37.4%
Compression time: cpu 56.35 secs, real 7.49 secs. Speed 604,833 kB/s
I:\>arc create a -mexe+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,627,609,136 bytes. Ratio 35.9%
Compression time: cpu 55.07 secs, real 7.96 secs. Speed 569,268 kB/s
I:\>arc create a -mrep:1g+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,283,372,701 bytes. Ratio 28.3%
Compression time: cpu 46.02 secs, real 16.62 secs. Speed 272,611 kB/s
I:\>arc create a -mrep:1g:128+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,221,256,024 bytes. Ratio 26.9%
Compression time: cpu 49.31 secs, real 23.43 secs. Speed 193,409 kB/s
I:\>arc create a -mrep:1g:32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,151,854,135 bytes. Ratio 25.4%
Compression time: cpu 64.23 secs, real 40.51 secs. Speed 111,850 kB/s
I:\>arc create a -mrep:1g:d1m:s32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,184,277,470 bytes. Ratio 26.1%
Compression time: cpu 74.40 secs, real 49.73 secs. Speed 91,108 kB/s

I:\>timer exdupe D:\Testing\dll4g.dll a
COMPRESSED 4,531,060,447 bytes in 1 file(s) into 1,861,014,750 bytes
Kernel Time = 1.934 = 00:00:01.934 = 19%
User Time = 50.497 = 00:00:50.497 = 505%
Process Time = 52.431 = 00:00:52.431 = 525%
Global Time = 9.984 = 00:00:09.984 = 100%
I:\>arc create a -mxtor:3 a
Compressed 1 file, 1,861,014,750 => 1,665,934,654 bytes. Ratio 89.5%
Compression time: cpu 37.75 secs, real 5.03 secs. Speed 369,888 kB/s

I:\>arc create a -mrep:512m+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,309,468,532 bytes. Ratio 28.8%
Compression time: cpu 46.43 secs, real 16.13 secs. Speed 280,945 kB/s
I:\>arc create a -mrep:512m:128+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,249,238,776 bytes. Ratio 27.5%
Compression time: cpu 49.17 secs, real 23.01 secs. Speed 196,931 kB/s
I:\>arc create a -mrep:512m:32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,181,619,756 bytes. Ratio 26.0%
Compression time: cpu 63.34 secs, real 39.06 secs. Speed 115,996 kB/s

в общем, надо
1. сделать rep многопоточным
2. в идеале - найти способ реализовать rep:32 таким же быстрым, как rep:512
3. опционально - интегрировать его в tor:3 (в основном это имеет смысл если удастся сделать быстрый rep:32)
4. добавить в tor:3 пропуск несжимаемых данных
Автор: slech
Дата сообщения: 01.03.2011 13:28

Цитата:
иконки такие потому, что это стандартные иконки из gtk - там есть набор для плеера, для редактора текстов, а вот для арзиватора как-то нету по идее вещей надо делать на платной основе

можешь сформулировать требования для иконок ?
сколько и каких - давай искать платный вариант - сколько такое может стоить ?

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.