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




Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Virus - О конкурсе по игре "Вирус 2".
Давайте посмеемся - Первые итоги конкурса. Смешной рассказик "Вредный чайник".
PartyZone - СПРЫГ-2k report.
Обзор игрушек - Обзор новых игровых программ: ARENA
B.B.S. Новости - О работе B.B.S.'ок.

В этот день...   29 марта