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

» FreeArc (часть 4)

Автор: WildGoblin
Дата сообщения: 22.09.2012 12:39
Andrey_Verkhoglyadov

Цитата:
Вы можете сделать это опционально (платно) или не сделать вообще.
Убейся уже, пожалуйста, об стену.

Bulat_Ziganshin

Цитата:
v8
Отлично выглядит!
Строка "Files Bytes Compressed Time" очень упрощает восприятие - взгляд сразу выхватывает нужное.
Автор: Bulat_Ziganshin
Дата сообщения: 26.12.2011 21:18
vasulpr
как запускал?
Автор: ruduk
Дата сообщения: 22.09.2012 13:46
Bulat_Ziganshin
1) Почему бы не пересунуть "Ratio" под столбик "Compressed" для наглядности? Юзер будет видеть примерный ~размер архива (после сжатия) и сразу понимать при какой степени сжатия, (Текст "Ratio" выравнять по первой букве с "Compressed")
2) также для Скорости сжатия нужно сделать подпись, что это "Скорость",
"Скорость" (сам текст) подсунуть под столбик "Files" (выравнять по последней букве)
3) неплохо выглядит также линия, которая отделяет зону диалога прогресса "Files Bytes Compressed Time"
а также спасает от неразберихи оригинального v8: - сверху столбика текст "Bytes", но числа почему-то внизу в "kB/s", но строка начинается "Ratio", со временем можно привыкнуть и понимать что к чему, но когда когда есть линия текст после линии уже читается не так сложно.
Вариант 1:


Вариант 2 без линии:
Автор: kalpak
Дата сообщения: 10.08.2011 18:49
Bulat_Ziganshin
вот я пакую файл
[more=подробнее]
Цитата:
C:\>arc a --cache=16mb -di -i2 -m4x4:lzma:256mb:fast data.arc "D:\Alcohol 120%\X
AKEP_10_82_DVD.md0"
FreeArc 0.67 (November 17 2010) Creating archive: data.arc using 4x4:i0:lzma:256
mb:fast:32
Memory for compression 1410mb, decompression 1154mb, cache 16mb
Compressing 1 file, 365,887,488 bytes
Compressing Alcohol 120%\XAKEP_10_82_DVD.md0
Compressed 1 file, 365,887,488 => 325,278,312 bytes. Ratio 88.9%
Compression time: cpu 366.06 secs, real 329.84 secs. Speed 1,109 kB/s
All OK

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

Цитата:

D:\free_arc067\bin>arc x -ld75% c:\data.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>arc x -ld95p c:\data.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>arc x c:\data.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>
[/more]

в GUI пишет что для упаковк нужно ~2450mb для упаковки и ~2300 для распаковки
[more=рисунок] [/more]
я забыл написать t1 при упаковке, но вот только что сделал с т1 и результат такой же.
[more=подробнее]
Цитата:
C:\>arc a --cache=16mb -di -i2 -m4x4:t1:lzma:256mb:fast data2.arc "D:\Alcohol 12
0%\XAKEP_10_82_DVD.md0"
FreeArc 0.67 (November 17 2010) Creating archive: data2.arc using 4x4:t1:i1:lzma
:256mb:fast:32
Memory for compression 1217mb, decompression 1153mb, cache 16mb
Compressing 1 file, 365,887,488 bytes
Compressing Alcohol 120%\XAKEP_10_82_DVD.md0
Compressed 1 file, 365,887,488 => 325,278,312 bytes. Ratio 88.9%
Compression time: cpu 337.91 secs, real 359.48 secs. Speed 1,018 kB/s
All OK
C:\>

при распаковке

Цитата:
D:\free_arc067\bin>arc x -ld75p c:\data2.arc
FreeArc 0.67 (March 18 2011) extracting archive: c:\data2.arc
Extracting 1 file, 365,887,488 bytes. Processed 0.0%
ERROR: can't allocate memory required for (de)compression in 4x4:lzma:256mb:fast
:32

D:\free_arc067\bin>arc x -ld75p c:\data2.arc
[/more]

