» FreeArc (часть 4)

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

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

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

тест на SSD Intel G2 120gb


Код: C:\>read lp2.pcf
Speed 236.023188 mbytes/sec

srep64i -m1 Cpu 154.174 mb/sec, real 146.101 mb/sec

srep64i -m2 Cpu 223.845 mb/sec, real 100.994 mb/sec
srep64i -m2 -nommap Cpu 227.554 mb/sec, real 167.256 mb/sec

srep64i -m3 Cpu 179.942 mb/sec, real 96.754 mb/sec
srep64i -m3 -nommap Cpu 166.436 mb/sec, real 86.298 mb/sec

Bulat_Ziganshin
v14 как-то больше нравится, всё просто и понятно

Shuld

Цитата:

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

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

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

Имхо, самым компактным и удобным вариантом было бы нечто такого типа:

Proceeded:                 58%
Files:               2823/5447
Bytes:       24984984/52046849
Compressed:    4984984/2046849
Ratio:                     72%
Time:        01:02:03/20:22:24

На первом месте - процент обработанного, далее - количество файлов (сделано/всё) и аналогично байты общие и обработанные, после этого логичнее всего показывать процент сжатия, и в конце - время по схеме [прошло/общее] или [прошло/осталось].

Как вариант, можно время разделить:

Обработано: 58%
Файлы: 2823/5447
Всего байт: 24984984/2046849
Сжатых байт: 4984984/2046849
Степень сжатия: 72%
Прошло: 01:02:03
Осталось: 20:22:24

Или даже так...

Proceeded:                 58%    Time:        01:02:03/20:22:24    
Files:               2823/5447    Ratio:                     72%    
Bytes:       24984984/52046849    Compressed:    4984984/2046849    


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

Bulat_Ziganshin

Цитата:

srep64i -m2 Cpu 223.845 mb/sec, real 100.994 mb/sec
srep64i -m2 -nommap Cpu 227.554 mb/sec, real 167.256 mb/sec

что то я не понял, CPU time ниже а real time выше, как так может быть ?

у меня метод m1 на 1 большом файле был самым быстрым
в то время как другие 2 вообще я не смог дождаться (больше 30 минут прошло, а они даже половину не сделали)

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

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

Цитата:

а все эксперименты начну с 3.41

лучше c 3.14

Добавлено:

Цитата:

read

а это что?

Bulat_Ziganshin

Цитата:

Another proposal for idea from v9+v10

как-то не интуитивно получается - "знаменатели" слева от "числителей"
(Speed = Bytes / Time, Ratio = Compressed / Bytes)

Цитата:

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

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

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


Цитата:

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

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

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

Точно, забыл про скорость:

Proceeded:                 58%    Files:               2823/5447    
Compressed:    4984984/2046849    Ratio:                     72%    
Speed:                5204kb/s    Time:        01:02:03/20:22:24    

read - моя утилита читающая файлы с диска. замеряет скорость чтения плюс вбивает файл в кеш, если места хватит

Добавлено:

Цитата:

CPU time ниже а real time выше, как так может быть ?

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


Цитата:

нельзя как то скомбинировать м1 и м3, у них разница в числе чтения в десятки тысяч раз

не хотелось мне это делать до релиза 3.0, но наверно придётся что-то подтянуть

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

insorg
Files:               2823/5447    Proceeded:                 58%    
Bytes:         123456/65432100    Speed/Ratio:    5204kb/s / 72%
Compressed:    4984984/2046849 Time:        01:02:03/20:22:24    

Помогите, пожалуйста. У меня есть скрипт от NFS Undercover v2.2 и я никак не могу понять, как в нём использовать FreeArc. Не могли бы вы описать примерную последовательность действий?

Если кто переводил с русского - там была небольшая ошибка в 1509: "требуют много памяти" вместо "требуют много времени"

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


Цитата:

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

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

Добавлено:

Цитата:

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

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


Цитата:

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

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

Bulat_Ziganshin
можно и так

Percey123
для этого есть же эта тема

можно понизить потребление памяти немного, если вместо sha1 использовать md5
я проверил, файл сжимался обычно с памятью 560мб, а есои подменить тип хеша, то около 490

Лучшие из вариантов (для меня) - 9 и 15.

Самое хорошее было бы взять вариант 15 и сделать изменения:
разместить Speed под Time - и то и то относится к времени
Ratio под Compressed - и то и то относится к размеру файла.

Цитата:

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

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

