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

» FreeArc (часть 4)

Автор: Fossius
Дата сообщения: 10.11.2013 11:25

Цитата:
А меня, например, ни чуть не смущает условная нумерация версий этого замечательного архиватора.

Дело не в нумерации, а в функционале. Был бы нормальный гуи с drag'n'drop, уже было бы значительно лучше, и кстати способствовало бы широкому распостранению архиватора. Булат, может напишешь в чём загвоздка? А мы чем сможем тем поможем.
Автор: Highpass
Дата сообщения: 12.11.2013 00:28
Вот это да, нам раскрыли глаза... Оказывается функционал заключается в GUI с drag'n'drop.
А мы то дурачки радуемся фильтру dispack, матчфайндеру ht4, возможности снижать потребление памяти при использовании внутренних алгоритмов путем указания tempfile в цепочке....
Автор: Bulat_Ziganshin
Дата сообщения: 12.11.2013 05:11
Новая альфа-версия:добавлен Win7-индикатор прогресса в таскбаре в Arc.exe, FreeArc.exe и GUI SFX модулях

Комстрока:поддержка множественных конфиг-файлов, по умолчанию arc*.ini (файлы с теми же именами в более приоритетных каталогах перекрывают файлы из менее приоритетных кталогов)
в листфайлах поддерживаются rar-совместиые комментарии - строки начинающиеся с "//"
удаляются элементы пути ".." и "." из имён файлов в архиве (при упаковке, распаковке и при распаковке в unarc/sfx/dll)
исправлена ошибка при обработке опций типа -s1e, добавлено сообщение об ошибке при некорректно заданной опции -s

Сжатие:метод lz4b переименован в lz4, так что это будет окончательной реализацией алгоритма LZ4
REP с большими :l/:c стал до 2 раз быстрее (для хеширования используются все ядра CPU)
-m4b -mt2 теперь основан на lzma (раньше - xlzma)
LZMA-x64/LZMA-x86 и facompress*.dll откомпилированы в Visual C++ 2013

Внешний вид:степень сжатия вычисляется с 4 цифрами и округляется: "12.34%"; скорости - в mB/s
после выполнения команды "freeearc a -t" окно программы не зщакрывается автоматически
MultiArc: плагин к Total Commander теперь везде использует ANSI-кодировку имён файлов




New alpha version:new translations: Bulgarian, Finnish and Malay for a total of 22 languages
added Win7 taskbar progress indicator to Arc.exe, FreeArc.exe and GUI SFX modules

Cmdline:support for multiple configuration files, default arc*.ini (files with the same names in higher-priority dirs override files from lower-priority dirs)
accept RAR-like "//" comments in listfiles
remove ".." and "." entries from filenames stored in archive (on compression, extraction and in unarc/sfx/dll)
fixed bug in processing option -s1e, added error message on incorrect solid grouping specifier

Compression:lz4b method renamed to lz4, so it will be final implementation of LZ4 algo
REP with large :l/:c made up to 2x faster (use all CPU cores for hashing)
use lzma instead of xlzma for -m4b -mt2
LZMA-x64/LZMA-x86 and facompress*.dll compiled with Visual C++ 2013

UI:show compression ratios with 4 digits and rounded: "12.34%"; show speeds in mB/s
don't close program window after execution of "freeearc a -t" command
MultiArc: updated Total Commander plugin to use ANSI codepage everywhere

Автор: Skif_off
Дата сообщения: 12.11.2013 10:14
Bulat_Ziganshin

Цитата:
MultiArc: плагин к Total Commander теперь везде использует ANSI-кодировку имён файлов

Т.е. в файле freearc.addon UTF-8 исправлено на ANSI и все?
Автор: Bulat_Ziganshin
Дата сообщения: 12.11.2013 10:36
Skif_off
да. так что в русской винде с новым addon русские имена файлов в архиве должны полностью поддерживаться. а в какой-нибудь литовской - соответственно литовские


Цитата:
drag'n'drop

я считаю что это самый большой недостаток нынешнего GUI. но в gk2hs его поддержки нет вообще, а на уровне gtk что-то наполовину сделанное, насколько я помню
Автор: sabio
Дата сообщения: 18.11.2013 11:02
FYI
Как пропатчить 32-битную WinXP, чтобы получить доступ к 4+ ГБ памяти - http://habrahabr.ru/post/202406/
Автор: Benchmark
Дата сообщения: 18.11.2013 15:10
Bulat_Ziganshin

