Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор

Модерирует : gyra, Maz

Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

   

Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
FreeArc
бесплатный open-source архиватор для Windows и Linux,
сочетающий высокую степень сжатия и большой набор возможностей

Официальный сайт
Документация он-лайн на консольную версию
Скриншоты / Документация на GUI версию
Страница загрузки
Проект на SourceForge.net / SVN-репозиторий

Последний релиз - FreeArc 0.40 от 1 января 2008 г. Новая версия включает мультимедиа-сжатие, улучшение обычного сжатия, сверх-быструю упаковку в режимах -m1/m2, поддержку произвольных внешних упаковщиков, настраиваемых в arc.ini, 1.5-кратное увеличение скорости работы на 2-ядерных процессорах, навороченное шифрование, полностью работающие плагины для FAR/TC, прямой доступ к архивам в интернете, восстановление архивов через интернет и множество других изменений (полный список)
 
Текущая альфа версия 0.50 от 23 июня 2008 г. Включает GUI с русификацией (описание), автоматическое определение типов файлов, создание SFX, ускорены режимы -m3/m4 и linux-версия, решены проблемы на машинах с 2+ гб ОЗУ, исправлены ошибки в -m1 и -mx (полный список изменений)

MiniFAQ...

Подробное описание используемых алгоритмов
Почему он сжимает лучше и быстрее, чем 7-zip/rar...
Результаты тестов, подтверждающие его крутизну...
Планы дальнейшего развития... (обновлены 15 июня)
Почему для использования 2+ гб памяти желательно установить 64-битную версию Windows
Что подразумевается под "интеграцией с Explorer"  
FreeArc wiki (включая описание формата архива)
External compressors Power Pack
Логотип - объявляется конкурс на иконки для FreeArc

Сторонние оконные программы для работы с FreeArc
wArc - простая и понятная программа управления архивами (требует .NET Framework 2.0)
PeaZip – менеджер архивов с поддержкой большого количества форматов, для Windows и Linux

предыдущая версия шапки

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 12:55 13-08-2007 | Исправлено: juvaforza, 20:57 28-01-2009
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
 и запихал всё в http://www.haskell.org/bz/arc.arc

непонятно на просто Win32
выставлял 2560m
 
получил:
lzma:128m
rep:1gb
 
ppmd:2017m
ERROR: Can't allocate memory required for (de)compression in ppmd:9:2048432kb
lzp:2208m
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18
 
вообщем косячит

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 01:02 11-01-2008
SCINER



Junior Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
Нельзя добавить пустую папку, и нельзя создать папку в архиве.
Можно ли сделать такой функционал?

Всего записей: 85 | Зарегистр. 17-12-2007 | Отправлено: 02:07 11-01-2008
Ghost2004

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Сорри, что торможу - закопался с тестами...
 
