Внимательно читаем мой первый пост:Цитата:
Сообщение от lvd
"я когда тестировал арифметическое сжатие, пробовал хриповые файлы дожимать"
Вид для печати
Внимательно читаем мой первый пост:Цитата:
Сообщение от lvd
"я когда тестировал арифметическое сжатие, пробовал хриповые файлы дожимать"
"Ты не умничай, ты пальцем покажи". ЧЕМ ты дожимал хрип на 10-15%? =)Цитата:
Сообщение от Vitamin
Варианты ответов:
1. методом LZ*
2. арифм. кодированием.
3. *?
Арифметическим кодированием! (палец показать в псевдографике не получается %)))Цитата:
Сообщение от lvd
Ну а тогда чего предлагаешь ЛЗ жать уже запакованное? Жми упакованное своим арифм. и всё. =)Цитата:
Сообщение от Vitamin
для более полной статистики. очень часто в кодовых блоках встречаются запакованные куски (incbin'ы). посему стоит проверить и этот режим работы.Цитата:
Сообщение от lvd
Мне приходилось лепить кодовые блоки полностью незапакованными, так и запакованными по частям (запакованные инкбины). И могу сказать, что во втором случае мне не приходило в голову повторно жать запакованное! (жал только коды и данные с ними незапакованные которые).Цитата:
Сообщение от Vitamin
А статистика тут простая - как правильно отметил jtn, увеличение будет на 1/8 за счёт того, что байты кодируются 9 битами. Плюс ОЧЕНЬ НЕЗНАЧИТЕЛЬНЫЙ выигрыш относительно 9/8 исходного размера за счёт СЛУЧАЙНЫХ РЕДКИХ совпадений.
объясните дураку, как можно инкбинить файлы в один кодовый блок, а потом его кусками паковать?
Берёшь и инкбинишь. Потом компиляешь и отЛАЖИваешь. А когда дело до релиза доходит, то ручками, ручками =))Цитата:
Сообщение от jtn
Не знаю, у кого как, а в хрусте1 "потери" на непакующихся данных составляют менее 12,5%...
Ага, а у кого-то и так, что случайные данные паковать не умеет в принципе, бо делалось чтоб неслучайные сугубо паковать =)Цитата:
Сообщение от Hrumer
я ж предлагал набрать скажем по крайней мере три набора команд - один для изначально сжатых и плохо поддающихся сжатию данных (чтобы минимум добавлений было при переносе данных в упакованные), второй для нормальных файлов (там классические последовательности, хотя бы те же что в храсте) и третий скажем для мультимедииЦитата:
Сообщение от lvd
Вот вам всем релиз! Отныне МегаЛЗ - лучший LZ-only пакер на спеке! =)))))
http://lvd.nm.ru/MegaLZ/
Сейчас буду смотреть... Сравнения с hrust1 не представлено :(
Для полноты картины...
http://web.gorny.ru/~hrum/zx/hrusttest/!hrust1.zip
hrust1 отстает в сумме где то на 3килобайта...
[QUOTE=lvd]Вот вам всем релиз! Отныне МегаЛЗ - лучший LZ-only пакер на спеке! =)))))
А для реального Спектрума можно сделать? :)
Что-то даже для писюка архив упаковщика большой или я в че-то не въехал?
А распаковщик, как я понимаю, остался спековский?
Хотел давно тиснуть этот пост, но не было повода. А тут как раз LVD сделал MegaLZ. Мне он понравился, а особенно то, что есть packer под Win.
В общем для Commodore64 существует довольно сильный компрессор PuCrunch - http://www.cs.tut.fi/~albert/Dev/pucrunch/
Коротко о нём:Вот тестдрайв на файлах от MegaLZ_Benchmark - http://lvd.nm.ru/MegaLZ/ на чуть-чуть подправленном PuCrunch (убран заголовок из выходных файлов). Запускался с параметрами -c0 -d -fdeltaЦитата:
Сообщение от http://www.cs.tut.fi/~albert/Dev/pucrunch/
В некоторых тестах PuCrunch выигрывает MegaLZ, а в некоторых проигрывает ему. Очень хорошо жмет текстовые файлы.Код:|Apri_PuCrunch
| |New MegaLZ
| | |Old MegaLZ
| | | |Bitbuster Extreme v0.1
| | | | |HRUST2.1
| | | | | |RIP v0.01
-------+-------+-------+-------+-------+-------+------
code-1 | 12403 | 12654 | 12863 | 12827 | 12865 | 12118
code-2 | 7818 | 7767 | 8034 | 8119 | 8012 | 7689
code-3 | 8257 | 8406 | 8524 | 8181 | 8291 | 7891
-------+-------+-------+-------+-------+-------+------
scrv-1 | 4603 | 4672 | 4724 | 4757 | 4705 | 4551
scrv-2 | 4121 | 4074 | 4148 | 4170 | 4144 | 4030
scrv-3 | 3660 | 3604 | 3688 | 3717 | 3722 | 3544
scrv-4 | 2146 | 2211 | 2314 | 2270 | 2359 | 2165
scrv-5 | 4405 | 4399 | 4479 | 4470 | 4486 | 4298
scrv-6 | 4344 | 4233 | 4324 | 4300 | 4345 | 4129
scrv-7 | 3789 | 3788 | 3899 | 3902 | 3921 | 3721
scrv-8 | 5278 | 5275 | 5340 | 5345 | 5308 | 5139
scrv-9 | 5028 | 4958 | 5043 | 5081 | 5048 | 4844
-------+-------+-------+-------+-------+-------+------
text-1 | 3862 | 3858 | 3986 | 4077 | 4004 | 3726
text-2 | 6748 | 7341 | 7663 | 7766 | 7549 | 6525
text-3 | 9172 | 10252 | 10681 | 11156 | 10360 | 8847
text-4 | 18567 | 20406 | 21417 | 22246 | 20892 | 17334
text-5 | 9478 | 10443 | 10919 | 11225 | 10618 | 9088
Декомпрессор PuCrunch занимает 255байт(после моей небольшой доработки), но не релоцируем. В целом выигрывает у MegaLZ на 1.5кб.
См. в аттаче оригинальный PuCrunch, мною чуть подправленный Apri_Pucrunch+декомпрессор для Alasm'a и запакованные им файлы для сводного benchmark'a.
Да-да, знаю такой! Про него прочитал в C=hacking каком-то номере, и во многом от него зафанател созданием сего MegaLZ'а. И идейки по убыстрению пакования оттуда же тиснул некоторые :)Цитата:
Сообщение от aprisobal
А как жмёт - хз, интересовался чисто теоретически. Прикольно что он лучше вышел, вроде-то убогонький 6502 =)
[QUOTE=axor]Можно. Но под 512кб тачки (не меньше) и сильно тормозной. Кстати, кто первый такое на спеке под тырдос сделает (файлы должны получаться такой же длины [или короче, хехе =], как на пцшном, вызванном без аргументов), тому от меня при личной встрече будет 6 бутылок 2литровых пепси. =)) Ещё условие - поддержка универсальных драйверов памяти аля аль-асм. Да, и распаковываться должно 'фирменным' 110байтовым, который в архиве. А то понаделаете там. :)Цитата:
Сообщение от lvd
Что значит большой? размер ехе который даёт мсвц6 - 53кб. Кроме того, там ещё есть ехе для линуха и для амиги.Цитата:
Что-то даже для писюка архив упаковщика большой или я в че-то не въехал?
И не только!Цитата:
А распаковщик, как я понимаю, остался спековский?
Насчет хруста 2.1 хотелось бы сказать что это уже устаревшая версия. Последней модификацией от Alone Coder'а является версия 2!4. В ней исправлен фирменный баг с потерей плотности упаковки, добавлен алгоритм нахождения лучшей ссылки (lazy evaluation), окно 32Кб, плюс разные мелочи.
Так же сильное влияние оказывает уменьшение размера окна при нехватке памяти, что ухудшает сжатие.
Для сравнения я упаковал все тестовые файлы при помощи QC v4.00i (бетаверсия), в упаковщике которого присутствуют все вышеупомянутые исправления (кроме размера окна, там 16Кб, что обычно не влияет), а под упаковываемый файл выделяется 46Кб памяти, что максимум возможно
Результаты лучше оригинального хруста 2.1, правда не настолько чтобы догнать megaLZ. Но меня больше интересует упакощик в плане упаковки новых версий QC, для чего я скомпилировал последнюю бетаверсию (файл QC.C) и упаковал ее при помощи mehaLZ и QC4.00i. Результат: выиграл алгоритм hrust2!4 на 133 байта. ;)
Все упомянутое в вложенном файле.
Нулей небось дохреня? =) А это с учётом длины депакера?Цитата:
Сообщение от Spectre
А вот тут есть варианты. Если уменьшить окно поиска на #100, то есть до #1000(можно будет использовать "закольцованную" таблицу поиска, как в hrum-hrust) и реализовать алгоритм оптимального подбора пар не для всего файла целиком, а для его фрагментов (размеры фрагмента определяются доступной памятью), то можно попытаться уложиться и в 128К... Замедление где то в 4 раза по сравнению с hrum. На некоторых файлах - до 50 раз, но с использованием спец. алгоритмов можно ускорить процесс. В любом случае, придется искать компромисс между скоростью, качеством паковки и объемом используемой памяти...Цитата:
Сообщение от lvd
Выложите также плиз и проги хруст2!4 и хруст1, которыми вы жали, тут или в емыл (lvd dgap mipt ru). Я выложу всё на урл, где мегалз, если конечно, кто-то не будет против.
Согласен. Но если честно, то МНЕ влом хоть как делать заново MegaLZ на спеке. Всё равно сборка релизов обычно на ПЦ идёт, и взять файл из ТРД, зажать ехещкой и пхнуть обратно - не влом совершенно.Цитата:
Сообщение от Hrumer
А вообще я предложил приз тому, кто это сделает на спеке, так что вперёд! =)) Если результат будет между длиной оригинального МегаЛЗа (или этого с -g) и минимальной - то кол-во бутылок пропорционально уменьшу =)
hrust1 недавно скачивал с zx.da.ru...
Посмотри сам. Файл QC.C прилагался к предыдущему сообщению.Цитата:
Сообщение от lvd
Без. Но длина депакера 207 байт, что длиннее megaLZ только на 97 байт. С приложенными депакерами все равно будет выигрыш на 36 байт. :-PЦитата:
Сообщение от lvd
Исходник hrust 2!4 прилагаю.
Оптимальный LZH: http://zxpress.ru/article.php?id=8538
Вводная статья тут: http://zxpress.ru/article.php?id=8569
Оптимизация по скорости, которой пока нет ни в одном спектрумовском пакере: An improvement on hash-based algorithms for searching the longest-match string used in LZ77-type data compression http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf
Бегло прочитал, правильно ли я понял, что памяти под таблицы надо в ~2 раза больше? Или хитрее?Цитата:
Сообщение от alone