Цитата:
я считаю что это самый большой недостаток нынешнего GUI. но в gk2hs его поддержки нет вообще, а на уровне gtk что-то наполовину сделанное, насколько я помню

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

Если бы существовала отдельная фриарковская библиотека (по аналогии с 7zip), её бы уже давно добавили в утилиты вроде PeaZip, PowerArchiver и т.д., т.е. в отлаженные и "вылизанные" полнофункциональные GUI.


Цитата:
FreeArc 0.70

FreeArc 0.70 is expected to be released in October.

Булат, ну хоть укажи, в октябре какого года

sabio

Цитата:
Как пропатчить 32-битную WinXP, чтобы получить доступ к 4+ ГБ памяти


Там в выводах прекрасное:

Цитата:
Примечание 1. Поскольку в методике используется dll из первого сервиспака, есть вероятность, что в ней имеются какие-либо уязвимости, закрытые последующими сервиспаками. Я не изучал этот вопрос.

Со времен SP1 закрыта тонна уязвимостей.

Цитата:
Примечание 2. Некоторые драйверы в пропатченой Windows XP могут вызывать BSOD. Впрочем, их крайне мало в природе.

Боюсь, автор понятия не имеет, сколько в природе таких драйверов и, главное, где и когда они могут встретиться.

Цитата:
Примечание 3. В первоисточнике ценных знаний сообщают, что на некоторых системах имеются проблемы с USB при использовании данной методики.

Следствие из п.2 - можно поиметь проблемы с новым драйвером или железом в любой момент и даже не сразу понять, в чем причина BSOD'ов.

Короче, методика для экстремалов. Проще поставить Win2k3 Server, если уж так хочется сидеть на старой 32-битной системе и использовать 4+ Гб памяти.
Автор: Skif_off
Дата сообщения: 18.11.2013 16:39
Benchmark

Цитата:
Боюсь, автор понятия не имеет, сколько в природе таких драйверов и, главное, где и когда они могут встретиться.

ЕМНИП, Intel'овские видео и/или сетевые не дружат с PAE.

Цитата:
Если бы существовала отдельная фриарковская библиотека (по аналогии с 7zip)

Для распаковки есть unarc.dll (unarc.exe?), а с упаковкой - с трудом представляю, как уложить в один-два файла (как в 7z):
минимум arc.exe, arc.groups, arc.ini
+ facompress.dll и facompress_mt.dll для скорости/многопотока
+ минимум srep.exe и precomp042.exe (необязательно, если вычеркнуть –m5p..–m9p)
Автор: Bulat_Ziganshin
Дата сообщения: 20.11.2013 22:05
C:\>fazip.exe lzma:3g:max:hc4:a0 z:\4g z:\4g-lzma3g
100%: 4,531,060,447 -> 868,432,143: 19.17% Cpu 3 mb/s (1637.667 sec), real 3 mb/s (1646.831 sec) = 99%

C:\>fazip.exe lzma:2g:max:hc4:a0 z:\4g z:\4g-lzma2g
100%: 4,531,060,447 -> 877,949,487: 19.38% Cpu 3 mb/s (1367.396 sec), real 3 mb/s (1375.032 sec) = 99%

C:\>fazip.exe lzma:1g:max:hc4:a0 z:\4g z:\4g-lzma1g
100%: 4,531,060,447 -> 889,336,360: 19.63% Cpu 3 mb/s (1262.235 sec), real 3 mb/s (1268.332 sec) = 100%

this means that support of dictionaries up to 4GB was in LZMA code for a years (i just removed a few checks). unfortunately, it's limited to hc4 and a0, making it pretty useless. decompression works fine and restored files are byte-identical
Автор: Bulat_Ziganshin
Дата сообщения: 22.11.2013 11:57
LZMA is fine. it was problems of my HT4-enabled code. i'm going to fix it. the only real LZMA problem is dictionary >=2GB wiith BT4


Код: C:\>fazip.exe lzma:max:2000m:ht4 z:\4g m:\1200
dict=2000mb: buf=2252mb head=1536mb son=0mb
100%: 4,531,060,447 -> 805,786,088: 17.78% Cpu 2 mb/s (2216.774 sec), real 3 mb/s (1683.414 sec) = 132%

