Разница: LZ77 против LZ4 против lz4hc (алгоритмы сжатия)?

формате LZ4 построено для того чтобы обжать быстро, на сотнях MB/s в сердечник. Это подходит для приложений, где вы хотите, чтобы сжатие было очень дешевым: например, вы пытаетесь сделать формат сети или на диске более компактным, но не можете позволить себе тратить кучу времени процессора на сжатие. Это в семье с, например,быстро и ЛЗО.

естественной точкой сравнения является zlib алгоритм deflate, который использует сжатие LZ77 и кодирование Хаффмана и используется в gzip.ZIP и .Форматы PNG и слишком много других мест для подсчета.

эти быстрые компрессоры отличаются потому что:

1. они используют код обнаружения повторения, который быстрее (часто простой hashtable без обнаружения столкновений), но не ищет несколько возможных совпадений для лучшего (что займет время, но приведет к более высокому сжатию) и не может найти некоторые короткие матчи.
2. они только пытаются сжать повторения во входных данных-они не пытаются воспользоваться тем, что некоторые байты более распространены, чем другие.
3. тесно связанные с 2, они генерируют байты вывода за один раз, а не биты; позволяя кодам фракции байта иногда позволять больше сжатия, но для кодирования и декодирования потребуется больше операций процессора (потенциально бит-сдвига, маскировки и ветвления).
4. много практической работы делая их реализации быстрыми на современных процессорах.

для сравнения, DEFLATE получает лучшее сжатие, но сжимает и распаковывает медленнее, а алгоритмы высокого сжатия, такие как LZMA, командой bzip2, LZHAM или кодом Brotli как правило, занимает еще больше времени (хотя Brotli при его более быстрых настройках может конкурировать с zlib). Существует много вариаций среди алгоритмов с высоким сжатием, но в целом они имеют тенденцию фиксируйте избыточность на больших расстояниях, используйте контекст для определения вероятных байтов и используйте более компактные, но медленные способы выражения результатов в битах.

LZ4HC-это вариант LZ4 с "высоким сжатием", который, я считаю, изменяет точку 1 выше-компрессор находит более одного соответствия между текущими и прошлыми данными и ищет наилучшее соответствие, чтобы гарантировать, что выход мал. Это улучшает сжатие соотношение но понижает сжатие скорость по сравнению с LZ4. Однако скорость декомпрессии не повредит, поэтому, если вы сжимаете один раз и распаковываете много раз и в основном хотите чрезвычайно дешевую декомпрессию, LZ4HC будет иметь смысл.

обратите внимание, что даже быстрый компрессор может не позволить одному ядру насыщать большой объем полосы пропускания, как это предусмотрено SSDs или быстрыми ссылками в центре обработки данных. Есть еще более быстрые компрессоры с более низкими коэффициентами, иногда используемые для временно упаковать данные в ОЗУ. WKdm и плотность есть два таких компрессора; одна черта, которую они разделяют, действует на 4-байтовый машина слова ввода за один раз, а не отдельных байтов. Иногда специализированное оборудование может достичь очень быстрого сжатия, как в чипы Exynos от Samsung или технология QuickAssist Intel.

Если вы заинтересованы в сжатии больше, чем LZ4, но с меньшим временем процессора, чем deflate, автор LZ4 (Yann Collet) написал библиотеку под названием Zstd; при его стабильном выпуске,Facebook написал о том, как они используют его. Он использует конечные автоматы, не коды Хаффмана, для энтропийного кодирования; я не эксперт в этом, но, по крайней мере,алгоритм подробно описан в RFC. The самые быстрые режимы zstd теперь приближаются к LZ4 в соотношении и скорости. Apple написал lzfse на аналогичных принципах. Несколько лет назад, Google опубликовал библиотеку под названием gipfeli, хотя он, казалось, не набрал много тяги. Есть также проекты, направленные на более быстрое сжатие в формате Zlib, например SLZ и патчи для zlib от CloudFlare и Intel.

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

Если задержка, а не Общее время процессора является вашей главной проблемой, и вы сжимаете один длинный поток, есть инструменты для параллельного сжатия, например pigz и -T опция threading для инструмента командной строки zstd. (Есть различные экспериментальные пакеров там тоже, но они существуют больше для того чтобы нажать границы на скорости или плотности, а не для пользы сегодня.)

таким образом, в целом, у вас есть довольно хороший спектр альтернативных компрессоров для разных приложений: LZ4 (или даже более слабые компрессоры памяти) для сжатия в реальном времени, выкачивают как старый стандарт для сбалансированного сжатия и Zstd как активно разработанная новая альтернатива, и brotli и другие для высокого сжатия. По мере продвижения от LZ4 через DEFLATE к brotli вы прикладываете больше усилий для прогнозирования и кодирования данных и получаете больше сжатия за счет некоторой скорости.