только чтот-о я не могу распаковать их unarc, странную ошибку пишет
[more=лог]
Цитата:
D:\>unarc x c:\data2.arc
FreeArc 0.67 unpacker. Extracting archive: data2.arc
Extracting Alcohol 120%\XAKEP_10_82_DVD.md0 (365887488 bytes)

ERROR: archive data corrupted (decompression fails)
D:\>unarc x c:\data.arc
FreeArc 0.67 unpacker. Extracting archive: data.arc
Extracting Alcohol 120%\XAKEP_10_82_DVD.md0 (365887488 bytes)

ERROR: archive data corrupted (decompression fails)
D:\>
[/more]
система: win xp sp2 ram 2gb | core 2 duo e4400
на работе система: win xp sp3 ram 2gb | core i5 650

Цитата:
кстати, пришёл в голову трюк, который возможно способен на порядок ускорить распаковку обычного srep (без -f) когда идёт трешинг диска - считывать матчи параллельно в нескольких десятках потоков. тогда есть надёжда что сработает ncq и мы будем иметь qd=32 or so

а если жесткий диск не поддерживает ncq то что делать ?))
что такое qd=32 or so ?
Автор: vasulpr
Дата сообщения: 26.12.2011 21:23
Bulat_Ziganshin
ПКМ по архиву - распаковать, пока оно розпаковувалося запустил программу с ярлыка выбрал папку, параметр сжатия, нажал ОК. сжатие стало в очередь, закрыл основное окно программы, распаковки закончилось а упаковка не началась, хотя окно упаковки висело.

Добавлено:
Bulat_Ziganshin
Извините за беспокойство! видно я чтото намудрил с параметрами сжатия, что у меня упаковки зависла даже не начавшись, потому что мне сейчас не удалось повторить этот баг. все работает нормально!
Автор: PAQer
Дата сообщения: 22.09.2012 13:49

Цитата:
мне кажется что в процессе архивации сотые интересны только конченым гикам.

А мне кажется что гики тоже люди. А для не совсем конченных гиков, можно и десятые доли выводить.
Фриарк, ведь, для таких маньяков/гиков и разрабатывался, да и кто, если не ты, Булат, что-то сделает для гиков?
Тем более что:

Цитата:
а зачем нормальному пользователю использовать freearc, а не rar/zip?

Автор: MAKLAI1994
Дата сообщения: 27.12.2011 06:47
Здраствуйте подскажити как зделать-распаковку FreArc затем PreComp затем Srep затем 7zip архивов и что бы распакованные архивы удалялись с игровой папки ВОТ Скрипт http://rghost.ru/35622051
Автор: Andrey_Verkhoglyadov
Дата сообщения: 22.09.2012 13:52
WildGoblin
пожалуйста -
Bulat_Ziganshin

Цитата:
v8

красивое решение.
Автор: Stalqer
Дата сообщения: 27.12.2011 18:29
MAKLAI1994

тебе сюда --> http://forum.ru-board.com/topic.cgi?forum=5&topic=36421&start=3020#lt
Автор: Bulat_Ziganshin
Дата сообщения: 10.08.2011 20:26

Цитата:
а если жесткий диск не поддерживает ncq то что делать ?))

тогда он будет работать с прежней скоростью


Цитата:
что такое qd=32 or so ?

or so="или типа того". qd - глубина очереди запросов, если долбить диск из 32 потоков, то qd будет 32 и диск с ncq получит шанс переупорядочить запросы, а диск без ncq просто выполнит их по очереди, как и сейчас


Цитата:
вот я пакую файл

теперь ясно. будем искать

Добавлено:

Цитата:
в GUI пишет что для упаковк нужно ~2450mb

кста на будущее есть команда lt:

[more=подробнее]
Цитата:

C:\Tests> Arc.exe lt ArcShellExt.arc
FreeArc 0.67 (March 18 2011) listing archive: ArcShellExt.arc

Archive type: FreeArc
Total bytes: 965,349
Compressed bytes: 965,350
Ratio: 100.0%

Directory blocks: 1
Directory, bytes: 457
Directory, compressed: 275
Solid blocks: 2
Avg. blocksize: 471 kb