C:\>fazip.exe lzma:max:2000m:ht4:h3g z:\4g m:\1200
dict=2000mb: buf=2252mb head=3072mb son=0mb
100%: 4,531,060,447 -> 805,196,672: 17.77% Cpu 2 mb/s (2003.989 sec), real 3 mb/s (1482.672 sec) = 135%

C:\>fazip.exe lzma:max:2000m:ht4:h4095m:mc240 z:\4g m:\1200
dict=2000mb: buf=2252mb head=3840mb son=0mb
100%: 4,531,060,447 -> 797,307,062: 17.60% Cpu 1 mb/s (6574.428 sec), real 1 mb/s (5963.810 sec) = 110%

C:\>fazip.exe lzma:max:2000m:hc4 z:\4g m:\1200
dict=2000mb: buf=2502mb head=1024mb son=8000mb
100%: 4,531,060,447 -> 805,324,025: 17.77% Cpu 1 mb/s (4527.274 sec), real 1 mb/s (3902.200 sec) = 116%


C:\>fazip.exe lzma:max:2000m:bt4 z:\4g m:\1200
dict=2000mb: buf=3002mb head=1024mb son=16000mb
100%: 4,531,060,447 -> 789,564,045: 17.43% Cpu 2 mb/s (2162.330 sec), real 3 mb/s (1559.318 sec) = 139%

C:\>fazip.exe d m:\1200 m:\4g
100%: 789,564,045 -> 4,531,060,447: 17.43% Cpu 104 mb/s (41.418 sec), real 99 mb/s (43.568 sec) = 95%

C:\>fc /b Z:\4g m:\4g
Comparing files Z:\4g and M:\4G
FC: no differences encountered
Автор: Andarin
Дата сообщения: 22.11.2013 12:59
Bulat_Ziganshin, а как же правила форума глава VI Соглашения по использованию?
Автор: Bulat_Ziganshin
Дата сообщения: 22.11.2013 13:36
вариантов два - или я выкладываю как есть, или кто-то берёт с английского форума и переводит. тебя кстати действительно так интересует то чем я занимаюсь? пока я получил всего два отклика и оба на английском форуме
Автор: Andarin
Дата сообщения: 22.11.2013 16:32
Bulat_Ziganshin
Просто я полагаю, Вы английский знаете весьма неплохо, русский тоже; под тэгом "код" перевод по определению не полагается, а перевести 4,5 строки (и 2 строки в предыдущем сообщении) Вам никаких затруднений не составило бы (что подтверждает сообщение о новой альфа-версии на странице до этой)
Цитата:
тебя кстати действительно так интересует то чем я занимаюсь?
Что до этого - меня больше интересует результат, в подробности вдаваться - это свыше моих возможностей (да и потребностей). Ну, а раз я регулярно слежу за этой темой, получается, что FreeArc меня интересует достаточно, чтобы держать его в числе трёх используемых (и вообще установленных) архиваторов.
Цитата:
пока я получил всего два отклика и оба на английском форуме
Лично у меня знания английского не хватает, чтобы читать англоязычные форумы (в случае необходимости приходится всё же иногда пользоваться словарём, когда надо понять побольше абзаца-двух)

P.S. Bulat, я это не на предмет потроллить, и не из желания просто докопаться (меня эти два момента, мягко выражаясь, просто бесят). Просто есть люди, которые в английском вообще ни бум-бум, в т. ч. и у меня такие знакомые есть, но которых интересует многое,что вроде их и интересовать не должно.
Sorry, если задело.
Автор: Bulat_Ziganshin
Дата сообщения: 22.11.2013 22:48
Andarin
вот когда такие люди появятся и меня попросят, я и рассмотрю возможность тратить время на перевод для них, будет ли он окупаться. перевод ни для кого очевидно не окупится. и мне регулярно пишут десятки людей, которые уверены что меня не затруднит срочно добавить ту или иную фичу, которая понадобилась лично им. а ты так сказать вышел на следующий уровень
Автор: slech
Дата сообщения: 23.11.2013 08:18
для всех лентяев на первых порах можно наверное вот такое решение внедрить