kalpak
Ясно, спасибо.

Shuld
speed под time не влезет

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}),
}

SREP 2.991 release candidate:

-m3f by default
-m1..-m3 disables future-LZ
-nommap by default, -mmap option
print program version and size of input file before compression
progress indicators (%% processed) for compression and decompression
exchanged compsize and origsize in decompression indicator


This version changes some defaults (-f and -nommap) and displays more info thorough operation

Добавлено:

Цитата:

можно понизить потребление памяти немного, если вместо sha1 использовать md5

ну так sha1 более надёжен. и не стоит редактировать сообщения, я их получаю по email

И, вероятно, строку Total выше, чем Procecced.

Добавлено:
Вообще самая большая сложность с Ratio - он не сразу понятен.

Добавлено:
А если посмотреть на процесс нестандартно?

.................Files........Bytes...............Time
Start...........44.....15 790
Processed....30.....4 800.->.2 258......0:30
Finish............1.........-........8 953.......2:22
-------------------------------------------------
Speed.......8 kb/s
Ratio.........50%


Добавлено:
Взгляд человека начинается слева вверху.
Мне кажется, что в любом варианте исходный размер несжатых данных должен располагаться вверху, и по-возможности левее.
Например, интересен вариант
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1860#13
но строку Total выше, чем Procecced


Добавлено:
В этом смысле варианты 11, 12 мне не нравятсяся совершенно!

Думаю, что может быть красивым вариант 15, если поменять местами
строки Total и Procecced
и Ratio / Speed, чтобы Ratio было под Compressed

Bulat_Ziganshin

Цитата:

-m1..-m3 disables future-LZ

а что это означает?

New alpha version:

Compression memory management: now FreeArc knows that 4x4/grzip may use more or less memory depending on number of threads without losing compatibility with already compressed data. This complicates memory management:On compression, "Memory for compression 747mb, decompression 96mb" message now tells how much memory actually used this time for compression and minimum memory that will be required later for decompression
The Compression Dialog shows the same numbers for standard compression methods
ArcInfo/lt commands show the minimum memory required for compression and decompression of selected archive
On compression, -lc limits memory usage, first adding "tempfile" between methods, then reducing :t:i parameters in 4x4/grzip and finally reducing memory used by each thread
On compression, -ld limits minimum amount of memory that will be required later for decompression (i.e. with "tempfile" between methods and :t1:i0 setting in 4x4/grzip)
On decompression, -ld limits memory usage, first adding "tempfile" between methods, then reducing :t:i parameters in 4x4/grzip; so you can use -ld1 to use as little memory as possible
Decreased memory usage for xlzma decompression by 9%, ppmd compression and decompression by 14 mb per thread
LZMA: -di/lt shows real hash size in :h (it may be smaller than specified in the command because each bucket (:mc) should contain 2^n values)
Fixed lot of bugs and made tons of improvements in compression memory management, now all memory sizes shown should reflect the real memory usage

Other improvements:New layout of the Progress Dialog invented by sabio and ruduk
The Progress Dialog title now is "xx% hh:mm:ss | Command ..." instead of "{xx% hh:mm:ss} Command ..."
i18n: full Portuguese Standard translation by Nuno Rego!
i18n: shortened msgs 0018, 0086, 0433, 0435, 0300, 0437, 0438, 0439, 0440, 0441, 0382, 0383, 0384, 0301, 0302. If you maintain a translation, please try to do the same
7z.dll: more accurate dict/mem calculation for bcj2-compressed archives in the ArcInfo/lt
Unarc/DLL/large SFX: added LZ4 decompression
Unarc.dll: added C# usage example developed by Mohammad Khalifa
LZMA: made lzma:fastest a really fastest set of settings

To do: small improvements in the Progress Dialog, memory management in Tornado and Unarc

egor23
раньше опции -m1..3 и -f действовали независимо - первая переключала метод поиска, вторая включала future-lz. теперь же есть 6 опций -m1..3 и -m1f..3f, которые одновременно выбирают метод поиска и выключают/включают future-lz

разницу можно увидеть например дав опции "-f -m3" старой и новой программам

Выложил свежий тест
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!

Нет ли в тесте существенных неточностей с вашей точки зрения?

Имхо такой вариант удобнее

Цитата:

Files:               2823/5447    Proceeded:                 58%    
Bytes:         123456/65432100    Speed/Ratio:    5204kb/s / 72%
Compressed:    4984984/2046849    Time:        01:02:03/20:22:24

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