Bulat_Ziganshin
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| т.е. распаковывать можно будет обычными средствами freearc'а? Без lzma-freearc-x64.exe? |
да, конечно. собственно что я сделал:
1. откомпилял пример из lzma sdk 64-битным icl'ем (и запатчил под amd)
2. убрал из него немного лишнего чтобы формат сжатых данных был как у моего внутреннего lzma (нормальный lzma.exe из SDK записывает 13 байт параметров в начало сжатого файла, у меня они хранятся в оглавлении архива)
3. добавил поддержку header=0 в FreeArc - с этой настройкой он не записывает доп. заголовок перед данными, сжатыми этим внешним компрессором
4. добавил <stdin> и <stdout> как обозначения того, что данная команда читает данные с stdin или пишет результат на stdout. к сожалению, в гуишном FreeArc.exe это почему-то не работает, я постараюсь разобраться
5. если команда использует и <stdin> и <stdout>, то её stderr скрывается, так что на экране не остаётся вообще никакого мусора - всё точь-в-точь как при использовании внутренних алгоритмов
в результате теперь при наличии достаточного объёма ОЗУ можно использовать lzma-x64 для сжатия со словарём 512-1024 мб в макс. режиме. или использовать 4x4:lzma на пару десятков гиг. и всё это будет распаковываться встроенным lzma - если хватит 32-битной памяти. а можно и внешним, в режиме фильтра временных файлов всё равно не будет
что можно сделать ещё: внешний lzma должен воспринимать все те же параметры, что и внутренний, подчиняться всей той же механике ограничения памяти/словаря и вызываться автоматом для солид-блоков размером, скажем, от 50 мб. тогда пользователь сможет вообще не замечать - внутренний там алгоритм или внешний
кстати, интересно сравнить с тем, что в планах партии было записано:
Цитата:| Compressor: лучше всего для толстых алгоритмов использовать внешние компрессоры. уже сейчас можно взять compressor.exe и использовать его подобным образом. в будущем же compressor будет совместим по формату данных с внутренними алгоритмами так, что к примеру можно будет упаковать внешним lzma со словарём в 1 гиг, а распаковывать внутренним. понятно, будут 32 и 64-разрядные версии, причём компилироваться они будут ICC, что увеличит скорость на 10-20%. fa будет автоматом соображать хватит ли ему наличной памяти для выполнения операции или лучше отдать её на откуп внешней программе. fa научится работать с внешними упаковщиками через stdin/stdout, что позволит использовать их так же удобно, как и внутренние алгоритмы - никакой записи на диск пормежуточных данных, актуальный индикатор прогресса и т.д. |
|
меньше на него темп-файлов будут скидывать) 
эту идею можно было реализовать ещё два года назад, когда у меня появилась 64-битная машина. там делов-то на полдня, и не было бы проблемы с упаковкой игрушек по максимуму
Что я еще не подправил? 