http://translate.google.com/translate?sl=en&tl=ru&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fforum.ru-board.com%2Ftopic.cgi%3Fforum%3D5%26topic%3D35164%26start%3D2460%232&act=url
Автор: Andarin
Дата сообщения: 23.11.2013 09:32
slech
Такой перевод, IMHO, надо ещё на нормальный русский переводить. Хотя, для лентяев, может и пойдёт. Но, опять же, им на фиг не надо это даже и на русском. А кому надо, кто этим серьёзно занимается - и без перевода понимают.
Автор: slech
Дата сообщения: 23.11.2013 14:25
Andarin что вы лентяй, что Bulat_Ziganshin лентяй.
Он запостит ссылку, кому нужно прочитает такой перевод
Хоть какое-то временное решение вопроса.
Автор: slech
Дата сообщения: 29.11.2013 18:58
Булат, вы как-то писали про Qt:

Цитата:
это будет разработка gui с самого начала.я имею в виду написание программы, конечно сами идеи его организации мы можем переиспользовать


Цитата:
а я бы купил программу, где это легко настраивается и есть возможность загрузить с сайта программы готовые скины с различными вариантами настройки. я присматриваюсь qt quick, где такая возможность есть, но к сожалению дела, дела..


Не думали над этим вопросом подробнее ?
Автор: slech
Дата сообщения: 01.12.2013 16:33
Bulat_Ziganshin, ещё вопрос возник:
Можно ли приостановить на время задачу которая выполняется в фоне ?
Автор: RandRover
Дата сообщения: 08.12.2013 19:10

Цитата:
что Bulat_Ziganshin лентяй


Уважаемый, если бы вы хоть одну из собственноручно написаных фриварных программ с исходниками от 5000 тыс. строк мейнтейнили на протяжении более 1 года, вы бы не только обленились, у вас также начались бы периоды жуткой прокрастинации и устойчивое желание всех юзеров с просьбами о добавлении еще одной фичи в программу, сразу слать прямым текстом к "такой-то бабушке"...
И, судя по резковатым ответам автора в топике, он скоро вообще даже перестанет отвечать на вопросы по работе программы...
И писать здесь упреки типа, "октябрь уже давно прошел, а новой версии всё нету..." - бесполезно и глупо, так как у автора уже давно прошел тот период, когда с энтузиазмом бежишь кодить только из-за того, что в прошлом месяце твою программу уже скачало более 100 человек и несколько из них даже написали в комментах на странице скачки, что "прога - нормуль"...

И еще информация для размышления: а вы не задумывались хоть на минуточку, что FreeArc - это единственный БЕСПЛАТНЫЙ (в отличии от ВинРАРа) архиватор с собственным форматом, в котором реализован функционал добавления информации для восстановления к архивам? А это значит, что он является прямым конкурентом для платного аналога, и вполне возможно даже, что Женя Рошал "отстегивает" автору какую-то фиксированную суму для того, чтобы автор подольше "тянул резину" с написанием удобного ГУЯ, добавлением новых фич и выпуском новых стабильных версий архиватора. (да-да, понимаю, что такая версия бредовенькая, хотя... )

Короче, если хотите побыстрее узреть новый удобный ГУЙ и добавленые фичи в новой версии FreeArc, то ускорить появление оных можно только двумя способами - либо активно донатить разработку либо брать сорцы и добавлять фичи и ГУЙ самим.

Автор: slech
Дата сообщения: 08.12.2013 21:11
RandRover

Цитата:
Уважаемый, если бы вы хоть одну из собственноручно написаных фриварных программ с исходниками от 5000 тыс. строк мейнтейнили на протяжении более 1 года, вы бы не только обленились, у вас также начались бы периоды жуткой прокрастинации и устойчивое желание всех юзеров с просьбами о добавлении еще одной фичи в программу, сразу слать прямым текстом к "такой-то бабушке"...

Это ни в коем не упрёк Булату. Ну не хочет - не делает, а ленится он или времени нет или нехочет возможно не принципиально.


Цитата:
Короче, если хотите побыстрее узреть новый удобный ГУЙ и добавленые фичи в новой версии FreeArc, то ускорить появление оных можно только двумя способами - либо активно донатить разработку либо брать сорцы и добавлять фичи и ГУЙ самим.

