Estou de volta novamente
Lista de conteúdos desta série:
Teoria da Informação e Tecnologia de Compressão: String vs. String de Byte
Mudança de tipo de comprimento variável
Método de compressão de dicionário
Mutilação da cauda
Ultra Pack e o princípio da substituição do espaço-tempo
Metafísica do motor V8
Este artigo é o último da série "Teoria da Informação" (série de conhecimento estranho). Todos os 4 artigos desta série são:
"Informação e entropia: a vida se alimenta de informação" (Noções básicas de teoria da informação)
"Árvore binária ideal e codificação de Huffman" (1 ~ 5 capítulos)
"Procurando os limites da serialização" (Capítulos 6 ~ 11)
"Host, Time and Space Replacement, V8 Metafísica" (Capítulos 12 ~ 16) (este artigo)
12
-
Número real de deslocamento de comprimento variável
O tipo string poda a árvore Huffman de utf8, de modo que todas as folhas se tornem objetos de codificação independentes. Embora uma certa quantidade de tempo seja sacrificada, minUTF8 se torna a codificação de caracteres ideal na teoria da informação. A seguir, estudaremos o esquema de compressão do tipo número real, sim, comprima o número!
Alguém perguntou, como o tipo de número real pode ser compactado? Os complementos e decimais de ponto flutuante definidos pelo IEEE atendem ao máximo os requisitos de armazenamento de números reais e são quase perfeitos. Posso projetar um formato melhor?
Minha ideia de compactação vem dos hábitos de uso das pessoas. Embora eu tenha mencionado anteriormente que não é confiável compactar informações com base em hábitos de uso (mencionei o hábito de usar TypedArray antes), é inegável que existe tal Esse “hábito de uso” é mais antigo e inalterado, ou seja: a frequência de ocorrência de números reais menores é sempre maior do que a de números reais maiores . As pessoas sempre gostam de usar números positivos próximos de 0 para a medição. Por exemplo, Celsius é usado em vez de Kelvin. Números na casa das centenas de milhões e trilhões raramente aparecem. Acho que não preciso provar isso, então, se cada número for um ponto flutuante de 64 bits. Armazenamento é, sem dúvida, um desperdício, então msp fornece um tipo de número real de comprimento variável: números reais em diferentes intervalos ocupam diferentes números de bytes.
Mas o número real de comprimento variável viola o princípio dois.
Tome o número inteiro positivo de comprimento variável como exemplo. Os números inteiros positivos de diferentes comprimentos na figura são armazenados na forma de código original binário. Nas duas faixas de 8 bits e 16 bits, [00000000] e [00000000 00000000] representam o número real 0, o que significa A mesma sequência de bytes, mas diferente, viola o princípio dois.
Como resolver?
A melhor maneira é atualizar o número real de comprimento variável para um número real de deslocamento de comprimento variável . O bit mais baixo de cada comprimento sucede ao bit mais alto do comprimento anterior. Por exemplo, conforme mostrado na figura, cada número real tem que adicionar o valor de deslocamento desta categoria para ser o valor real:
Número inteiro de 8 bits: MIN = 0, MAX = 2 ^ 8-1 = 255
Inteiro de 16 bits: MIN = MAX [上] + 1 = 256, MAX = MIN + 2 ^ 16-1 = 65792
Número inteiro de 32 bits: MIN = MAX [上] + 1 = 65793, MAX = MIN + 2 ^ 32-1
13
-
Método de compressão de dicionário
Bem, os novos formatos de string e números reais alcançaram com sucesso o limite teórico de serialização, mas eles são todos tipos de dados básicos e desafiam o tipo composto: o algoritmo de compressão do dicionário.
Se o dicionário é compressível, em primeiro lugar depende se ele viola os dois princípios anteriores. No msp, o tipo de dicionário armazena cada par de valores-chave na forma de [chave, valor, chave, valor ...] e cada chave ou valor pode ser um tipo básico ou composto.
Para plataforma cruzada, na maioria dos casos, o tipo de "chave" é string, portanto, o campo de tipo pode ser omitido para economizar espaço.
Um elemento é composto principalmente de três partes: tipo, comprimento e conteúdo . O tipo + comprimento constitui um objeto de codificação e o comprimento é o comprimento do conteúdo.
Além disso, na maioria dos casos, os pares de valores-chave não são ordenados e a ordem não faz muito sentido, assim como uma tabela hash. Mas se você organizar pares de valores-chave como json ou msp, sempre estará em ordem. Mesmo se você não usar essa ordem, as informações nesta ordem sempre existirão. Informações = assunto , e as informações ocuparão espaço. Como remover o dicionário A ordem?
A solução é classificar à força os pares de valores-chave.
De acordo com o byte do código de chave de classificação, ou seja, uma cadeia de caracteres como um número inteiro grande , depois pequeno para grande. Na codificação, a posição de cada chave não armazena mais a chave em si, mas sim o "incremento" da chave anterior. Na decodificação, cada chave é obtida acumulando o incremento.
Desta forma, o dicionário classificado ainda está "ordenado", mas a "ordem" neste momento não tem significado, porque a ordem crescente das chaves é 100% certa, e não há outra possibilidade, e a informação é para A incerteza (entropia) é eliminada , de modo que a quantidade de informação fornecida pela própria "sequência" é 0, o que naturalmente não ocupa nenhum espaço.
14
-
Mutilação da cauda
De acordo com a análise acima, strings, números reais e dicionários encontraram seus próprios algoritmos de compressão extrema. Espere, e a lista?
Na verdade, todos que estudaram o front-end sabem que uma lista é um dicionário especial , mas a "chave" da lista é um número natural de 0, 1, 2, 3 ..., não há necessidade de nenhuma otimização para números naturais e o próprio tipo de lista já está serializado O limite.
Até agora, o limite de serialização não foi realizado em um sentido real, porque a sequência de bytes binários de entrada aleatória também precisa considerar o hardware. A menor unidade de memória é um byte, mesmo se o comprimento da sequência de bytes aleatórios for preenchido com um múltiplo de 8. Para considerar um problema mais fundamental: o problema da mutilação da cauda.
O que devo fazer se eu digitalizar EOF, que é o final de todos os dados, e descobrir que o comprimento do último elemento não atingiu o comprimento declarado no prefixo? Neste momento, se um erro for relatado, ele viola o princípio 1 (nunca relate um erro) e não pode ser preenchido com 0, o que viola o princípio 2 (rejeitar redundância).
A maneira que posso pensar por enquanto é remover a parte "comprimento" do prefixo do último elemento, o que é equivalente a usar o resto EOF para implicar o comprimento do elemento. Mas parece que esse método tem muitas armadilhas. Em vista de minhas reservas teóricas e energia limitadas, os detalhes da implementação específica da compressão da cauda são deixados para você.
Desde que terminei o exame de matemática superior do primeiro ano, meu conhecimento básico não melhorou muito. Mais tarde, meu progresso na teoria da computação é totalmente baseado na matemática, física e química que aprendi antes. Sinto vagamente que este dia de aprender novos conhecimentos todos os dias está prestes a terminar. , Assim como a física humana. .
15
-
Ultra Pack
Depois de discutir tantos métodos de compactação, o objetivo do curso é desenvolver um formato de serialização binário melhor, então temos UltraPack, um MessagePack aprimorado, com uma árvore de Huffman bem projetada e um formato perfeito que pode compactar até o limite. A estrutura de dados aprimorada de formatos comuns, como números reais, strings, strings de bytes, listas e dicionários é um código teoricamente ideal!
Embora eu até pense na extensão do arquivo e no tipo mime, o UltraPack é apenas um formato que vive na teoria, pois existem inúmeras dificuldades na implementação e promoção específicas.O chamado "limite" é o limite no sentido da teoria da informação? Difícil de dizer. Embora este projeto não seja atualmente financiado, a equipe está indecisa e o código está temporariamente indisponível, isso não nos impede de provar isso. Viver é o suficiente.
Para isso, também imaginei o editor UltraPack, que permite aos usuários ler / escrever visualmente arquivos de configuração no formato UltraPack, o que aumenta a legibilidade e melhora a segurança, evitando erros gramaticais que podem ocorrer durante a edição do formato do texto.
Em teoria, o UltraPack é menor, mais rico e mais seguro do que o JSON. Mas tudo permanece apenas na teoria, o UltraPack, que atinge seu limite no espaço, irá inevitavelmente falhar no tempo.
A teoria da relatividade de Einstein unifica o tempo e o espaço com uma pequena velocidade da luz, fazendo com que as pessoas percebam que o tempo e o espaço são intercambiáveis, portanto, no campo da ciência baseada no silício (ciência da computação) há uma CPU e memória Acoplamento de jogo, algoritmo e restrições de estrutura de dados, complexidade de tempo e complexidade de espaço.
Desde o início, o UltraPack não considerou questões de tempo, mas sacrificou o tempo tanto quanto possível em troca de benefícios de espaço. Especialmente para obter uma árvore de Huffman perfeita, ele não hesita em cruzar o limite físico de todo o byte, o que leva diretamente ao tempo adicional da CPU durante a codificação e decodificação. Mas, novamente, tempo e espaço são duas contradições que não podem ser alcançadas ao mesmo tempo, valeria a pena sacrificar o tempo e deixar que os gastos com espaço atinjam o limite teórico.
16
-
Metafísica do motor V8
No final, resta uma pequena pergunta: Por que o teste de desempenho do msp escolheu a plataforma python em vez da plataforma JS / node mais popular? Porque na plataforma JS / node, seja para codificação ou decodificação, a velocidade do msp é muito menor do que a do json. O que causou esse fato trágico?
O culpado é o motor V8.
Em geral, msp é definitivamente mais rápido do que json em teoria, mas a razão fundamental pela qual os resultados experimentais da plataforma JS são bastante diferentes das expectativas teóricas é que não é que a velocidade de json seja muito rápida, mas que a velocidade de msp é severamente enfraquecida pelo motor V8.
O mesmo objeto JS é definido abaixo. Qual dos dois métodos a seguir é mais rápido?
// spawn an object, which way is faster?
// 第一种
const data = { foo: 42, bar: 133 }; // ????
// 第二种
const data = JSON.parse(`{"foo":42,"bar":133}`); // ????
Intuitivamente, o primeiro método é mais rápido, pois o primeiro método define diretamente um objeto, enquanto o segundo método usa a string JSON para decodificá-la parece ter uma camada extra de operação de "compilação", que deveria ser mais lenta. Mas o tiro saiu pela culatra. Após o teste, o segundo método é muito mais rápido que o primeiro.
A razão fundamental é que a primeira maneira está acima do motor e a segunda sob o capô. JS é uma linguagem de alto nível que funciona no motor. A existência do motor V8 é uma faca de dois gumes, que é conveniente para as pessoas, mas prejudica as máquinas . Na especificação JS, mesmo uma função simples pode levar mais de uma dúzia de etapas para ser concluída. Por exemplo, Array.prototype.push () insere um novo elemento na matriz. Esta é uma operação básica de que o JS Siga as seguintes etapas:
Para adicionar um novo elemento, o V8 primeiro verifica a duração da verificação, depois verifica o tipo e, finalmente, permite que você empurre até ter certeza de que é seguro fazer. Quando um grande número de empurra é realizado em conjunto, é impossível imaginar o tempo perdido. Só para deixar os desenvolvedores felizes e jogar a máquina assim, pela primeira vez tenho vergonha de ainda estar usando uma linguagem de digitação fraca ????!
Esta é a razão pela qual o msp é tão lento na plataforma JS: o interpretador msp é executado no mecanismo V8. Embora a análise seja rápida, a eficiência da construção de objetos JS é amplamente bloqueada, e JSON é a API no mecanismo V8. , O suporte nativo permite que a velocidade de análise JSON toque diretamente no limite do hardware.
Em outras plataformas, como Python, C ++, etc., a mesma operação de push de matriz, porque o elemento tem um tipo (TypedArray) e memória pré-alocada, a velocidade de push não é afetada pelo mecanismo e é limitada apenas pelo físico, onde msp pode mostrar Sua vantagem.
A série "Teoria da Informação" completou todos os 16 capítulos, envolvendo palavras-chave: entropia da informação, vida, árvore binária, serialização, limite de espaço, motor V8.
<end>
Depois de terminar meu trabalho: