» FreeArc (часть 4)

AftarJjet

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

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

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

AftarJjet

Цитата:

Нет ли связи в связи с тем, что разработчик из мусульманской страны, и релизом 666? Нет ли тут скрытого намека всех христианским странам?

Ты о чём? Вроде первое апреля давненько было или у тебя в часах-календаре двух камней не хватает? Дак ты попроси - аж с Тау Кита самые каменные пришлют.

А вообще-то поинтересуйся-ка ты той же Git/SVN/Subversion что сиё за зверь и с чем его едят и вопрос мигом испарится в сторону нетей.... Коминты и распишитесь - хотите придумывайте благозвучные "цыфыры" для версий, хотите нумеруйте версии по ревизиям сорцов, хотите очи к небу и высматривайте там знамения с "цыфырами" - тут каждый разработчик поступает как ему Бог на душу положит. А нечистую силу оставь в покое, а то ненарок накличешь дак спать своими воплями не даст - работа у неё такая...

Shuld

Цитата:

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

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


Цитата:

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

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

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

чем лучше FreeArc 7zip-a?

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

Цитата:

Нет ли связи в связи с тем, что разработчик из мусульманской страны, и релизом 666? Нет ли тут скрытого намека всех христианским странам?

по такой логике, следующую версию надо назвать 0.69


Цитата:

чем лучше?

чем 7-zip!

Цитата:

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

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


Цитата:

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

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


Цитата:

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

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

Цитата:

чем лучше FreeArc 7zip-a?

http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=800#5

Цитата:

он прикручен

x86

redson 13:09 11-05-2013
Цитата:

чем лучше FreeArc 7zip-a?

Наличием человеческого GUI и фич, напрочь отсутствующих в 7-zip. Объясняется различиями в подходе у авторов - автора 7-zip кроме алгоритмов сжатия ничего не интересует, автор Freearc думает и об удобстве юзеров.

К сожалению, все плюсы Freearc перечеркиваются его слабой распространенностью.

Цитата:

x86

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

Поднимаю вопрос про cabal и спокойную сборку на linux

http://www.linux.org.ru/forum/general/7894692
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1620#3

Цитата:

x86

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

эх добавили бы еще поддержку расширенных атрибутов NTFS

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

Bulat_Ziganshin
можно на офсайте повесить ожидаемую дату релиза?

Benchmark

Цитата:

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

Универсальной зависимости нет. А пользователи, скорее всего, даже не догадаются поэкспериментировать.
Вот, например,
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=840#2
Zcm080 (-t1) – 3 m 22 s, 140 858 897 – загрузка процессора 25 %
Zcm080 (-t2) – 2 m 49 s, 195 288 141 – загрузка процессора 75 %
Zcm080 (-t3) – 2 m 33 s, 234 349 823 – загрузка процессора 100 %
Zcm080 (-t4) – 2 m 36 s, 268 775 356 – загрузка процессора 100 %
Как видите, разница вовсе не проценты, а время вовсе не пропорционально количеству потоков!
Какой здесь будет вывод?
(Мой вывод - кроме (-t1) - все остальное неудачно).
И такая ситуация, возможно, бывает чаще, чем та, которую Вы обрисовали. (никто же экспериментирует!)


Цитата:

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

А для 7zip 9.30a, словарь 1024 МБ, потоков 8, нужно 46 ГБ + запас!
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#10

Для rep из FreeArc на машине с ОЗУ 4 ГБ не реализуется 2 Гб!
А как было бы хорошо при сжатии огромных данных, например, rep 8 ГБ + tor.
---
Так что, на мой взгляд, 4 ГБ очень немного.

Добавлено:
Внес исправления.

Цитата:

можно на офсайте повесить ожидаемую дату релиза?

о, это слишком далёкое будущее. вот увидиш дату и расстроишся, от того что врят ли дожить до неё получится.

