FreeArc: бесплатный open-source архиватор - Часть 3 - [98] :: Программы

еще тут столкнулсо с непоняткой одной:
значит написал я себе батник на упаковку. Поскольку на разделе где времянка места только 7гб, а я жму данных 12гб, то решил на время сжатия перенести времянку. В доке видел что можно задавать в -w, но я решил не вписывать в каждую строку упаковки -w, вместо этого в начале командника написал:
Код:

set temp = F:\temp

однако это никак не повлияло на процесс и временные файлы ломанулись в С: как и прежде. Я тогда чисто ни на что не рассчитывая изменил в начале командника:
Код:

set tmp = F:\temp

и вот что интересно - фарк отказался паковать вообще с сообщением "...Disk Full?". Т.е. создается впечатление, что фарк вместо переменной среды %TEMP%, указанной в доке (-w%TEMP%), использует %TMP%, а мб и обе.
Решилось все когда таки вписал в каждой строчке упаковки -w"f:\temp".

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

Пришлось добавить в батнике после каждой строки упаковки:
Код:

ERASE /F /S /Q J:\Temp\*.*

но это уже для следующей ночи.

Интересно, вот если реп находит повтор, можно ли как-то где-то узнать меж какими файлами нашлись повторы, а меж какими - нет, чтобы для следующего сжатия файлы с повторами разместить рядом? Ну скажем задал я окно 512мб, а повторы нашлись в начале и в конце, т.е. 450 мб в середине - без особых попаданий. Вот если узнать какие файлы с повторами, то их мб разместить при сжатии вместе и тогда можно будет либо уменьшить словарь без ухудшения сжатия, либо при том же словаре найдется еще больше повторов - т.е. сжатие окажется еще лучше. Может ли иметь место какой-либо анализатор, который бы дал отчет на эту тему? Т.е. какая-то прога проанализировала бы какие файлы имеют меж собой больше выгодных повторов, какой размер словаря был бы оптимальным и т.п. Если бы такой анализ был бы встроен в фарк, он бы по результатам анализа при последующем сжатии сам размещал бы файлы в соотв. порядке. Пусть бы даже анализ начинался с словарем в 2Гб или если х64 -то и того боле... Это не только для репы полезно, но и для лзма. Да, сжатие с анализом заняло бы уйму времени, но кому надо - на такое пойдут, это 100%.
Или это все уже в srep-е есть и нех тут мозг сношать

? Но srep ищет повторы на дальних дистанциях, это другое. Это для вариантов, когда файлы идут размерами по несколько гиг каждый и некуда деваться, т.е. тасовать их порядок при сжатии практически бесполезное занятие. Кстати говоря раз srep ищет повторы на дальних дистанциях, то анализатор как раз на его основе можно делать.

Добавлено:
Вот есть такой режим сжатия 4х4 - это когда запускается сжатие в 4 потока. Это правильно и модно, но он не то чтобы заточен, но так и просится для использования на 4х-ядерных платформах.
А нельзя ли для такой же большой армии 2х-ядерных процов забацать режим 2х2? Я понимаю что сейчас и 4х4 работает, просто по 2 потока на ядро, но это как бэ избыточно. Я не уверен в принципе, есть ли смысл в 2х2, но не сошли еще с полей четвёртые пни, у которых второе ядро типа НТ, да и для 1-ядерных решений получится 2 потока.
Опять же на подходе 6-ядерное решение от АМД - тоже надо реагировать в 6х6

Ну и для 4х-ядерных обрубков от АМД еще придется мутить 3х3

Модерирует : gyra, Maz
Widok (23-11-2010 11:37): Лимит страниц. Продолжаем здесь	Версия для печати • Подписаться • Добавить в закладки
Страницы: 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 101 102 103 104 105 106