Могу предоставить текущие результаты.  
Исходные данные: Rogue Galaxy, DVD-Split (т.е. DVD9 для PS2 разбитый на 2 DVD5 – у PS2  формат DVD9 настандартный, так что записнная двуслойная болванка не прочтётся приставкой – не говоря уж о том, что две DVD5 раз этак в 4-5 дешевле одной DVD9). Два варианта – первый просто RG_compression methods.arc, второй – RG_ExIm_compression methods.arc, - т.е. извлечённые из .iso данные (но не просто так – на втором диски для совместимости  два файла по 1 Gb и 1.5 Gb соответственно пропросту дублируются под разными именами, т.е. что-то вроде hard-link'ов в NTFS – так вот я удалил 100% совпадающие файлы – это к вопросу о трудностях при реализации варианта, где iso файл воспринимается как просто каталог + данные файловой системы – впрочем подозреваю, что оно лечится включением сортировки в первую очередь по размеру (или, скажем, введением дополнительной сортировки максимального приоритета для файлов одинакового объёма)).  
 
Результаты следующие (подчёркивание в имени файла можно воспринимать как двоеточие в настройках, ++ - «tempfile в ручную», т.е. сжатие файла .arc до ++, методом указанным после ++)
исходный релиз сжатый rar'ом: 5 430 917 128 (5.05 Gb)
исходный размер:  
RG – 7 906 369 994 (7.36 Gb),
RG_ExIm – 7 904 307 412 (7.36 Gb).
 
RG_delta+lzma_158mb_max_273.arc - 5 163 801 775 (4.80 Gb) – короче, от 158 mb-словаря выигрыш лишь 5%... Сжимала 3 часа – правда скорее всего, мешали другие приложения.
 
RG_rep1266mb_h27_a99_32.arc – 5 795 086 471 (5,39 Gb) – от rar'а не сильно отстаёт... Хотя длина 32 тут не самая лучшая настройка... Потому как дальнейшие rep:1512mb:h26:32:a99 дают выигрыш лишь в 20.95 Мб – а l32 чаще всего именно для этого и нужно – чтобы уменьшить дистанцию между совпадающими данными для следующего rep'а, который смог бы преодолеть барьер между совпадающими данными.
 
Оно и видно:
RG_rep1522mb_h26_a99_32++delta+lzma_158mb_max_273.arc  - 5.163.393.612 (4.80 Gb) – фактически то же, что и без rep (разница между 1522mb:h26 и 1266mb:mb минимальна – примерно 2 mb).
 
А вот с ExIm совсем другая картина:
RG_ExIm_delta+lzma_158mb_max_273.arc – 4 482 809 972 (4,17 Gb) – уже серьёзный выигрыш в 15% только засчёт распаковки iso и сортировки их содержмого (только с hard-link'ами в iso разобраться бы – иначе эти самые 2.5 Гб встали бы lzma поперёк горла).
 
RG_ExIm_rep1200mb_h27_a99_32.arc – 4 168 528 006 (3.88 Gb) – даже лучше просто lzma...
 
RG_ExIm_rep1200mb_h27_a99_32++rep1200mb_h27_a99_32.arc – 3 660 071 213 (3.40 Gb) – вот тут-то выигрыш от второго rep'а налицо.
 
RG_ExIm_rep1200mb_h27_a99_32++delta+lzma158mb_max_273.arc – 3 616 747 587 (3.36 Gb) – результат очень близок к предыдущему.
 
Ну и наконец:
RG_ExIm_rep1200mb_h27_a99_32++rep1200mb_h27_a99_32++delta+lzma158mb_max_273.arc  
даёт 3 322 267 047 (3.09 Gb) – на данный момент это максимум сжатия, который удалось получить... Впрочем, rep:l32 не самый лучший вариант – вполне вероятно, что rep:4096/512/128 дадут лучшие результаты (не говоря уж о варианте l4096/512/128:s32:d158mb).
 
Speaking of which,  
 
RG_ExIm_rep1512mb_h26_4096.arc – 4 339 992 792 (4.04 Gb) (угу, тоже лучше простого lzma)
 
RG_ExIm_rep1512mb_h26_4096++delta+lzma_158_273.arc – 3 304 231 764 (3.07 Gb) – таки с максимумом я погорячился, всё же rep:4096 тут оказалась даже лучше двух rep:32...
 
В общем, буду дальше тестировать – теперь 4096 (с 32 вместо 512 я начал чтобы охватить более широкий набор настроек), затем наверное 512, а потом 128... Ну а ещё попробую поиграться с d158mb:s32/64/128...
 
Кстати, может имеет смысл выделять один блок памяти для хранения данных, а другой – для хеш-таблицы? А то у меня в win32 (с /3GB /USERVA=2800) avalible physical memory выдаёт   в районе 2500 Mb (впрочем, это я ещё не все жадные до памяти приложения повырубал), а ram speed test застревает на 1909 Mb (есть варианты как с этим побороться?)...
 
Насчёт варианта rep с более усточивым  хэшем – c удовольствием постестирую, даже без распаковки, тем более что на RG она бы улучшила сжатие в раза в 1.5, судя по отсортированному ExIm варианту. И думаю что для всех подобных случаев вышло бы примерно то же самое (на 25 Гб SO 3 – так вообще из 18 Гб сжатых rar'ом стало бы наверняка 5-8  Гб ... Надеюсь только, что она не будет мучить те 8 Гб слишком долго, более 6 часов... И ещё – если будешь реализовывать этот вариант, такое вот пожелание - можно ли без особых трудностей добавить в отладную информацию следующую меру эффективности: сколько сопадений на дистанциях меньше 128 Мб и какой их суммарный размер (т.е. по сути выигрыш), затем то же, но на дистанциях от 128 до 256Мб, 256-512, 512-1024 и т.д (или даже 128-256, 256-512, 512-768, 768-1024 и т.д)? Ведь альтернатива этому лишь возможность воспринимать образы дисков как простые каталоги, а там много подводных камней, вроде тех же hard-link'ов... Да и вообще в смысле распаковки это могло бы устранить проблему прожорливости rep'а – ведь rep:1gb распакуется без тормозов лишь на компе с 2 gb... Другое дело, что для этого варианта (назовём его lrep – (long rep)) придётся исхитряться с распаковкой, используя доступную RAM в качестве кэша и придумывая разнообразные оптимизации... Впрочем, если эта штука будет достаточно быстрой, то можно просто на основании той статистики провести перестановку блоков по 128-1024 Мб и прошерстить их простым rep'ом... Да, и ещё, какие размеры слова там имеют смысл – 128 (ограничив дистанцию до 4-8 Гб) можно испробовать как экстремальный вариант, наподобие 32 для rep?
 
 
 
 
egor23

Цитата:
опять второпях ключевое слово пропустил подобрать подходящую последовательность зачем же лишнюю работу делать самому, пускай FreeArc делает.
 
т.е.
Пример
есть 4 файла пусть по 2gb
используем rep:1gb, но обработка идёт не последовательно, а параллельно:
1. или пропорционально - 1gb\4 = 250mb - берутся по 250Мб из каждого файла и обрабатываются, потом следующие 250Мб и т.д.
2. или возможность задания участков в файлах и их последовательности в обработке.
 

Ну, 1 вариант скорее всего не пройдёт, можно коненчо потестировать вариант с разбиванием iso'шек на куски по 256 mb - но вряд ли будет заметный выигрыш, уж очень это ограниченная штука, данные ведь запросто могут лежать не последовательно, плюс её и без freearc элементарно реализовать... А вот подбор и задание участков и их последовательности увеличит время сжатия в n-1 раз (в неоптимизированном варианте), где n - отношение полного размера данных к размеру куска - надо же провести rep для каждого куска с каждым, а в случае простейшего метода оно будет n(n-1)/2, тогда как для простого rep выходит всего лишь порядка n/2 таких сравнений (плюс n-1 раз придётся создавать tempfile )... Может лучше подобные вещи делать с умом - т.е. используя статистику полученную из lrep...
 
Впрочем, всё равно потестирую RG с этим, разбив её, скажем, на куски по 512 mb...
 
З.Ы.
Да, а насчёт памяти – даже в win32 /3G /USERVA=2800 rep:1779mb:h27:a99 проходит в 0.40 версии пропатченой editbin, виртуальная (а также физическая) память при этом достигает 2 368 048 kb ... А вот lzma по прежнему не пашет выше 159 mb . В 0.50 (и 0.50-no-http) указанная rep:1779mb:h27:a99 не хочет идти – работает только с h24 вместо h27 – если её не пропатчить editbin (если пропатичть, то ведёт себя также как и в пропатченой 0.40).

Всего записей: 51 | Зарегистр. 02-01-2008 | Отправлено: 08:14 11-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Нельзя добавить пустую папку, и нельзя создать папку в архиве.  
Можно ли сделать такой функционал?

в общем, я сейчас подчищаю проблемы, выявленные в 0.40, и собираюсь сделать всё как в rar - "arc a archive dir" будет паковать и сам каталог dir, и всё его содержимое рекурсивно
 

Цитата:
=) Прикол конечно. Каталог назвать двумя точками =)

ещё одна бага. fa должен был обрезать ".." в начале пути
 

Цитата:
ыыы жестоко  
пожалуйства выкладывайте Arc.exe и т.п. новое (без страрого) в архиве 7-zip(на всякий случай)

а какие это может вызвать проблемы? есть стабильная 0.40, которая всё это распаковывает; даже если что будет не так - вы это сразу заметите
 

Цитата:
получил:  
lzma:128m  
rep:1gb

ты хочешь сказть, что lzma:192m, lzma:fast:256m, rep:1536m не работают, даже с /3g? ну тогда потестируй на висте, плиз
 
и ещё посмотри -m8/-m9 без всяких -lc/ld - смогут они автоматом вписаться в твою машину (под xp, xp/3g, vista) или автодетект по объёму доступной вирт. памяти пока что не работает?
 

Цитата:
ppmd:2017m  
ERROR: Can't allocate memory required for (de)compression in ppmd:9:2048432kb  
lzp:2208m  
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18  
 

ну вот, насчёт ppmd - это как раз пример неработоспособности автоопределения объёма свобожной вирт. памяти. lzp - просто ошибка, надо запретить словари больше 2 гиг
 

Цитата:
Пример  
есть 4 файла пусть по 2gb  
используем rep:1gb, но обработка идёт не последовательно, а параллельно:  
1. или пропорционально - 1gb\4 = 250mb - берутся по 250Мб из каждого файла и обрабатываются, потом следующие 250Мб и т.д.  
2. или возможность задания участков в файлах и их последовательности в обработке.  
 

лучше это делать внешней утилитой
 

Цитата:
А вот подбор и задание участков и их последовательности увеличит время сжатия в n-1 раз (в неоптимизированном варианте),

учитывая ввысокую скорость работы REP, фактчисеки это будет время n-кратного чтения с диска всех наших 18 гиг
 

Цитата:
можно ли без особых трудностей добавить в отладную информацию следующую меру эффективности

можно, но только в standalone rep.exe
 

Цитата:
Ведь альтернатива этому лишь возможность воспринимать образы дисков как простые каталоги, а там много подводных камней, вроде тех же hard-link'ов...  

знаешь, была какая-то утилита, которая сжимала не то jpg, не то bmp, но не bit-to-bit - что-то она портила в заголовке. и вот один чел просто написаол батник, которая сравнивала заголовки исходного и восстановленного файла обычной командой fc, и запоминала сжатый файл плюс выведенные fc изменения
 
аналогично можно поступать и здесь - сохранять набор файлов плюс к примеру "болванку" диска со всеми каталогами, но без реальных данных - можно заменить их нулями или опустить
 

Цитата:
Кстати, может имеет смысл выделять один блок памяти для хранения данных, а другой – для хеш-таблицы?

и в rep, и в lzma так и делается. поэтому теоретичсеки ограничения на рахзмер окна - 2гига в rep и 256мег в lzma (поскольку один блок памяти ограничен в win32 2 гигами)
 

Цитата:
Да, и ещё, какие размеры слова там имеют смысл – 128 (ограничив дистанцию до 4-8 Гб) можно испробовать как экстремальный вариант, наподобие 32 для rep?

считай сам - при слове 10000 скорость должна быть 1 мб/с (исходя из seek time 10 мс), при 128 - 12.8 кб/c. при этом всё время распаковки он будет нещадно молотить винтом. я думаю, что это будет достаточно реально при использовании в качестве кэша флешки - там и объёмы в 8-16 гиг доступны, и seek time в 1мс - реален
 

Цитата:
впрочем подозреваю, что оно лечится включением сортировки в первую очередь по размеру (или, скажем, введением дополнительной сортировки максимального приоритета для файлов одинакового объёма)).  

