Hacker News Digest

Сжатие данных — это предсказание.
Алгоритмы сжатия достигают предела энтропии, используя предсказание следующего символа на основе контекста. Современные LLM оптимизируют кросс‑энтропию, что делает их одновременно мощными предсказателями и потенциальными сжатылями.

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

Запомните: сжатие и предсказание — две стороны одной математической медали.

Сжатие и предсказание эквивалентны при совпадении распределений обучающих и тестовых данных; при обобщении на другие support эта эквивалентность теряется. LLM — это оптимизированный алгоритм сжатия, обученный на больших данных, генерирующий «новые идеи» как побочный эффект сжатия через вероятностное моделирование, а не через понимание. Сжатие — не просто подсчёт, а моделирование распределения (например, арифметическое кодирование), что делает его математически эквивалентным предсказанию. Низкая энтропия позволяет высокое сжатие — фундаментальный принцип теории информации. Сжатие тесно связано с коррекцией ошибок: сжатые данные чувствительны к искажениям, так как каждый бит несёт больше информации. LLM можно рассматривать как «весь интернет, сжатый в один архив» с интеллектуальной системой запросов. Сжатие — не только предсказание, но и абстракция; декомпрессия — экстраполяция. Сжатие и индексация — две стороны одного процесса: выявление повторяющихся структур, образуя триаду: сжатие, предсказание, индексация. Все статистические модели — компрессоры; термины «модель» и «компрессор» взаимозаменяемы, включая эмбеддинги и энкодеры. LLM воспроизводят только правдоподобные токен-последовательности, исключая маловероятные. Споры: @qarl2 считает сжатие пониманием, @Lerc — что компрессоры могут кодировать паттерны без последовательного предсказания, ставя под сомнение эквивалентность; @caust1c утверждает, что сжатие — воспроизведение, а не предсказание; @jjk166 считает математическую эквивалентность тривиальной, а не удивительной. Для понимания LLM полезно рассматривать их как системы сжатия, а не как «думающие» агенты — это снимает иллюзии понимания и фокусирует на статистической природе. Оптимизация процессов — единственный путь к глубокому пониманию; медленное ПО — признак непонимания.

OpenZL — это новый фреймворк для сжатия структурированных данных с открытым исходным кодом, разработанный Meta. Он обеспечивает сжатие без потерь, достигая производительности специализированных компрессоров, но при этом использует единый универсальный декомпрессор. Ключевая идея в том, что данные имеют предсказуемую структуру — колоночную, перечисления, повторяющиеся поля — и OpenZL явно использует это знание, применяя конфигурируемую последовательность преобразований для выявления скрытых закономерностей.

Фреймворк устраняет компромисс между эффективностью формато-специфичных решений и простотой поддержки общего инструмента. В отличие от универсальных методов, которые тратят ресурсы на угадывание структуры, OpenZL заранее знает тип данных и фокусируется только на релевантных трансформациях. Это позволяет экономить вычислительные циклы и улучшать соотношение скорости к степени сжатия. Практический вывод: один бинарный инструмент может заменить множество кастомных компрессоров без потери производительности.

• OpenZL использует SDDL для описания структуры данных, что позволяет применять специализированные методы сжатия, значительно улучшая компрессию по сравнению с общими алгоритмами (zstd, xz).
• Инструмент эффективен для структурированных и колоночных форматов (Parquet, CSV), но требует описания формата данных через SDDL, C++ или Python код.
• Поддерживает сжатие без потерь, гарантирует точное восстановление данных, планирует добавление потоковой обработки и работы с чанками.
• Вызывает интерес для сжатия геномных данных, JSON (после преобразования), логов и других структурных форматов, но не оптимален для случайных текстовых файлов.
• Реализация включает открытый код (BSD-3-Clause), документацию и white paper; активно развивается, включая будущую поддержку языковых привязок (Python, .NET).

Режим --long в Zstandard значительно улучшает сжатие геномных последовательностей, но требует удаления символов новой строки внутри записей.

Специализированные методы сжатия ДНК, такие как MiniPhy, достигают коэффициента сжатия (CR) 91, но работают медленно. Zstandard со стандартными настройками сжимает в 10 раз быстрее, но с CR всего 3.

Использование --long без удаления переносов дало скромное улучшение — CR 3.8. После удаления переносов (seqtk seq -l 0) CR вырос до 11. С максимальным размером окна (--long=31) CR достиг 31, уменьшив размер данных с 2.46ТБ до 80ГБ при увеличении времени сжатия на 80% по сравнению со стандартными настройками.

Хотя --long не дотягивает до специализированных методов, он предлагает хороший баланс между скоростью и эффективностью сжатия для больших файлов с повторяющимися последовательностями. Главное — предварительно удалить переносы строк.

