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

[Eugene85]

b2m, хоть бы ссылку на форум дали

[Advertiser]

[ivagor]

Возможно у кого-то возникнет вопрос "а как же zx1?". Он распаковывает быстрее zx0, но
1. По степени сжатия соревнуется с megalz с переменным успехом
2. Немного не догнал megalz b2m по скорости (хотя небольшой резерв есть)
3. Размер распаковщика несколько больше, чем у zx0, и пришлось использовать самомодифицирующийся код. Тем не менее почти двукратная разница с megalz по этому параметру, это плюс. Но zx0 то еще компактнее и сжимает сильнее, а проигрыш по скорости на мой взгляд не такой принципиальный. Если важна именно скорость при близком к megalz и zx1 сжатии, то есть lzsa2.

[b2m]

b2m, хоть бы ссылку на форум дали

Та ради Бога: http://www.nedopc.org/forum/viewtopi...159208#p159208

Но ноги растут вот отсюда: https://hype.retroscene.org/blog/933.html

[ivagor]

Переосмыслил, доработал и выложил распаковщик ZX1 для 8080.
1. Разогнал до "быстрее megalz".
2. Убрал самомодифицирующийся код.
3. Внимательно перепроверил степень сжатия с учетом размеров распаковщиков (распаковщик ZX1 на 79 байт, т.е. более чем на треть, короче megalz). Оказалось, что там, где zx1 проигрывает megalz, это более чем компенсируется компактным распаковщиком. А вот там, где zx1 сжимает лучше, выигрыш может быть гораздо более заметным (в отдельных случаях до нескольких килобайт!). В итоге по степени сжатия в этой паре безоговорочная победа у zx1.

Обновленная шкала упаковщиков/распаковщиков общего назначения для 8080 от быстрых к сильно сжимающим: lzsa1 - lzsa2 - zx1 - zx0
Еще один момент - у всех перечисленных распаковщиков есть прямой и обратный варианты (у megalz только прямой).

MegaLZ хороший упаковщик и распаковщик b2mа в свое время поднял планку и задал ориентир для подражания на платформе 8080, но современные еще лучше.

[ivagor]

обобщенный zx7 от автора zx0

Поправка - оригинальный zx7 от автора zx0 (Einar Saukas), а автор обобщенного - Antonio Villena.

[ivagor]

Немного оптимизировал распаковщики ZX0 и ZX1

[ivagor]

Еще ускорил и сократил распаковщики zx0 (теперь и прямой и обратный меньше 100 байт) и особенно zx1.

[ivagor]

Сегодня можно отметить день оптимизации распаковщиков.
ZX0 - на байт короче и чуть быстрее.
Успехи в оптимизации ZX0/1 мотивировали вернуться к LZSA. Т.к. LZSA по степени сжатия не соревнуется с ZXами, сосредоточился на их сильной стороне - скорости.
LZSA2:
Стандартный +3 байта, зато обогнал быстрый вариант предыдущей версии.
Быстрый +1 байт и стал еще быстрее.
LZSA1:
Компактный +3 байта, но заметно ускорился.
Быстрый -25 байт! и при этом немного обгоняет предыдущую версию.

[Improver]

ivagor, заглянул в исходники быстрого распаковщика LZSA1 (LZSA1_unlzsa1_fast.asm), сразу заинтересовал один момент:

Исходники

BLOCKCOPY1:
			mov a,m
			stax d
			NEXT_HL
			NEXT_DE
			dcr c
			jnz BLOCKCOPY1
			dcr b
			jz $+6
			jmp BLOCKCOPY1
			pop h

и

BLOCKCOPY2:
			mov a,m
			stax d
			NEXT_HL
			NEXT_DE
			dcr c
			jnz BLOCKCOPY2
			dcr b
			jz $+6
			jmp BLOCKCOPY2
			pop psw

[свернуть]

Почему бы там не сделать так:

Вариант

BLOCKCOPY1:
			mov a,m
			stax d
			NEXT_HL
			NEXT_DE
			dcr c
			jnz BLOCKCOPY1
			dcr b
			jnz BLOCKCOPY1
			pop h

и

BLOCKCOPY2:
			mov a,m
			stax d
			NEXT_HL
			NEXT_DE
			dcr c
			jnz BLOCKCOPY2
			dcr b
			jnz BLOCKCOPY2
			pop psw

[свернуть]

Вроде, будет короче ещё на 6 байт... Или такой вариант приведёт к снижению скорости распаковки?

[ivagor]

Или такой вариант приведёт к снижению скорости распаковки?

Да, так (на типичных файлах) быстрее, т.к. преобладают короткие пересылки. Вариант

Почему бы там не сделать так

есть в zx1, но он там вынесен в отдельную ветку (если занести в основную ветку, то будет медленнее). Проверял lzsa1 с таким же вариантом как сейчас в zx1, было чуть-чуть быстрее, но +7 байт, посчитал, что того не стоит. У меня есть "секретный" мегатурбо вариант lzsa1, он еще быстрее, но большой до такой степени, что счиатю его непрактичным.