такое в fa есть (буква r в опции -ds), но сейчас оно "подтаскивает ближе" только файлы с одним расширением. надо будет переделать
 
и ещё - 273 по моим тестам не лучшая настройка для lzma. 128 лучше
 
и плиз потестируй no-http версии из http://www.haskell.org/bz/arc.arc - они могут быть лучше в плане максим. размера словаря для lzma/rep

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 11:31 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
ты хочешь сказть, что lzma:192m, lzma:fast:256m, rep:1536m не работают, даже с /3g? ну тогда потестируй на висте, плиз

только смотрел как идёт ограничение если выствить большой словарь на Win32 без 3g.
выставлял размер словаря 2560m(первое число которое пришло на ум).
 
букву m забыл:
Arc050.exe a a.arc -mppmd:2560 -di -di+$ 2207.tar
ppmd:2560:48mb
Вываливается:
Инструкция по адресу "0x0050788e" обратилась к памяти по адресу "0x01010002". Память не может быть "written".

Цитата:
и ещё посмотри -m8/-m9 без всяких -lc/ld - смогут они автоматом вписаться в твою машину (под xp, xp/3g, vista) или автодетект по объёму доступной вирт. памяти пока что не работает?

Впишутся, а куды они денутся, без -lc/ld - они и раньше вписывались, хотя ещё включу опцию Установить поддержку языков с письмом иероглифами, тогда это будет наглядней в Win32.

