GPU LZ77 decode на H100 упирается не туда, куда обычно смотрят. В этом разборе главный ключ — GPU LZ77 decode, а вопрос простой: что именно делает декодирование последовательным, и что из этого реально можно убрать.
Проблема возникает не на уровне copy, как часто предполагают, а на уровне parse. На четырёх корпусах parse удерживает 63.7–71.5% времени device-resident decode, поэтому ускорение нужно искать именно там. Это важный сдвиг в модели: если оптимизировать не тот слой, throughput почти не меняется, даже если сама копия выглядит дорогой.
Авторы сравнивают три decoder architectures, потому что каждая подсвечивает свой ограничитель. Dense full-pipe, wavefront и v7-RA seek показывают, что разные механизмы сериализации живут на разных уровнях: parse, depth, token count. Такой разбор полезен именно для архитекторов, потому что он отделяет системный bottleneck от привычной, но неверной гипотезы о “сложной копии” как главной причине.
Решение здесь тоже не одно. Во-первых, back-reference chain depth можно ограничить на этапе encode, и это почти не меняет compression ratio: cost составляет 0.006% по сравнению с базой. Во-вторых, self-overlapping matches оказались не цепочкой зависимостей, а periodic fills, то есть их можно распараллелить без потери bit-perfect correctness. Это меняет саму схему исполнения: вместо искусственной сериализации появляется параллельная match layer.
Практический trade-off при этом честный. Depth cap даёт выигрыш только там, где depth действительно формирует latency, и почти не влияет на spike cluster: byte-level comparison всех 15,499 blocks показал, что cap меняет 16 blocks, а в cluster из 181 blocks не меняет ничего. Значит, для этого участка latency cap бесполезен. Это хороший пример того, как измерение ломает интуицию: не вся глубина в parse превращается в задержку.
Реализация строится на encode-time absolute offset parse. ACEAPEX хранит back-reference как absolute position, а не относительное смещение в sliding window. Из-за этого block decode начинается, как только готовы блоки-источники. Формат хранит four streams per block: literals, lengths, absolute offsets и commands. Это даёт block independence, но сохраняет другой sequential element — four-entry distance history, который уже можно убрать на стороне encoder.
Именно здесь появляется самый жёсткий компромисс. Удаление distance history убирает последний genuinely sequential элемент, но стоит 0.540% ratio. Зато dependency-free parse run растёт с 4 commands до 706. Для системного инженера это понятный обмен: немного compression efficiency в обмен на более простой граф зависимостей и более предсказуемый decode path.
Отдельно важен memory floor. Даже после устранения sequential parts остаётся проблема granularity. На chr1 median match равен 7 bytes при 128-byte cache line, поэтому bus efficiency составляет 4.4%. Coalesced write того же объёма измерен как 39× faster. Это показывает, что часть ограничения уже не алгоритмическая, а физическая: слишком мелкие записи плохо ложатся на шину.
На random access картине это видно особенно ясно. Для 50 GB archive позиция внутри файла почти не меняет время: decode one 16 KB tile колеблется в диапазоне 292.6–386.6 µs, то есть около ±14% вокруг 344 µs. Это не bit-perfect comparison, потому что original is not on disk, но позиционная стабильность измерена. Иначе говоря, формат даёт адресуемость, но не отменяет цену каждого мелкого блока.
Итог у исследования прагматичный. Главная последовательность в GPU LZ77 decode сидит не в copy, а в parse. Depth cap почти бесплатен, self-overlap можно распараллелить, а последний sequential element можно убрать ценой небольшой потери ratio. Но после этого остаётся ещё один предел — memory traffic, и именно он определяет нижнюю границу ускорения.
Источник информации
arXiv — крупнейший открытый репозиторий препринтов (с 1991 года, под эгидой Корнелла), где исследователи оперативно размещают рабочие версии статей; материалы общедоступны, но не проходят полное рецензирование, поэтому результаты следует считать предварительными и, по возможности, сверять с обновленными версиями или рецензируемыми журналами. arxiv.org