Compression memory: 450 mb
Decompression memory: 450 mb
Dictionary: -

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 0 0 1 storing
31 965,349 965,350 10 paq8px64
-----------------------------------------------------------------------------
11 files, 965,349 bytes, 965,350 compressed
[/more]
Автор: sabio
Дата сообщения: 22.09.2012 14:28
Bulat_Ziganshin
ещё одна вариация с отступлением от "классических канонов" - (v9)

..............Files .... Compressed ........ Bytes ...... Time
Processed ....... 8 ..... 6,229,876 ... 16,188,368 ... 0:00:02
Total .......... 35 .. ~ 51,893,133 .. 134,844,601 . ~ 0:00:17
.............................. | ...... | .. | ............ |
.............................. +- 38 % -+ .. +- 7,970 kB/s -+
................................ Ratio .......... Speed

не совсем логично получается, что Compressed и Bytes переставлены местами
зато Ratio и Speed очень наглядны, кмк

более логичный, но и более громоздкий вариант - (v10)

..............Files ........ Bytes .... Compressed ...... Time
Processed ....... 8 ... 16,188,368 ..... 6,229,876 ... 0:00:02
Total .......... 35 .. 134,844,601 .. ~ 51,893,133 . ~ 0:00:17
.............................. | ............ | ........... |
..................... Ratio .. +---- 38 % ----+ ........... |
..................... Speed .. +--------- 7,970 kB/s -------+
Автор: MAKLAI1994
Дата сообщения: 28.12.2011 12:51
Парни ещё вопрос что нужно зделать в скрипте что бы Сначала Распаковывались файлы bin. а из них уже RAR-SREP-Arc и т.д мне главное что бы все архивы были в файлах bin вот скрипт попробуйте похимичить
http://rghost.ru/35642435
Автор: Shuld
Дата сообщения: 30.12.2011 16:10
Быстрое сжатие больших объемов

«Философия»
Подход к линейке методов сжатия для архиваторов консервативен. Для FreeArca – это методы –m1, -m2, … , -m9 (-mex9). Хочешь быстро – используй –m1, хочешь сильно сжать – используй –m9 (-mex9). Но такая линейка «одномерна» и не очень хороша, поскольку учитывает размер файлов однобоко. Например, нет оптимального метода для «быстрого» сжатия большого объема. Конечно, можно воспользоваться –m1 (-m2), но результат будет далек от идеала. Причина – обработка больших массивов данных заложена только в «старших» (медленных) методах (большой rep). Я вижу выход в «двухмерном» подходе.

От слов к делу
Например, для быстрого сжатия больших объемов можно взять большой rep (от m8, mex8) и быстрый алгоритм (подобный –m2). Под «большими объемами» в таком случае будут пониматься данные размером примерно 1GB (и выше).
Я долго тестировал варианты и предлагаю два «оптимальных». Эти методы по «двухмерной» идеологии я назвал –m81 и –m82. Здесь 8 означает большой объем сжимаемых данных (8rep = rep:1gb), а цифры 1 и 2 – «скоростной» и «быстрый» метод. Деление файлов на группы отсутствует.

Вот результаты сравнения с методами –m2 и –mex8, отсортировано по увеличению реального времени работы:

Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-разрядная, ОЗУ 4 ГБ
Консольная версия FreeArc 0.67 от 25 декабря 2011
Метод time: cpu time: real Размер архива Memory for compression Memory for decompression
Автор: Bulat_Ziganshin
Дата сообщения: 22.09.2012 14:30
все варианты на одной странице со ссылками на загрузку соответствующих freearc.exe: http://freearc.org/download/testing/progress/
Автор: Bulat_Ziganshin
Дата сообщения: 22.09.2012 16:55
ruduk
подретушировал твои варианты и добавил их как v11 и v12 на http://freearc.org/download/testing/progress/



Добавлено:
вариация v8, выводящая Speed справа:

v13 - http://freearc.org/download/testing/progress/FreeArc13.exe :
Автор: Bulat_Ziganshin
Дата сообщения: 30.12.2011 16:16
Shuld
тут есть тег "таблица" (после x2) - может переоформишь с ним?
Автор: kalpak
Дата сообщения: 10.08.2011 21:05
Bulat_Ziganshin
понятно, буду знать )
а вот насчет ошибка распаковки unarc странно, на работе у меня получалось распаковывать
Автор: sabio
Дата сообщения: 22.09.2012 18:29
сделал вот картинки
v9