У меня сложилось впечатление, что Булата больше интересуют технические вещи, чем реализация задач для пользователей. Каждому нравится своё и это здорово.

Значит нужно оформить Т.З. и определить стоимость проекта.
Собрать средства и найти разработчика.

Возможно как-то так.
Автор: Engaged Clown
Дата сообщения: 08.12.2013 22:26
slech

Цитата:
Значит нужно оформить Т.З. и определить стоимость проекта.
Собрать средства и найти разработчика.

KickStarter, но гуй на GTK всё убивает.
Автор: Bulat_Ziganshin
Дата сообщения: 09.12.2013 13:10
http://encode.ru/threads/1838-Command-Line-Process-Profiling-Tool?p=35675#post35675 это типа timer.exe/consmeter но гораздо круче. пока он работает над прогой, можно попытаться передать через меня ему пожелания, если вы не можете там зарегиться и/или не знаете английского. для меня прога просто супер, вот пара примеров её работы (она выводит только выделенные жирным шрифтом строки):


C:\Base\Tools\Utils>ProcProfile64.exe -tb rar -inul a m:\aaa z:\1g

1,000,001,799 -> 296,995,091: 29.69%. Cpu 8 mb/s (116.860 sec), real 44 mb/s (21.670 sec) = 539%


C:\Base\Tools\Utils>ProcProfile64.exe -tb 7z a m:\aaa ProcProfile64.exe >nul

93,696 -> 37,706: 40.24%. Cpu 1475 kb/s (0.062 sec), real 1946 kb/s (0.047 sec) = 131%


C:\Base\Tools\Utils>ProcProfile64.exe -tb 7z a m:\aaa z:\1g

7-Zip [64] 9.32 alpha Copyright (c) 1999-2013 Igor Pavlov 2013-12-01
Scanning

Creating archive m:\aaa.7z

Compressing 1g

Everything is Ok

Kernel Time = 1.107 = 1%
User Time = 378.458 = 657%
Process Time = 379.566 = 659% Virtual Memory = 1178 MB
Global Time = 57.534 = 100% Physical Memory = 1008 MB

1,000,000,000 -> 261,801,487: 26.18%. Cpu 2572 kb/s (379.565 sec), real 16 mb/s (57.539 sec) = 659%
Автор: Edison007007
Дата сообщения: 09.12.2013 18:57
Булат, если использовать внешний компрессор внутри FA, то различаются показания у ProcProfile_x86_1.3.1 и arc.exe (12.12.12)

ProcProfile32 -k -tb arc.exe a -r -ep1 -ds=ens -s=; -lc- -di=ecwftsm -i1 --logfile=freearc.log --append -wE:\FreeArcTempDir -m=precomp "1.arc" "TestDATA\*"

Compressed 1 file, 201,152,043 => 239,227,035 bytes. Ratio 118.9%
Compression time: cpu 1.42 secs, real 384.19 secs. Speed 524 kB/s

468,427,026 -> 440,379,740: 94.01%. Cpu 156821 kb/s (2.917 sec), real 1190 kb/s (384.284 sec) = 0%
Автор: Shegorat
Дата сообщения: 09.12.2013 20:08
Edison007007 20:57 09-12-2013
Цитата:
Булат, если использовать внешний компрессор внутри FA, то различаются показания у ProcProfile_x86_1.3.1 и arc.exe (12.12.12)

Думаю, ProcProfile учитывает все операция чтения-записи. Так что нужно учитывать, что FA сначала копирует данные в темп-файл, потом этот темп-файл обрабатывает прекомпом в другой темп-файл и уже его копирует в архив.
Автор: Bulat_Ziganshin
Дата сообщения: 11.12.2013 19:33
FAZip 0.3 это пофайловый упаковщик (аналогично gzip/bzip2), поддерживающий все алгоритмы сжатия FreeArc, включая CLS dll-ки, 4x4 и цепочки методов (например rep:512m+delta+4x4:lzma). Однако, у него нет развитого набора опций и сохранения контрольных сумм в сжатом файле, так что пока я не могу рекомендовать использовать его как замену вышеупомянутым программам.

