Сжатие данных

[ivagor]

Чтобы не засорять тему по средствам разработки решил создать новую. За неделю есть подвижки по нескольким распаковщикам, начну c LZ4.
Решил хакнуть smallz4, чтобы
1) Удобно для 8080 (да и для z80) хранить смещения
2) Убрать заголовок, чтобы его не надо было пропускать или отрезать сторонними программами
В итоге получилось сократить (размер каждого рапаковщика указан в исходнике в комментариях) и ускорить распаковщики. Можно еще сократить на байт все варианты, если разрешить портить упакованные данные (т.е. одноразовая распаковка), но чтобы не захламлять исходники убрал эту фичу.
Предыдущая версия для стандартного smallz4 здесь. Ее тоже можно чуть оптимизировать, но при наличии v4 не вижу смысла выкладывать такой вариант.

[Advertiser]

[ivagor]

Следующий номер программы - zx7. Выкладывал вариант, оптимизированный по размеру. Его удалось еще немного сократить и ускорить. И сделал 2 варианта оптимизированных по скорости, быстрейший из которых вплотную приблизился к распаковщику MegaLZ b2mа (210 байт) все еще выигрывая по размеру.
Относительная скорость распаковки разными вариантами на примере теста устройств:
compact (101/106 байт - одноразовый/многоразовый) - на 49% медленнее MegaLZ
normal (125 байт) - на 17% медленнее MegaLZ
fast (170 байт) - на 7% медленнее MegaLZ

[ivagor]

Лучший по степени сжатия упаковщик для восьмибиток несомненно exomizer. Со времени обновления версии распаковщика для 8080 прошло уже несколько лет, но зато будет сразу много улучшений.
Важный момент - теперь для сжатия нужно использовать версию не ниже 3 (текущая 3.0.1), т.к. все представленные распаковщики требуют опции -P1. Что интересно, еще даже не обновили версии распаковщиков для z80, хотя для z80 есть exoopt для exomizer2.
Второй момент - теперь 2 набора по 4 распаковщика. Два набора соответствуют общим опциям -P1 и -P1 -M255. А 4 варианта внутри наборов соответствуют четырем распаковщикам для z80: "полный", -С, -B, -C -B. Т.е. теперь поддерживаются "простые" и "обратные" распаковщики.
Т.к. версий стало много, поддерживать и оптимизировать для всех них варианты под 8085 и 580ВМ1 нет возможности и я их убрал.
Скорость распаковки очень заметно возросла (на примере теста устройств): "полный" распаковщик на 27% быстрее, простой на 28 %. С -M255 все еще лучше: "полный" на 35% быстрее, простой на 36%. Простые и обратные распаковщики короче. Простые практически всегда быстрее, обратные - в зависимости от файла. Недостаток "простых" и -M255 - несколько худшая степень сжатия.
Требуемые опции сжатия и размеры упаковщиков указаны в комментариях.

[Cheburashka]

Перенес сообщение в тему "Архивирование, сжатие, упаковка"

Ссылка

[ivagor]

Cheburashka, думаю есть соответствующеая спековская тема и распаковщики "только z80" лучше туда. aplib для 8080 я выкладывал.

[Error404]

А упаковщики для них где выложены?

[ivagor]

Большинство упаковщиков (и не только упаковщиков) можно скачать одним архивом здесь (ссылку туда я постил). В некоторых случаях (когда упаковщик свой или новый) упаковщики или ссылки на них приведены прямо в соответствующем сообщении.

[Error404]

Большинство упаковщиков (и не только упаковщиков) можно скачать одним архивом здесь (ссылку туда я постил). В некоторых случаях (когда упаковщик свой или новый) упаковщики или ссылки на них приведены прямо в соответствующем сообщении.

Нет времени сравнивать, но может опытным взглядом оценишь эффективность вот этого пакера (а может она уже известна)? Я им пользуюсь для производства пакованных игр под Альтаир-ДОС (это клон CP/M), убивая сразу несколько зайцев:
- Код игр часто больше размера TPA, а после пакера он всегда туда влезает
- быстро распаковывает, компактный распаковщик (тут субъективное ИМХО, не сравнивал)
- Депакер состоит из двух независимых побайтовых стримов - один стрим на вход и один на выход, что делает очень простой задачу распаковки в страницу памяти, отличную от страницы памяти TPA (как в большинстве случаев и происходит).

[ivagor]

"Все уже сравнили до нас" (с)
В вышеприведенном обзоре BitBuster упоминается. Можно сказать, что он "устарел", т.к. есть два его наследника: zx7 и Pletter5. Не хочу пересказывать обзор, лучше там посмотреть, есть варианты более эффективные по степени сжатия, есть более быстрые, есть более компактные распаковщики. В зависимости от приоритетов по тому обзору можно выбрать подходящий упаковщик/распаковщик для z80.
Для 8080 все примерно аналогично, только я не все распаковщики конверснул в 8080 и не вижу в этом необходимости. Самое сильное сжатие (и медленная распаковка) - exomizer, послабее/побыстрее - aplib, еще слабее/быстрее - megalz/zx7, самый слабый/быстрый - lz4. Самый маленький распаковщик (+ еще плюшки) - zx7mini. Надо бы выложить слегка оптимизированный вариант распаковщика megalz b2ma, если нужен сбалансированный вариант и не нужны рекорды (по степени сжатия, по скорости, по размеру распаковщика) то он близок к оптимуму.

[ivagor]

Лучший по степени сжатия упаковщик для восьмибиток несомненно exomizer.

Лучше поздно, чем никогда. introspec в своем обзоре почему-то обошел стороной Real Information Packer и спековский rar/unrar. Судя по описанию RIP уступает RARу, поэтому попробовал только RAR. Упаковал с использованием писишного RARa 2.50, распаковал спековским UNRARом - все сработало, файл совпал с исходным.
RAR (по крайней мере с режимом сжатия Best) совсем чуть-чуть, но превосходит exomizer по степени сжатия, поэтому должен признать, что exomizer не лучший упаковщик для восьмибиток. Скорость распаковки не сравнивал.
Вряд ли кто-то будет переделывать unrar для 8080 (я точно не собираюсь), поэтому для вектора exomizer остается лучшим упаковщиком на обозримую перспективу.
RIP, RAR и exomizer насколько я понял очень похожи по "принципу действия" и есть шанс, что будущие версии exomizera станут жать чуть сильнее и обойдут RAR 2.x.