Цитата:
а какие это может вызвать проблемы?

мне 4Мб выкачивать тяжело "каждый раз", а извлечением по сети не пользуюсь, у меня не постаянный доступ Inet.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 13:12 11-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
linux-версия - http://www.haskell.org/bz/arc-linux-gui.arc

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 13:32 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ghost2004

Цитата:
RG_ExIm_rep1512mb_h26_4096++delta+lzma_158_273.arc – 3 304 231 764 (3.07 Gb) – таки с максимумом я погорячился, всё же rep:4096 тут оказалась даже лучше двух rep:32...

у lzma размер слова max 273, так что перед тем как отдать ему проганите rep-ом с l256
т.е. rep1512mb_h26_4096 + rep1512mb_h26_256 или типа того, т.е. если повторы большие, то ставить большой l потом уменьшать его.
Но, универсальных настроек быть не может, для этого данные нужно предварительно подвергать анализу, после корректировать настройки алгоритмов сжатия.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 13:52 11-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ну вот, благодаря Ghost2004 мы наконец выяснили, что моя компиляция просто не включает largemem - похоже, это ошибка в компиляторе!
 
теперь вопрос звучит так - если все эти 4 exe-шника пропатчить editbin, то есть ли разница в работе http/no-http и gui/console версий хотя бы на одной из 3 ОС - xp, xp/3g, vista-64bit. в зависимости от этого я и буду принимать решение. очень не хотелось бы с curl возиться - времени и так в обрез, да к тому же это лишняя головная боль для тех, кто будет собирать fa из исходников
 