v10
Автор: Shuld
Дата сообщения: 30.12.2011 16:22
Булат
1. Переоформил
2. Почему при Memory for compression более 1444mb из-под консоли методы сжатия работают без темп-файла, а под оболочкой (GUI) - с темп-файлом (во всяком случае время становится примерно в 2 раза больше)?
Автор: Bulat_Ziganshin
Дата сообщения: 10.08.2011 21:40
SREP 2.99 release candidate:

fixed bug: 32-bit version was unable to decompress large files (>2gb) compressed with -f


btw, i've tested srep on i7-2600k@4.6GHz - compression speed on my files was in 100-200 mb/s range so srep was ALWAYS limited by HDD speed

Добавлено:


and once again: -nommap testing proves that memory-mapped files slow down the SREP when you are short on RAM:


Код: D:\>read lp2.pcf
Speed 84.369956 mbytes/sec

srep64i -m1 Cpu 148.074 mb/sec, real 83.986 mb/sec

srep64i -m2 Cpu 201.726 mb/sec, real 54.300 mb/sec
srep64i -m2 -nommap Cpu 209.772 mb/sec, real 71.276 mb/sec

srep64i -m3 Cpu 155.684 mb/sec, real 40.795 mb/sec
srep64i -m3 -nommap Cpu 157.294 mb/sec, real 57.553 mb/sec

Compression ratio: 22,069,494,174 -> 7,284,431,814: 33.01%
Автор: Bulat_Ziganshin
Дата сообщения: 22.09.2012 18:48
sabio
спасибо, добавил на http://freearc.org/download/testing/progress/

Добавлено:
v14:
Автор: vishyakov
Дата сообщения: 30.12.2011 17:32
Если сжимаешь первый раз, то время 140 с. При повторных сжатиях – около 25 с.

Очевидно, "при повторных сжатиях" файлы брались из системного кэша.
Автор: Bulat_Ziganshin
Дата сообщения: 23.09.2012 13:33
Another proposal for idea from v9+v10 in text:

..............Files......Time............Bytes.... .Compressed..
Processed ........8.....0:00:02.......16,188,368.....6,229,876..
Total ...........35...~ 0:00:17......134,844,601..~ 51,893,133..
..........................|..............|....|... ....|........
..........................+- 7,970 kB/s -+....+- 38 % -+........
...............................Speed .......... Ratio...........

Автор: egor23
Дата сообщения: 10.08.2011 23:31
Bulat_Ziganshin

Цитата:
tested srep on i7-2600k@4.6GHz

главное не указали, кол-во RAM
Автор: Shuld
Дата сообщения: 30.12.2011 18:07
Что это значит?
Это же не ОЗУ, в чем разница?
(Все ОЗУ 2 ГБ, причем архиватор использует почти 1,5 ГБ)
Автор: Andarin
Дата сообщения: 23.09.2012 15:05
Всё это субъективно, но мне больше всего нравятся v13 (или v12)
Автор: Engaged Clown
Дата сообщения: 10.08.2011 23:35
16 Gb.
Автор: egor23
Дата сообщения: 30.12.2011 18:08
Shuld

Цитата:
В методе –m1 по времени стоят вопросы из-за совсем странного (для меня) поведения. Если сжимаешь первый раз, то время 140 с. При повторных сжатиях – около 25 с.


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

используйте ram-drive, тогда не будет узкого места ввиде диска, для быстрых методов
и будет минимизировано разница между первым и последующим тестами на одном наборе данных.
Автор: Bulat_Ziganshin
Дата сообщения: 23.09.2012 15:30
v15 - http://freearc.org/download/testing/progress/FreeArc15.exe :



это v11 с Ratio и Speed в обратном порядке. я думаю что мне надо центрировать Speed/Ratio в последней строке, отказавшись от какого-либо выравнивания с числами над разделителем. и возможно добавить ETA (время завершения операции) в самом конце - это очень удобно для длительных операций

Добавлено на http://freearc.org/download/testing/progress/
Автор: Bulat_Ziganshin
Дата сообщения: 11.08.2011 01:11
ага, но 5 гиг рамдиском занято

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

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


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