FAZip может быть интересен для бенчмаркинга и поиска ошибок в алгоритмах сжатия FreeArc, и как внешний упаковщик, заменяющий встроенные в FreeArc алгоритмы. Включенный в поставку файл arc-fazip.ini показывает как использовать FAZip чтобы полностью заменить встроенные алгоритмы LZMA и REP, сохраняя полную совместимость по данным (т.е. данные, сжатые FAZip, будут распаковываться встроенными алгоритмами, и наоборот).

FAZip заменяет FreeArc-LZMA-x64.exe, Delta.exe и другие упаковщики, откомпилированные из библиотеки сжатия FreeArc.

Что новенького:Windows: 32-битный exe и facompress*.dll откомпилированы ICL 2011
Windows: 64-битный exe откомпилирован MSVC 2013
Linux: 32/64-битные динамически/статически-слинкованные программы откомпилированы GCC 4.6.3 под Ubuntu 12.04 (отсутствует поддержка CLS)
работает с чистым потоком сжатых данных при использовании синтаксиса "compress:метод" и "decompress:метод" (используется в arc-fazip.ini)
автоматически использует все ядра ЦПУ, но не уменьшает отывчивость системы
отображает зелёненький индикатор прогресса в таскбаре Win7
по умолчанию: использует большие страницы памяти (2МБ/4МБ) если они доступны; -slp-: никогда их не использовать; -slp+: использовать только их, при недоступности/нехватке выходить с ошибкой (ага, для бенчмарков)
опция -i0 отключает вывод программы (хотя сообщения об ошибках и ^Break всё же печатаются)
обновляет индикатор прогресса не чаще раза в 0.2 секунды (иначе на это может уходить слишком много времени)
печатает "\n" перед выходом и выдаёт расшифровки сообщений об ошибке вместо их цифровых кодов
удаляет частично созданный выходной файл при выходе по Ctrl-Break или ошибке

LZMA:словарь до 2 ГБ в BT4, до 4000 МБ в HT4/HC4
улучшено сжатие со словарём в 1 ГБ
предвыборка памяти в BT4/HT4 - до 20% быстрее
по умолчанию MaxChain (:mc) в HT4 теперь равен FastBytes/2 (:fb/2)

Другие алгоритмы:FAZip поддерживает все алгоритмы FreeArc, включая "tempfile" и cls-*.dll, за исключением только внешних алгоритмов, определяемых в arc.ini
64-битные версии алгоритмов ppmd/grzip/tta на самом деле пока не работают
REP: стал до 2 раз быстрее при больших :l/:c (потому что для хеширования теперь используются все ядра ЦПУ)
Delta: стало в 1.7 раз быстрее


Планы на будущие версии FAZip, в порядке приоритета:32/64-битные версии, откомпилированные MSVC 2010/2012/2013, ICL 2011/2013/2014 и GCC 4.8
подробное описание использования и параметров каждого алгоритма сжатия
полноценный формат сжатых файлов - с идентификатором формата и контрольной суммой
64-битные версии ppmd/grzip/tta
значительное ускорение HT4/BT4 (хотя при этом мы упрёмся в другую часть LZMA - Оптимальный Парсер)
упереть драйвер командной строки из bzip2 или tornado - где хуже лежит
64-битный MemSize (lzma:h4g)
не выводить сообщений об ошибках при -i0?





FAZip 0.3 is a single-file compression utility (like gzip/bzip2), that supports all
the FreeArc compression algorithms, including CLS dlls, 4x4, and method chaining
(like rep:512m+delta+4x4:lzma). It lacks feature-rich command line and data checksums,
though, so i can't yet recommend to use it as general-purpose compressor.

FAZip may be useful for benchmarking and bug-hunting FreeArc compression algorithms,
and as external compressor replacing built-in FreeArc methods. The provided arc-fazip.ini
demonstrates how to use FAZip to completely replace built-in LZMA and REP algorithms
while retaining full data format compatiblity (i.e data compressed by FAZip may be extracted
by built-in methods and vice versa).

FAZip replaces FreeArc-LZMA-x64.exe, Delta.exe and other standalone compression tools
compiled from the FreeArc library.