разумеется, теперь в компиляцию включен шаг editbin, а в инструкцию по самостоятельной компиляции - ссылка на его загрузку
 

Цитата:
мне 4Мб выкачивать тяжело "каждый раз", а извлечением по сети не пользуюсь, у меня не постаянный доступ Inet.

понял. буду выкладывать для тебя отдельно exe-шники
 

Цитата:
без -lc/ld - они и раньше вписывались

вот почему я не хотел этим заниматься. те, кто использует -lc- должны сами разбираться сколько им памяти использовать. меня взволновало только то, что -mx не работает при наличии 3-4 гиг ОЗУ
 

Цитата:
ppmd:2560:48mb

поправлю

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 15:00 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Available Physical Memory.exe использует
ExitProcess
GlobalMemoryStatus
 
RAM Speed Test.exe использует
ExitProcess
GetCurrentProcess
GetCurrentThread
GetSystemInfo
GlobalMemoryStatus
QueryPerformanceCounter
QueryPerformanceFrequency
SetPriorityClass
SetThreadAffinityMask
SetThreadPriority
VirtualAlloc
VirtualFree
 
(WinXP 32bit) 2.5Гб+2Гб(файл подкачки)+иероглифы
RAM Speed Test.exe 1325Мб
Available Physical Memory.exe 2035Мб
 
ppmd
 
Arc050.exe a a.arc -mppmd:2560m -di -di+$ 2207.tar
ERROR: Can't allocate memory required for (de)compression in ppmd:8:1536mb
 