• Удаление незначащих переносов строк в формате FASTA значительно улучшает сжатие Zstd, так как они нарушают поиск длинных совпадений.
• Zstd — байтовый компрессор, не учитывающий семантику данных, поэтому случайные переносы строк снижают его эффективность.
• Использование больших размеров окна (--long) в Zstd улучшает сжатие геномных данных, но требует больше памяти и совместимых настроек при распаковке.
• FASTA и FASTQ критикуются как неэффективные форматы, но остаются популярными из-за простоты и широкой поддержки.
• Для обработки больших геномных данных часто рекомендуется конвертировать FASTA/FASTQ в бинарные или колоночные форматы (например, Parquet).
• Создание специализированных словарей или препроцессинг данных могут значительно улучшить сжатие для специфичных структур.
• Геномные данные обладают высокой избыточностью из-за общих последовательностей у разных видов, что эффективно используется компрессорами.
• Многие инструменты биоинформатики используют внутренние бинарные форматы, но FASTA остаётся стандартом для обмена данными.
• Проблемы с устаревшими форматами и инструментами в биоинформатике частично связаны с трудностями финансирования их поддержки.

• В 70‑х некоторые системы (например, PDP‑10) имели 9‑битовые байты, но стандарт закрепился за 8 битами. Если бы байт был 9‑битным, ряд исторических случайностей сыграли бы нам на руку.

• IPv4: при 9‑битовых байтах адрес IPv4 был бы 36‑битным (~64 млрд адресов). Этого хватило бы до 2030‑х без массового NAT и тормозов с IPv6; позже проблему решили бы мягкими рыночными механизмами.

• UNIX time: 32‑битные метки ломаются в 2038, а 36‑битные прожили бы до 3058. Отрицательные охватывали бы времена с 882 года — достаточно для исторических нужд.

• Юникод: вместо 16‑битных 65 тыс. символов было бы 18‑битных 262 тыс. — хватило бы без болезненной унификации CJK; сейчас всех символов ~155 тыс. UTF‑9 стал бы скорее компрессией и уступил бы GZip; либо однобайтно‑двухбайтная схема при умеренной экономии на эмодзи.

• Указатели и память: 36‑битные ОС дали бы до 32 ГБ на процесс (вместо 2 ГБ у 32‑битных). Серверы всё равно виртуализируют; меньшие указатели экономят память и ускоряют код, хотя строки стали бы длиннее — общий баланс близок к нулю.

• Прочие выигрыши:

  • 18‑битные AS‑номера не иссякли бы; порты/PID/UID просторнее.
  • Кодирование инструкций x86/A64 чуть опрятнее; Thumb работал бы лучше.
  • Полуточные 18‑битные числа прижились бы раньше; экзотика 4–5 бит не взлетела бы.
  • Расширенный ASCII влез бы с греческим и стал бы «натовской» кодовой страницей; UTF‑9 привилегировал бы почти всю Западную Европу.
  • Права Unix умещались бы в один байт (без «липких» битов). Оctal стал бы нормой вместо hex.
  • 18‑битный цвет 6/6/6 даёт различия на грани восприятия; потеря альфа‑канала неприятна.

• Издержки? Существенных нет: адресация по битам не используется; деления на девять не требуется; размеры страниц/блоков ОС могли бы остаться прежними, ядру не пришлось бы менять основы работы.

• Обсуждение крутится вокруг гипотетического мира с 9-битными байтами: часть участников отмечает аппаратную неудобность непоказательных (не 2^n) размеров и сложность для мультипликаторов, адресации и сдвигов.
• Скептики считают аргументы «добавим по одному биту и всё станет лучше» натянутыми: решения о размерах всё равно принимались бы иначе, а выигрыш в 12.5% не компенсирует издержки и усложнение.
• Приводятся исторические примеры: PDP-8/10 с 12/36-битными словами, 6-битные коды, термин «octet» для однозначности; упоминается даже N64 с «внутренними» 9-битными байтами для GPU.
• По сетям: 36-битный IPv4 дал бы ~64 млрд адресов, но это лишь отсрочка дефицита; проблемы ASLR и безопасности 32-битной адресации 36 битами решаются слабо, переход на 64 бита всё равно был бы.
• Есть идеи альтернатив: 10-битные байты, тернарные системы, 9-й бит как признак продолжения для варинтов/инструкций, либо как служебный (ECC/контроль/метка данных).
• Отмечают экономику кремния: лишние провода/логика удорожают дизайн; если уже расширять шину, логичнее идти к степеням двойки (например, к 16 битам на «байт»).
• Итоговый тон дискуссии: 9 бит могли бы немного смягчить отдельные «почти-не-хватает» пороги (16/32-бит), но в целом это привнесло бы больше сложностей, чем пользы; ключ — лучше прогнозировать размеры, а не «маскировать» ошибки лишним битом.