What's new:Windows: 32-bit executable and facompress*.dll compiled by ICL 2011
Windows: 64-bit executable compiled by MSVC 2013
Linux: 32/64-bit dynamic/static-linked executables produced by GCC 4.6.3 on Ubuntu 12.04 (no CLS support)
raw compressed stream produced by "compress:method" and extracted by "decompress:method" syntax (employed by arc-fazip.ini)
automatically employs all cpu cores, while keeping the computer responsive
Win7 taskbar progress indicator (the green bar)
default: use Large Memory Pages (2MB/4MB) if possible; -slp-: never use LP; -slp+: use only LP, abort if there aren't enough LP available (just for benchmarking)
-i0 option disables program output (although error/^Break messages are still displayed)
updates progress indicator only once per 0.2 seconds (otherwise it may need too much time)
prints "\n" before exiting and shows error descriptions instead of numeric codes
removes unfinished outfile on Ctrl-Break or error

LZMA:dictionary up to 2 gb in BT4, up to 4000 mb in HT4/HC4
improved compression with 1 GB dictionary
prefetching in BT4/HT4 matchfinders - up to 20% faster
default MaxChain (:mc) for HT4 now is FastBytes/2 (:fb/2)

Other compressors:FAZip supports all FreeArc algorithms, including "tempfile" and cls-*.dll, except only of external compressors defined in arc*.ini
64-bit versions of ppmd/grzip/tta don't really work yet
REP: made up to 2x faster with large :l/:c (since now it uses all CPU cores for hashing)
Delta: made 1.7x faster


Plans for future FAZip versions, in order of priority:32/64-bit executables compiled by MSVC 2010/2012/2013, ICL 2011/2013/2014 and GCC 4.8
document usage and parameters for all compression algorithms
compressed file format with fileid and checksum
64-bit versions of ppmd/grzip/tta
much faster HT4/BT4 matchfinders (so that LZMA speed will be limited only by the Optimal Parser)
steal cmdline processing from bzip2 or tornado
64-bit MemSize (lzma:h4g)
no error messages on -i0?

Автор: 0Vovan0
Дата сообщения: 23.12.2013 01:17
Когда-то давно здесь http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=780#2 обсуждалась распаковка архивов, которые воспринимаются арком как запароленные, хотя на самом деле распаковываются unarc.dll без пароля. Я попробовал с помощью UnarcDllExample.exe распаковать такой архив, но он все равно требует пароль. Как определить точно архив ли запаролен или распаковка почему-то происходит неправильно? Пример архива - например тут http://rutor.org/torrent/276813/arx-fatalis-zolotoe-izdanie_arx-fatalis-gold-edition-2002-2007-pc-repack-ot-r.g-mehaniki
Автор: Shuld
Дата сообщения: 06.01.2014 08:13
Bulat_Ziganshin

Прошу комментарий.
Проводил тесты и столкнулся с таким моментом.

При архивировании командой (-m89)
rep:734mb+4x4:lzma:128mb:h128mb:normal:bt4:128
получается архив размером 338 695 222 байта (4 м 48 с)
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#9

Но в одном случае я ошибся, у меня была запущена программа, и памяти не хватило.
Архиватор заменил метод на строку:
rep:734mb+4x4:b350mb:lzma:69mb:normal:bt4:128
и получился архив размером 337 769 101 байт, заметно меньше. Время архивирования было не намного больше (5 м 13 с).

Вопрос:
Размер словаря lzma стал меньше, в чем возможная причина уменьшения архива?
Какой стандартный параметр "b" у 4x4? Или он меняется?
Автор: Bulat_Ziganshin
Дата сообщения: 06.01.2014 20:02
параметр 4x4:b определяет размер блоков, на которые разбиваются входные данные (каждый блок сжимается независимо адгоритмом описанным внутри 4x4). по умолчанию размер блока равен размеру словаря во внутреннем алгоритме, т.е. для 4x4:lzma:128mb этот блок будет 128 мб.

у тебя после "урезания" размер блока увеличился с 128 до 350 мб что ес-но увеличило сжатие. я сейчас посмотрел исходники - размер блока затрагивается только если памяти не хватает даже на одну копию алгоритма внутри 4x4 и ес-но он при этом должен уменьшаться, т.е. в данном случае ты столкнулся с ошибкой в моём алгоритме "обрезания". я её записал
Автор: Shuld
Дата сообщения: 07.01.2014 08:17
Есть смысл посмотреть и сравнить
4x4:b128mb:lzma:128mb
4x4:b256mb:lzma:128mb
4x4:b512mb:lzma:128mb
?

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

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


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