Arc050.exe a a.arc -mppmd:1326m -di -di+$ 2207.tar (далее Can't allocate memory required)
Memory for compression 1326mb, decompression 1326mb, cache 1mb
ppmd:10:1326mb
Вирт.память - 1371724кб=1340Мб
 
rep
 
Arc050.exe a a.arc -mrep:2560m -di -di+$ 2207.tar
rep:1gb
Memory for compression 1280mb, decompression 1gb, cache 1mb
Вирт.память - 1324784кб=1294Мб
 
Arc050.exe a a.arc -mrep:1070m -di -di+$ 2207.tar (далее Can't allocate memory required, начиная с 1281m(подсчёт нужной памяти переваливает за 1536m) скидывает до rep:1gb)
Memory for compression 1326mb, decompression 1070mb, cache 1mb
 
Вирт.память - 1371932кб=1340Мб
 
lzp
 
Arc050.exe a a.arc -mlzp:2560m -di -di+$ 2207.tar
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18
 
Arc050.exe a a.arc -mlzp:663m -di -di+$ 2207.tar (далее Can't allocate memory required на втором этапе, начиная с 768m(подсчёт нужной памяти переваливает за 1536m) скидывает до lzp:785920kb:64:h18, на втором этапе Can't allocate memory required)
Memory for compression 1327mb, decompression 1327mb, cache 1mb
Вирт.память - 1372616кб=1340Мб
 
lzma
 
Arc050.exe a a.arc -mlzma:2560m -di -di+$ 2207.tar
Using lzma:128mb:normal:bt4:32
Memory for compression 1476mb, decompression 128mb, cache 1mb
Вирт.память - 1390612кб=1358Мб
 
Arc050.exe a a.arc -mlzma:133m -di -di+$ 2207.tar (далее скидывает до 128m, т.е. подсчёт нужной памяти переваливает за 1536m)
Memory for compression 1534mb, decompression 133mb, cache 1mb
Вирт.память - 1570500кб=1534Мб
 
Как у lzma размер хэша считается? и вообще как выделение памяти считается?
 
Добавлено:

Цитата:
теперь вопрос звучит так - если все эти 4 exe-шника пропатчить editbin, то есть ли разница в работе http/no-http и gui/console версий хотя бы на одной из 3 ОС - xp, xp/3g, vista-64bit.

было без разницы, 050 пока ещё не проверял
http://forum.ru-board.com/topic.cgi?forum=5&topic=24319&start=600#6
 

Цитата:
вот почему я не хотел этим заниматься.

вписывались потому что лимит 1536m катит, с +иероглифы уже не катит.
 
 
Добавлено:

Цитата:
 -mx не работает

не работал в gui - т.к. лимит 1536m не прокатывал в отличии от cli
 
С памятью обратите внимание на RAM Speed Test.exe
находит самый большой непрерывнй блок в памяти.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 15:28 11-01-2008
Registered User

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
В http://www.haskell.org/bz/arc.arc всё, как я понимаю, запихано в 1 блок.
Что не есть гуд.листинг

Всего записей: 76 | Зарегистр. 22-12-2007 | Отправлено: 16:12 11-01-2008
G2_UFO

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
небольшое замечание для GUI: в выборе настройки сжатия нужно сделать что-то более понятное, а не m4x - для обычного пользователя эти 3 буквы ничего не значат совершенно.

Всего записей: 93 | Зарегистр. 12-06-2006 | Отправлено: 16:23 11-01-2008
Bulat_Ziganshin

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
В http://www.haskell.org/bz/arc.arc всё, как я понимаю, запихано в 1 блок.

нет. мой листинг, в отличие от 7-zip, не показывает солид-блоки. это увидеть можно только в FAR plugin:
 

Код:
charset               dll|   24576| 3066191
iconv                 dll|  892928|       0
intl                  dll|   45056|       0
...
Arc050-no-http        exe| 2244608| 1099876
Arc050                exe| 2247168|       0
WinArc050-no-http     exe| 2417664|       0
WinArc050             exe| 2420736|       0
 

Всего записей: 3408 | Зарегистр. 13-08-2007 | Отправлено: 16:38 11-01-2008 | Исправлено: Bulat_Ziganshin, 16:45 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

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

Ессесно.
Но дополнительная опцию -lv всё таки наверно нужна
-lc\-ld - ограничивают физ.память вообще
-lv - ограничивает виртуальную, а тут по-сути ограничение не вируальной памяти вообще, а ограничение на непрерывный блок в ней. (не накаждой машине будет такой непрерывный блок),
т.к. если сейчас сомещено ограничение, то расёт параметров алгоритмов будет сильно занижен, т.к. насколько я понял, напримере rep-а, занимается непрерывнй блок равный размеру словаря, а хэш занимает далее. Тут кстати вопрос хэш занимает память как зря или ему тоже нужен непрерывный блок?
 
Может сделаете утилитку для работы с памятью, для обкатки всяких "мыслей"
Например вывод не только самого большого непрерывного блока, но и вывод информацию о других непрерыных блоках (ессенно без фанатизма, min размер блока лимитирован, если определение этих блоков продолжительная операция).
также вывод другой информации о памяти, а то на глаза не попадались такого рода утилитки, кроме RAM Speed Test.

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 16:56 11-01-2008
SCINER



Junior Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
wArc научился:
Отображать размер архива в статусной строке
Переключать вид списка файлов на большие и маленькие иконки

Всего записей: 85 | Зарегистр. 17-12-2007 | Отправлено: 17:19 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ghost2004

Цитата:
 а ram speed test застревает на 1909 Mb (есть варианты как с этим побороться?)...

Win64
http://forum.ru-board.com/topic.cgi?forum=5&topic=24319&start=580#20
http://forum.ru-board.com/topic.cgi?forum=5&topic=24319&start=600#13
http://forum.ru-board.com/topic.cgi?forum=5&topic=24319&start=600#15

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 19:00 11-01-2008 | Исправлено: egor23, 19:06 11-01-2008
Registered User

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
нет. мой листинг, в отличие от 7-zip, не показывает солид-блоки. это увидеть можно только в FAR plugin:  
 

 
За что же такая дискриминация J.

Всего записей: 76 | Зарегистр. 22-12-2007 | Отправлено: 19:03 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

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

уточнение
-lv - ограничивает виртуальную память вообще.
-lvb - ограничение на непрерывный блок в виртуальной памяти.
т.к. Win64 - вирт.памяти вообще больше, чем в Win32.
 
Добавлено:

Цитата:
-lv - ограничивает виртуальную память вообще.

чёрт, тогды не -lv, а
-lvс - ограничивает виртуальную память упаковка
-lvd - ограничивает виртуальную память распаковка

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 19:44 11-01-2008
SCINER



Junior Member
Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
wArc:
Реализовано извлечение только выделенных файлов

Всего записей: 85 | Зарегистр. 17-12-2007 | Отправлено: 21:05 11-01-2008 | Исправлено: SCINER, 21:07 11-01-2008
egor23



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Bulat_Ziganshin

Цитата:
покажи мне хоть олного автора архиваторов, который озабочен работой с >2gb.

хотя не наверно есть\точнее был судя по последним версиям:
Matt Mahoney
paq8a-paq8d опция -9
 
Win64 2.5Гб+2Гб(файл подкачки), EDITBIN.EXE /LARGEADDRESSAWARE paq8a.exe
paq8a.exe -9 p.paq 3dmark05_v100_installer.exe
Вирт.память - 3233180кб=3157Мб=3.08Гб

Всего записей: 3832 | Зарегистр. 03-11-2003 | Отправлено: 21:07 11-01-2008
slech



Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
WinArc050 в zip заходить не умеет ?
у меня вылетает сразу.

Всего записей: 4893 | Зарегистр. 10-11-2004 | Отправлено: 22:17 11-01-2008
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Компьютерный форум Ru.Board » Компьютеры » Программы » FreeArc: бесплатный open-source архиватор
Widok (30-01-2009 12:03): лимит страниц. продолжаем здесь


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru