Rápido
Análise LZ gulosa, sem etapa de entropia. Para quando a latência de compressão importa mais que a densidade máxima.
VV_MODE_ULTRA_FASTRelease 2.65.11
Formato aberto · implementação compacta
Compressão,sem caixa-preta.
VaptVupt é um codec de compressão LZ + tANS escrito em C11: zero dependências externas de runtime, formato de arquivo documentado e decodificadores de referência byte a byte em Python e JavaScript.
Feito para quem integra e quer uma fronteira de codec pequena e auditável — não como substituto universal para todo compressor.
2.65.11release atual
3modos de compressão
16 MiBjanela máxima
0dependências externas
01 / Codec
Um formato.
Três prioridades.
O modo muda como o codificador procura e precifica correspondências. Não cria três formatos incompatíveis: o decodificador lê o fluxo, não o preset escolhido.
Balanceado
O padrão. Um parser lazy e escolhas de entropia por bloco buscam um compromisso prático entre razão e velocidade de decode.
VV_MODE_BALANCEDExtremo
Caminho de parse ótimo e busca profunda para priorizar razão. A compressão é deliberadamente mais lenta e pode usar bem mais memória.
VV_MODE_EXTREME02 / Evidência
Medição
com contexto.
O perfil atual de páginas compara contextos fornecidos pelo chamador no mesmo processo, com entradas de 4, 16 e 64 KiB. A tabela mostra o subconjunto ilustrativo de texto sintético de 4 KiB; a execução completa cobre 216 perfis e confere cada página descomprimida.
| API | Razão | Compressão p50 µs | Descompressão p50 µs | Compressão MB/s | Descompressão MB/s | Estado em bytes |
|---|---|---|---|---|---|---|
| Contexto FAST do VaptVupt fornecido pelo chamador | 2,868 | 62,536 | 9,206 | 65,7 | 486,2 | 537.800 |
| LZ4 extState | 2,454 | 12,636 | 2,851 | 339,6 | 1495,0 | 16.416 |
| Contexto Zstd, nível 1 | 4,927 | 42,057 | 13,337 | 99,4 | 320,1 | 169.752 |
Proveniência: código medido da v2.65.11 no commit
a14e09f54c2d; Intel Core i7-13700HX, Linux 7.2.3, GCC 14.3, fixado na CPU 4. O VaptVupt usou o caminho escalar portátil sem vetorização automática do compilador; LZ4 1.10.0 e Zstd 1.5.7 foram usados por suas bibliotecas de espaço de usuário no mesmo processo. A matriz completa usou 64 páginas independentes, 101 amostras de latência e sete amostras em lote por perfil. O framing está incluído e o checksum foi desativado nas três linhas. LZO-RLE e runtime no kernel não estavam disponíveis. O LZ4 é mais rápido aqui e o Zstd gera saída menor; essa evidência não demonstra que o VaptVupt substitui nenhum dos dois. Resultados completos e comandos para reprodução.
| Entrada máxima | Anterior | Atual | Redução |
|---|---|---|---|
| 4 KiB | 1.070.264 | 537.800 | 49,75% |
| 16 KiB | 1.131.752 | 574.712 | 49,22% |
| 64 KiB | 1.377.705 | 722.361 | 47,57% |
Trade-offs preservados: seis compilações pareadas preservaram 2.304 frames byte a byte. A latência em lote da compressão pelo contexto melhorou 31,71% para páginas aleatórias de 4 KiB, 16,22% para registros e 39,13% para dados repetitivos. Texto melhorou apenas 1,07%, com três pares para cada lado. A mesma comparação registrou perda de 2,36% na descompressão em lote de registros de 64 KiB nos seis pares e perda de 12,24% no p95 da descompressão de texto de 4 KiB em cinco.
03 / Compilar e usar
Do código
ao primeiro frame.
O build padrão requer GNU Make e um compilador C11. O codec usa a biblioteca padrão de C e não tem dependência externa de runtime; compressão multithread é opcional.
- Compilar
makeproduz a CLI.make amalggeravaptvupt.cevaptvupt.hpara integração direta. - Verificar
make testexecuta suítes C, casos negativos e as referências Python/JavaScript quando os runtimes estão disponíveis. - Janela
-w 10..24escolhe entre 1 KiB e 16 MiB; zero ou omissão mantém a seleção automática. - ArquivosA CLI grava
.zuptpor padrão e ainda reconhece frames legados.vvpelo cabeçalho.
git clone https://codeberg.org/berkeley/vaptvupt-codec.git
cd vaptvupt-codec
git checkout v2.65.11
make
make test
./vaptvupt -c -m fast -o rapido.zupt entrada
./vaptvupt -c -m balanced -o dados.zupt entrada
./vaptvupt -c -m extreme -o denso.zupt entrada
./vaptvupt -d -o restaurado dados.zupt#include "vaptvupt.h"
vv_options_t opt;
vv_default_options(&opt);
opt.mode = VV_MODE_BALANCED;
size_t cap = vv_compress_bound(src_len);
int64_t n = vv_compress(src, src_len, dst, cap, &opt);
if (n < 0) { /* tratar VV_ERR_* */ }
int64_t m = vv_decompress(dst, (size_t)n, out, out_cap);
if (m < 0) { /* rejeitar o frame */ }Contrato de streaming
vv_cstream_* aceita chunks de origem de até 1 MiB e preserva o histórico de matches. vv_dstream_* aceita chunks comprimidos arbitrários e retém blocos parciais. Mantenha a mesma base do buffer de saída e a capacidade do frame inteiro em todas as chamadas; written permanece cumulativo, inclusive após a conclusão, enquanto consumed vale para cada chamada. A 2.65.11 preserva a correção de reset da 2.65.10 e adiciona verificações de limites no footer, na cauda do checksum e nos spans do decodificador; bytes válidos permanecem compatíveis.
04 / Formato e filtros
Bits portáveis.
Transformações opcionais.
Um frame começa com cabeçalho de 16 bytes, continua com blocos de tipos independentes e pode terminar com footer XXH64. A especificação pública basta para escrever um decoder sem importar a implementação C.
O pré-processamento BCJ reversível opcional pode normalizar alvos de branch x86 ou instruções BL/ADRP AArch64 antes da compressão. Ele pode melhorar a razão em binários adequados; não é criptografia e não muda a fronteira de segurança.
# código executável x86
./vaptvupt -c -m extreme --bcj -o app.zupt app
# código executável AArch64
./vaptvupt -c -m extreme --bcj-arm64 -o app.zupt app
# detectar ELF / PE / Mach-O e escolher um filtro ou nenhum
./vaptvupt -c --auto-filter -o app.zupt appUma arquitetura por frame
Os filtros x86 e ARM64 explícitos são mutuamente exclusivos. As entradas do encoder rejeitam flags contraditórias e valores inválidos de modo de compressão. A CLI também rejeita nomes de modo desconhecidos e opções numéricas malformadas.
05 / Fronteiras
Integridade não é
autenticação.
Compressão pertence a um desenho de confiança maior. Trate o frame e seu checksum conforme o que eles realmente oferecem.
XXH64 ≠ MAC
O footer XXH64 opcional detecta corrupção acidental. Não é autenticador criptográfico e pode ser forjado por um atacante. Um frame .zupt sozinho não fornece confidencialidade nem autenticação; use AEAD ou outro envelope autenticado quando adulteração for relevante.
Decodifique com limites
Aloque a partir de limites confiáveis, informe a capacidade real do destino e rejeite qualquer retorno negativo do decoder. Não tente recuperar dentro de um frame malformado.
Pule só atrás de AEAD
VV_DECOMPRESS_SKIP_CHECKSUM só é apropriado quando uma camada autenticada externa já verificou os bytes comprimidos.
Limite encodes caros
O modo extremo prioriza razão e pode consumir CPU e memória de matcher substanciais. Imponha limites de tamanho, memória e tempo ao comprimir dados controlados por terceiros.
06 / v2.65.11
Contextos limitados.
Spans mais rigorosos.
Este release melhora a preparação para páginas, torna explícita a posse do workspace das tabelas de literais e reforça os limites de ponteiros. O formato e as entradas públicas existentes permanecem compatíveis.
Reutilizar estado entre páginas independentes
Um contexto FAST fornecido pelo chamador cobre entradas independentes de até 64 KiB sem alocação no heap durante a operação. Ele reinicia o histórico em cada chamada e preserva os bytes one-shot correspondentes. Seu workspace de 4 KiB ainda ocupa 537.800 bytes, grande demais para uma proposta confiável de zram por CPU.
Workspace de literais sob controle do chamador
Helpers validados de literais Huffman e ANS aceitam memória alinhada do chamador. Blocos S/T reaproveitam a arena de sequências de 48 KiB, e a construção direta da tabela ANS remove um array temporário de 4 KiB de frames individuais do decodificador. A descompressão do frame completo ainda aloca.
Validar antes de avançar
A capacidade do footer, a cauda do checksum, os spans de entrada e os dois históricos de prefetch AVX2 são verificados antes de avançar ou formar o ponteiro correspondente. O modo rápido com format_v2 agora mantém o match mínimo de quatro bytes dos tokens simples, em vez de emitir dados inválidos.
Testar o núcleo escalar
SIMD=0 desativa intrínsecos e dispatch do codec. make scalar-test executa onze suítes em espaço de usuário. Isso não é uma compilação para kernel: compatibilidade com GPL-2.0-only, remoção da libc, menor memória de contexto, KUnit e integração em runtime continuam pendentes.
07 / Fontes primárias
Audite a alegação.
Leia o código.
Especificação, notas de segurança, medições e decodificadores independentes ficam ao lado da implementação. O release 2.65.11 está espelhado nos quatro forges do projeto.