ZXNet эхоконференция «code.zx»
тема: Оптимальное LZ-кодирование
от: lvd
кому: All
дата: 14 Dec 2005
Hello, All
Ситуация: есть некий файл, его хочется запаковать LZ-методом.
Файл гружу в память и для каждого байта строю набор всех подходящих к нему
LZ-кодов (длина, смещение, размер кода в битах).
Hадо: выбрать оптимальную цепочку этих кодов и сгенерить самый короткий из
возможных выходных запакованных файлов.
Вопрос: как? =)
Делаю пакер megalz на сях.
от: valker
кому: All
дата: 14 Dec 2005
Hello, lvd
lvd> Ситуация: есть некий файл, его хочется запаковать LZ-методом.
lvd> Файл гружу в память и для каждого байта строю набор всех подходящих к
lvd> нему LZ-кодов (длина, смещение, размер кода в битах).
lvd>
lvd> Hадо: выбрать оптимальную цепочку этих кодов и сгенерить самый
lvd> короткий из возможных выходных запакованных файлов.
lvd>
lvd> Вопрос: как? =)
lvd>
lvd> Делаю пакер megalz на сях.
Платформа какая?
Возможно, поможет представление кода, как прохода по графу, а оптимальный в
смысле длины кода, как путь по графу минимальной длины.
от: Камиль Каримов
кому: All
дата: 14 Dec 2005
Hello, lvd
lvd> Ситуация: есть некий файл, его хочется запаковать LZ-методом.
Посмотри исходники, надеюсь поможет.
Файл: lz_src.zip http://zx.pk.ru/attachment.php?attachmentid=2109
от: Камиль Каримов
кому: All
дата: 14 Dec 2005
Hello, lvd
lvd> Ситуация: есть некий файл, его хочется запаковать LZ-методом.
Посмотри исходники, надеюсь поможет.
Файл: lz_src.zip http://zx.pk.ru/attachment.php?attachmentid=2109
от: lvd
кому: All
дата: 14 Dec 2005
Hello, valker
val> Платформа какая?
val>
Какая разница - если на сях пишу... Hе спек уж точно! =) Жрёт память
по-чёрному, так что не дос тоже. :)
> Возможно, поможет представление кода, как прохода по графу, а
> оптимальный в смысле длины кода, как путь по графу минимальной длины.
Hу да - и как этот путь минимальной длины искать? ;)
от: Dima Kozlov
кому: All
дата: 16 Dec 2005
Hello, lvd
вот тут есть n-ное количество статей на тему non-greedy/lazy parsing'а для LZ*
алгоритмов:
http://www-koi.compression.ru/download/lz.html
они дают не оптимальный результат, но сжатие улучшают выбирая более правильные
цепочки...
от: Dmitry Pyankov
кому: All
дата: 16 Dec 2005
Hello, Hrumer
В дополнение: ага, понял о чем ты. Минимизация количества пар (длина смещение)
и литералов не означает того, что получится файл минимальной длины. Hо за то,
скорее всего такой файл будет быстрее всего распаковываться. Хотя выигыш по
скорости распаковки, наверное, составит менее 0.1%.
от: Dmitry Pyankov
кому: All
дата: 16 Dec 2005
Hello, valker
Valker: оптимальность кодирвания может быть как минимум 2 типов: опимальность в
смысле размера упакованного файла, и оптимальность в смысле минимизации
количества пар(длина смещение) и литералов. Какая у тебя имеется ввиду?
от: lvd
кому: All
дата: 16 Dec 2005
Hello, Hrumer
Hru> Valker: оптимальность кодирвания может быть как минимум 2 типов:
Hru> опимальность в смысле размера упакованного файла, и оптимальность в
Hru> смысле минимизации количества пар(длина смещение) и литералов. Какая
Hru> у тебя имеется ввиду?
Hrumer, пасиб за посыл в нужном направлении в емыле :) Я отыскал то же самое
уже потом в инфогуиде#6 =)
Valker, по сути алго дейкстры это то же самое что Хрумер мне предложил (и что в
инфогуиде#6), только во втором случае он упрощён применительно к специфическому
виду деревьев.
elf/2, ага 10х, выкачал всё, завтра доберусь до компа где выкачано и посмотрю
=))
от: lvd
кому: All
дата: 16 Dec 2005
Hello, caro
car> Посмотри исходники, надеюсь поможет.
Хм... там даже и намёка нет на оптимальный выбор цепочки... =)
от: lvd
кому: All
дата: 16 Dec 2005
Hello, caro
car> Приведено три варианта, которые на одном и том же тестовом файле дают
car> разные результаты паковки.
car>
Из которых один - с хаффманом после ЛЗ, а другой - с арифм. кодированием после
ЛЗ. У меня только ЛЗ =)
> Думаю готовый вариант решения задачи не стоит ждать :)
Да вот Хрумер дал один намёк в емыле - буду туда копать =)
от: valker
кому: All
дата: 16 Dec 2005
Hello, lvd
lvd> Какая разница - если на сях пишу... Hе спек уж точно! =) Жрёт память
lvd> по-чёрному, так что не дос тоже. :)
lvd>
lvd> Hу да - и как этот путь минимальной длины искать? ;)
Если чистый С, то реализовать алгоритм Дейкстры (он подходит для
неотрицательных весов).
Если С++, то возьми BGL (Boost Graph Library), там этот алгоритм (и многие
другие) уже реализован.
Удачи!
от: Камиль Каримов
кому: All
дата: 16 Dec 2005
Hello, lvd
lvd> Хм... там даже и намёка нет на оптимальный выбор цепочки... =)
Приведено три варианта, которые на одном и том же тестовом файле дают разные
результаты паковки.
Думаю готовый вариант решения задачи не стоит ждать :)
от: valker
кому: All
дата: 16 Dec 2005
Hello, Hrumer
Hru> Valker: оптимальность кодирвания может быть как минимум 2 типов:
Hru> опимальность в смысле размера упакованного файла, и оптимальность в
Hru> смысле минимизации количества пар(длина смещение) и литералов. Какая
Hru> у тебя имеется ввиду?
В смысле длины полученного кода в битах.
от: lvd
кому: All
дата: 22 Dec 2005
Hello, lvd
Итак, предварительные результаты. Если старый megalz делал файлы на 10-20 байт
длиннее (а то и менее 10 байт), чем хруст2, то с этим алго - уделывает хруст в
сотни байт! Хрум3.5 вообще отдыхает (с вычитанием 150 байт из длины даже). Рип
естественно всех поруливает - но на то он и хафман. Единственный прокол - на
одном файле хруст всех уделал. Это был асм-выход компилятора msvc =)
от: lvd
кому: All
дата: 23 Dec 2005
Hello, Hrumer
Hru> 2lvd: интересно было бы посмотреть на таблицу результатов.
Hru>
Ща ещё чуть-чуть причешу код - и будет релиз =) там и таблицы рекламные будут,
и файлы тестовые даже =) Если не заломает меня...
> Следующим этапом, видимо, будет рассмотрение других кодов - просто
> для эксперимента.
>
Мне уже скорее всего влом будет =)
> У тебя какие именно коды используются? (долго смотреть в
> распаковщике)
типа вот такого:
┌─- code ───
Формат пакованного файла:
первый байт копируется в выход
второй - ид т в биты
биты в байте битов - со старшего.
Если нужен бит, а его уже нет (все 8 кончились) - то новый байт выбирается
из потока. Оттуда же выбираются и байты, обозначенные - но только
после выборки всех битов ссылки.
В формате ссылок: - байт, который выбирается из потока
1 - копировать в выход.
000abc - копировать 1 старый байт по смещению FFF8+[abc] от текущей позиции в
выходе
(abc==000 - смещение FFF8, abc==111 - FFFF)
001 - копировать 2 байта по смещению FF00+ (-1..-256)
0100 - копировать 3 байта по смещению FF00+
0101abcd - копировать 3 байта по смещению (F[abcd]-1)*256+
(-257..-4352)
более длинные ссылки удобно представить в виде 3 частей:
префикс: 011
длина ссылки:
1a -> 4+[a]
01ab -> 6+[ab]
001abc -> 10+[abc]
0001abcd -> 18+[abcd]
00001abcde -> 34+[abcde]
000001abcdef -> 66+[abcdef]
0000001abcdefg -> 130+[abcdefg] (тут длина не более 255!)
смещение:
0 - FF00+ назад (-1..-256)
1abcd - (F[abcd]-1)*256+ (-257..-4352)
Метка конца потока:
011000000001
примеры:
000111 - повторить последний байт
001 - повторить последний байт дважды (смещение=-1, длина 2) -
совмещение LZ и RLE!!!!!
011 001101 10000 - ссылка длиной %101+10 = 15 байт со смещением -4352
└── code ───
от: Valery Grigoriev
кому: All
дата: 23 Dec 2005
Hello, GriV
2lvd> внимательней почитай, там из общей теории следуют парочка интересных
2lvd> выводов, интересных для тебя в том числе. Поиск оптимальных команд языка
2lvd> LZ* - вообще задача экспертной системы и для файлов разного контента
2lvd> (текст, медиа, код) эта задача по разному решаться будет (т.е. давать
2lvd> разный результат, тот же пример привёл Caro вообще-то). Пример с тем же
2lvd> LC - его команды в общем то очень неплохо подобраны для сжатия картинок,
2lvd> однако сильно сомнительно что при помощи LC можно будет эффективно текст
2lvd> или код сжимать - у него управляющие коды под другое заточены.
А потому универсальной последовательности нет, именно это и следует из отсылки,
которая была до математика и воздушного шара.
Если ты хочешь сделать чтото совсем мегауниверсальное, сделай, скажем, штук 256
наборов управляющих команд - каждая из которых будет подбираться под сжимаемый
файл - и в конце у тебя будет неизменно блестящий результат - для распаковщика
дискретного всё равно весь набор команд (256 таблиц) известен, а для
распаковщика интегрированного с архивом так вообще тем более - он изначально
будет заточен под заданную комбинацию.
Hемного пофантазировав (то что было чуть выше это банальные реалии
:-D) можно сообразить такое: файл сжимаемый разбивается на блоки по несколько
килобайт каждый из которых сжимается по оптимальной таблице - итого будет уже
не просто блестящий - а просто отличный результат, непревзойдённый в принципе.
Hемножко оффтопа - тут один товарищ тоже упаковщик писал... который все файлы в
32 байта сжимал (-; я так за него радовался, жалко он рабочий алгоритм -
рабочий код - не показал... (-%
от: Valery Grigoriev
кому: All
дата: 23 Dec 2005
Hello, lvd
lvd> Мне совершенно не нужен хафман и рле. Исключительно лз-коды,
lvd> исключительно найти оптимальную их цепочку, и как посоветовали многие
lvd> - алгоритном Дейкстры. Без всяких теорий =)
Анекдот был конечно руль (-%, причём в тему (-%
Дело вовсе не в RLE и не в Хаффмане - дело в подходе - его можно и для цепочек
LZ* использовать :-D, и придётся решать ту же задачу минимизации по связанным
параметрам в нелинейном пространстве.
от: lvd
кому: All
дата: 23 Dec 2005
Hello, GriV
Gri> 2lvd> внимательней почитай, там из общей теории следуют парочка
Gri> интересных выводов, интересных для тебя в том числе. Поиск
Gri> оптимальных команд языка LZ* - вообще задача экспертной системы и для
Gri> файлов разного контента (текст, медиа, код) эта задача по разному
Gri> решаться будет (т.е. давать разный результат, тот же пример привёл
Gri> Caro вообще-то). Пример с тем же LC - его команды в общем то очень
Gri> неплохо подобраны для сжатия картинок, однако сильно сомнительно что
Gri> при помощи LC можно будет эффективно текст или код сжимать - у него
Gri> управляющие коды под другое заточены.
Gri> А потому универсальной последовательности нет, именно это и следует
Gri> из отсылки, которая была до математика и воздушного шара.
Gri> Если ты хочешь сделать чтото совсем мегауниверсальное, сделай,
Gri> скажем, штук 256 наборов управляющих команд - каждая из которых будет
Gri> подбираться под сжимаемый файл - и в конце у тебя будет неизменно
Gri> блестящий результат - для распаковщика дискретного всё равно весь
Gri> набор команд (256 таблиц) известен, а для распаковщика
Gri> интегрированного с архивом так вообще тем более - он изначально будет
Gri> заточен под заданную комбинацию.
Gri>
Эээ. Я хочу (хотел) лишь под существующий распаковщик паковать наиболее
оптимально. Вот и всё. Это получилось. Переписывать распаковщик в мои планы не
входило. Вот.
> Hемножко оффтопа - тут один товарищ тоже упаковщик писал... который
> все файлы в 32 байта сжимал (-; я так за него радовался, жалко он
> рабочий алгоритм - рабочий код - не показал... (-%
Гы. Легко доказать, что такое невозможно. =)
от: Dmitry Pyankov
кому: All
дата: 23 Dec 2005
Hello, SMT
2SMT: Как я слышал, изначально в правилах вообще не оговаривался этот пункт, а
в дальнейшей переписке "автор" спора согласился, что после упаковки файла
результат упаковки мог быть в нескольких файлах... Вот кастати, есть страничка
где то в инете Леонида Брухиса(если не ошибаюсь) - там есть пари о сжатии...
от: Dmitry Pyankov
кому: All
дата: 23 Dec 2005
Hello, lvd
2caro: Да,похоже я слышал эту историю.. Кое-кто ыявлял определенный символ,
который точно встречается в файле, и по нему разбивал файл на несколько. Сам
символ, естественно в выходные файлы не записывался. Имена файлов, видимо,
использовались для того, чтобы можно было правильно склеить эти файлы...
от: SMT
кому: All
дата: 23 Dec 2005
Hello, lvd
lvd> Ха-ха, ну и правильно, что зажали, ибо читер подлый! =)
не согласен. нечего было лопухаться, когда составляли правила. дал слово -
держи!
от: SMT
кому: All
дата: 23 Dec 2005
Hello, lvd
всё верно, был файл 1.txt с содержимым "Hello", стал 1-48.txt с содержимым
"ello", потом стал 1-48-65.txt с "llo", и т.п...
от: SMT
кому: All
дата: 23 Dec 2005
Hello, lvd
хм. был конкурс с призом в мильон баксов тому, кто сделает архиватор, сжимающий
любой файл хотя бы на 1 байт. ну и нашёлся умник, который сделал. формально
прога удовлетворяла всем критерием и прошла все тесты :) только когда
организаторы разобрались с тем простеньким алгоритмом, они гады денежку зажали
:( жлобы
(если кто эту историю не слышал, могу запостить алгоритм)
от: lvd
кому: All
дата: 23 Dec 2005
Hello, Hrumer
Hru> 2caro: Да,похоже я слышал эту историю.. Кое-кто ыявлял определенный
Hru> символ, который точно встречается в файле, и по нему разбивал файл на
Hru> несколько. Сам символ, естественно в выходные файлы не записывался.
Hru> Имена файлов, видимо, использовались для того, чтобы можно было
Hru> правильно склеить эти файлы...
Hе только имена, но и длины файлов - помечали места вставления символа, т.е.
были дополнительными битами информации.
от: lvd
кому: All
дата: 23 Dec 2005
Hello, SMT
SMT> не согласен. нечего было лопухаться, когда составляли правила. дал
SMT> слово - держи!
Дык учтём инфу о длинах файлов - и всё. =)
от: lvd
кому: All
дата: 23 Dec 2005
Hello, SMT
SMT> хм. был конкурс с призом в мильон баксов тому, кто сделает архиватор,
SMT> сжимающий любой файл хотя бы на 1 байт. ну и нашёлся умник, который
SMT> сделал. формально прога удовлетворяла всем критерием и прошла все
SMT> тесты :) только когда организаторы разобрались с тем простеньким
SMT> алгоритмом, они гады денежку зажали :( жлобы
SMT>
SMT> (если кто эту историю не слышал, могу запостить алгоритм)
Запости. Такого быть не может в принципе.
от: lvd
кому: All
дата: 23 Dec 2005
Hello, caro
car> Если я правильно помню он использовал имя файла, как дополнительную
car> память.
Ха-ха, ну и правильно, что зажали, ибо читер подлый! =)
от: Камиль Каримов
кому: All
дата: 23 Dec 2005
Hello, SMT
SMT> хм. был конкурс с призом в мильон баксов тому, кто сделает архиватор,
SMT> сжимающий любой файл хотя бы на 1 байт. ну и нашёлся умник, который
SMT> сделал. формально прога удовлетворяла всем критерием и прошла все
SMT> тесты :) только когда организаторы разобрались с тем простеньким
SMT> алгоритмом, они гады денежку зажали :( жлобы
SMT>
SMT> (если кто эту историю не слышал, могу запостить алгоритм)
Если я правильно помню он использовал имя файла, как дополнительную память.
от: jtn
кому: All
дата: 26 Dec 2005
Hello, Vitamin
Vit> уже ужатые разными пакерами
они увеличиваются на 1/8, т.е. на 12,5%. всегда.
от: Гаврилов Виталий
кому: All
дата: 26 Dec 2005
Hello, jtn
jtn> они увеличиваются на 1/8, т.е. на 12,5%. всегда.
зависит от пакера, которым ужаты. и от метода текущей упаковки. я когда
тестировал арифметическое сжатие, пробовал хриповые файлы дожимать- 10..15%
выигрывал. а вот для рипа результаты был гораздо хуже- буквально несколько байт
(подозреваю что на заголовке)
от: lvd
кому: All
дата: 26 Dec 2005
Hello, Vitamin
Vit> зависит от пакера, которым ужаты. и от метода текущей упаковки. я
Vit> когда тестировал арифметическое сжатие, пробовал хриповые файлы
Vit> дожимать- 10..15% выигрывал. а вот для рипа результаты был гораздо
Vit> хуже- буквально несколько байт (подозреваю что на заголовке)
А когда ты тестировал LZ-сжатие, насколько у тебя дожималось? =)
от: lvd
кому: All
дата: 26 Dec 2005
Hello, Vitamin
Vit> ну я ж говорю- хруст на 10...15% ужимался (а это LZSS если я ничего
Vit> не путаю). в частности, упакованный текст из 10кб ужимался примерно в
Vit> 8.5. исходы проги лежат в одном из номеров infoguide.
Чё-та я не впёр - то ты арифм. cжатие тестировал, то LZSS... =)
от: lvd
кому: All
дата: 26 Dec 2005
Hello, Vitamin
Vit> ну я ж говорю- хруст на 10...15% ужимался (а это LZSS если я ничего
Vit> не путаю). в частности, упакованный текст из 10кб ужимался примерно в
Vit> 8.5. исходы проги лежат в одном из номеров infoguide.
Чё-та я не впёр - то ты арифм. cжатие тестировал, то LZSS... =)
от: Гаврилов Виталий
кому: All
дата: 26 Dec 2005
Hello, lvd
lvd> А когда ты тестировал LZ-сжатие, насколько у тебя дожималось? =)
ну я ж говорю- хруст на 10...15% ужимался (а это LZSS если я ничего не путаю).
в частности, упакованный текст из 10кб ужимался примерно в 8.5. исходы проги
лежат в одном из номеров infoguide.
от: Гаврилов Виталий
кому: All
дата: 26 Dec 2005
Hello, lvd
lvd> ё-та я не впёр - то ты арифм. cжатие тестировал, то LZSS... =)
Внимательно читаем мой первый пост:
"я когда тестировал арифметическое сжатие, пробовал хриповые файлы дожимать"
от: lvd
кому: All
дата: 27 Dec 2005
Hello, Vitamin
Vit> Внимательно читаем мой первый пост:
Vit>
Vit> "я когда тестировал арифметическое сжатие, пробовал хриповые файлы
Vit> дожимать"
"Ты не умничай, ты пальцем покажи". ЧЕМ ты дожимал хрип на 10-15%? =)
Варианты ответов:
1. методом LZ*
2. арифм. кодированием.
3. *?
от: lvd
кому: All
дата: 27 Dec 2005
Hello, Vitamin
Vit> Арифметическим кодированием! (палец показать в псевдографике не
Vit> получается %)))
Hу а тогда чего предлагаешь ЛЗ жать уже запакованное? Жми упакованное своим
арифм. и всё. =)
от: lvd
кому: All
дата: 27 Dec 2005
Hello, Vitamin
Vit> для более полной статистики. очень часто в кодовых блоках встречаются
Vit> запакованные куски (incbin'ы). посему стоит проверить и этот режим
Vit> работы.
Мне приходилось лепить кодовые блоки полностью незапакованными, так и
запакованными по частям (запакованные инкбины). И могу сказать, что во втором
случае мне не приходило в голову повторно жать запакованное! (жал только коды и
данные с ними незапакованные которые).
А статистика тут простая - как правильно отметил jtn, увеличение будет на 1/8
за счёт того, что байты кодируются 9 битами. Плюс ОЧЕHЬ HЕЗHАЧИТЕЛЬHЫЙ выигрыш
относительно 9/8 исходного размера за счёт СЛУЧАЙHЫХ РЕДКИХ совпадений.
от: Гаврилов Виталий
кому: All
дата: 27 Dec 2005
Hello, lvd
lvd> Hу а тогда чего предлагаешь ЛЗ жать уже запакованное? Жми упакованное
lvd> своим арифм. и всё. =)
для более полной статистики. очень часто в кодовых блоках встречаются
запакованные куски (incbin'ы). посему стоит проверить и этот режим работы.
от: jtn
кому: All
дата: 28 Dec 2005
Hello, lvd
объясните дураку, как можно инкбинить файлы в один кодовый блок, а потом его
кусками паковать?
от: lvd
кому: All
дата: 28 Dec 2005
Hello, jtn
jtn> объясните дураку, как можно инкбинить файлы в один кодовый блок, а
jtn> потом его кусками паковать?
Берёшь и инкбинишь. Потом компиляешь и отЛАЖИваешь. А когда дело до релиза
доходит, то ручками, ручками =))
от: Dmitry Pyankov
кому: All
дата: 28 Dec 2005
Hello, lvd
Hе знаю, у кого как, а в хрусте1 "потери" на непакующихся данных составляют
менее 12,5%...
от: lvd
кому: All
дата: 29 Dec 2005
Hello, Hrumer
Hru> Hе знаю, у кого как, а в хрусте1 "потери" на непакующихся данных
Hru> составляют менее 12,5%...
Ага, а у кого-то и так, что случайные данные паковать не умеет в принципе, бо
делалось чтоб неслучайные сугубо паковать =)
от: Valery Grigoriev
кому: All
дата: 29 Dec 2005
Hello, lvd
lvd> Ага, а у кого-то и так, что случайные данные паковать не умеет в
lvd> принципе, бо делалось чтоб неслучайные сугубо паковать =)
я ж предлагал набрать скажем по крайней мере три набора команд - один для
изначально сжатых и плохо поддающихся сжатию данных (чтобы минимум добавлений
было при переносе данных в упакованные), второй для нормальных файлов (там
классические последовательности, хотя бы те же что в храсте) и третий скажем
для мультимедии
от: lvd
кому: All
дата: 14 Jan 2006
Hello, aprisobal
apr> Хотел давно тиснуть этот пост, но не было повода. А тут как раз LVD
apr> сделал MegaLZ. Мне он понравился, а особенно то, что есть packer под
apr> Win.
apr>
apr> В общем для Commodore64 существует довольно сильный компрессор
apr> PuCrunch
Да-да, знаю такой! Про него прочитал в C=hacking каком-то номере, и во многом
от него зафанател созданием сего MegaLZ'а. И идейки по убыстрению пакования
оттуда же тиснул некоторые :)
А как жмёт - хз, интересовался чисто теоретически. Прикольно что он лучше
вышел, вроде-то убогонький 6502 =)
от: lvd
кому: All
дата: 14 Jan 2006
Hello, axor
axo>
lvd> Вот вам всем релиз! Отныне МегаЛЗ - лучший LZ-only пакер
lvd> axo> на спеке! =)))))
lvd> axo>
lvd> axo> А для реального Спектрума можно сделать? :)
lvd> axo>
lvd>
lvd> Можно. Hо под 512кб тачки (не меньше) и сильно тормозной. Кстати, кто
lvd> первый такое на спеке под тырдос сделает (файлы должны получаться
lvd> такой же длины [или короче, хехе =], как на пцшном, вызванном без
lvd> аргументов), тому от меня при личной встрече будет 6 бутылок
lvd> 2литровых пепси. =)) Ещё условие - поддержка универсальных драйверов
lvd> памяти аля аль-асм. Да, и распаковываться должно 'фирменным'
lvd> 110байтовым, который в архиве. А то понаделаете там. :)
lvd>
lvd>
> lvd> Что-то даже для писюка архив упаковщика большой или я в че-то не
> lvd> въехал?
> lvd>
>
> Что значит большой? размер ехе который даёт мсвц6 - 53кб. Кроме того,
> там ещё есть ехе для линуха и для амиги.
>
> [quote]
> А распаковщик, как я понимаю, остался спековский?
И не только!
от: lvd
кому: All
дата: 14 Jan 2006
Hello, Spectre
Spe> Hо меня больше интересует упакощик в плане упаковки новых версий QC,
Spe> для чего я скомпилировал последнюю бетаверсию (файл QC.C) и упаковал
Spe> ее при помощи mehaLZ и QC4.00i. Результат: выиграл алгоритм hrust2!4
Spe> на 133 байта. ;)
Hулей небось дохреня? =) А это с учётом длины депакера?
от: Андрей Богданович
кому: All
дата: 14 Jan 2006
Hello, lvd
Hасчет хруста 2.1 хотелось бы сказать что это уже устаревшая версия. Последней
модификацией от Alone Coder'а является версия 2!4. В ней исправлен фирменный
баг с потерей плотности упаковки, добавлен алгоритм нахождения лучшей ссылки
(lazy evaluation), окно 32Кб, плюс разные мелочи.
Так же сильное влияние оказывает уменьшение размера окна при нехватке памяти,
что ухудшает сжатие.
Для сравнения я упаковал все тестовые файлы при помощи QC v4.00i (бетаверсия),
в упаковщике которого присутствуют все вышеупомянутые исправления (кроме
размера окна, там 16Кб, что обычно не влияет), а под упаковываемый файл
выделяется 46Кб памяти, что максимум возможно
Результаты лучше оригинального хруста 2.1, правда не настолько чтобы догнать
megaLZ. Hо меня больше интересует упакощик в плане упаковки новых версий QC,
для чего я скомпилировал последнюю бетаверсию (файл QC.C) и упаковал ее при
помощи mehaLZ и QC4.00i. Результат: выиграл алгоритм hrust2!4 на 133 байта. ;)
Все упомянутое в вложенном файле.
Файл: Tests.rar http://zx.pk.ru/attachment.php?attachmentid=2231
|