Если warc пишет:
Для установки этой программы необходима библиотека .NET Framework версии 2.0. Пожалуйста установите .NET Framework и повторите попытку снова.
или
This setup requires the .NET Framework version 2.0. Please install the .NET Framework and run this setup again.
и при этом .NET 2.0 установлен

достаточно в дистрибутиве warc_setup_1.0.exe md5 2697210b512bbecac39ef0fe5fbe99bf
HEX редактором поменять байт по адресу 00015979 с 84 на 85.

Или на время установки программы удалить в разделе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy все разделы старше v2.0: v3.0 v4.0.... А потом восстановить заранее экспортированную ветвь.

Цитата:

А для 7zip 9.30a, словарь 1024 МБ, потоков 8, нужно 46 ГБ + запас!

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

И при этом никак не разберусь с командной строкой
Подскажите, такая запись корректна?
"%ProgramFiles%\FreeArc\bin\Arc.exe" a d:\file.arc d:\tprk\* -max
Задача следующая всё содержимое папки d:\tprk\ положить в архив d:\file.arc с ключом -max
Смущает, что в начале работы архиватор пишет, что будет сжимать слишком малое количество файлов, меньше чем в папке, меньшее и объёму и по количеству.
То же самое и с
"%ProgramFiles%\FreeArc\bin\Arc.exe" a d:\file.arc d:\tprk\* -mx
Разобрался: или
"%ProgramFiles%\FreeArc\bin\Arc.exe" a d:\file.arc d:\tprk\* -max -r или
"%ProgramFiles%\FreeArc\bin\Arc.exe" a d:\file.arc d:\tprk -max
Про интерфейс GUI версии: ПЕРЕГРУЖЕН. Есть мнение, что больше 7ми опций, вариантов, чекеров, и т.п. сбивают человека с толку и перегружают его мозг.
P.S. Имея в виду 7 опций в одном экране

Цитата:

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

там используется vhash, на x64 скорость 128-битного хеширования 0.4cpb, т.е. 10 ГБ/с при 4ГГц cpu. я его регулярно людям на encode.ru советую, но его и готовить сложнее, и не особо он им нужен


Цитата:

Для rep из FreeArc на машине с ОЗУ 4 ГБ не реализуется 2 Гб!

это особенность реализации алгоритма, так-то для словаря в 2000 мб достаточно 2512 мб озу. rep со словарём >4ГБ реализован в srep:m0, но понятно что это не так удобно как встроенный в fa алгоритм

Цитата:

Про интерфейс GUI версии: ПЕРЕГРУЖЕН. Есть мнение, что больше 7ми опций, вариантов, чекеров, и т.п. сбивают человека с толку и перегружают его мозг.

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

жду новой версии... желательно и 64бит))) буду тестировать на 4ядр/8гб озу

sergEO7905

Цитата:

в этом же тесте, говорится что размер архива почти не меняется

Еще раз повторю: универсальных зависимостей не существует.
Вот как Вы отнесетесь к этим тестам:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#19
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#21
?

Добавлено:
Комментарий:
4. Забегая вперед, можно отметить, что размер архива для уровня сжатия Быстрый 1024 МБ и 1 поток в данном тесте получился меньше, чем для любых 4-поточных методов, включая Ультра

Про GUI
Возможно, это зависит от целевой аудитории: все или техническая элита.
Ещё удивило в версии для командной строки, что к числу файлов к сжатию добавляются все папки, вместо того чтобы просто просуммировать файлы. Отголоски nix'ов, что ли.

Как-то пропустил, что корейцы добавили в свой BandiZip поддержку FreeArc, скрин из темы по архиватору:
http://i9.pixs.ru/storage/5/1/3/Bezimyanni_6339734_16016513.jpg

Цитата:

Если warc пишет:  
Для установки этой программы необходима библиотека .NET Framework версии 2.0. Пожалуйста установите .NET Framework и повторите попытку снова.

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