10 postagens marcadas com "JavaScript"

No V8 v9.1 desativamos temporariamente as funções internas incorporadas no desktop. Embora incorporar funções internas melhore significativamente o uso de memória, percebemos que chamadas de funções entre as funções internas incorporadas e o código compilado pelo JIT podem resultar em uma penalidade de desempenho considerável. Esse custo depende da microarquitetura do CPU. Neste post, vamos explicar por que isso está acontecendo, como o desempenho é afetado e o que planejamos fazer para resolver isso a longo prazo.

Fazer o JavaScript rodar rapidamente é essencial para um aplicativo web responsivo. Mesmo com as otimizações avançadas do V8, analisar e compilar JavaScript crítico durante a inicialização ainda pode criar gargalos de desempenho. Saber quais funções JavaScript compilar durante a compilação inicial do script pode acelerar o carregamento da página da web.

O compilador otimizador de última etapa do V8, o Turbofan, é conhecido como um dos poucos compiladores de produção em larga escala que utilizam Mar de Nós (SoN). No entanto, há quase três anos, começamos a nos livrar do Mar de Nós e a retornar para uma Representação Intermediária (IR) Gráfico de Fluxo de Controle (CFG) mais tradicional, que chamamos de Turboshaft. Até agora, todo o backend de JavaScript do Turbofan utiliza Turboshaft e o WebAssembly usa Turboshaft ao longo de todo o seu pipeline. Duas partes do Turbofan ainda usam algum Mar de Nós: o pipeline embutido, que estamos substituindo gradualmente pelo Turboshaft, e o frontend do pipeline de JavaScript, que estamos substituindo pelo Maglev, outro IR baseado em CFG. Este post no blog explica as razões que nos levaram a abandonar o Mar de Nós.

No V8, estamos constantemente buscando melhorar o desempenho do JavaScript. Como parte desse esforço, recentemente revisamos o conjunto de benchmarks JetStream2 para eliminar gargalos de desempenho. Este post detalha uma otimização específica que realizamos e que resultou em uma melhoria significativa de 2.5x no benchmark async-fs, contribuindo para um aumento perceptível na pontuação geral. A otimização foi inspirada pelo benchmark, mas padrões como esses aparecem em código do mundo real.

Você já se perguntou de onde vêm undefined, true e outros objetos principais do JavaScript? Esses objetos são os átomos de qualquer objeto definido por usuário e precisam estar presentes primeiro. O V8 os chama de raízes imutáveis e imovíveis e eles vivem em seu próprio heap – o heap somente leitura. Como eles são usados constantemente, o acesso rápido é crucial. E o que poderia ser mais rápido do que adivinhar corretamente seu endereço de memória em tempo de compilação?

Bem-vindo ao emocionante mundo do V8, onde velocidade não é apenas uma característica, mas um estilo de vida. Enquanto nos despedimos de 2023, é hora de celebrar as impressionantes realizações que o V8 alcançou este ano.

Através de otimizações inovadoras de desempenho, o V8 continua a expandir os limites do que é possível no cenário em constante evolução da Web. Introduzimos um novo compilador de nível intermediário e implementamos várias melhorias na infraestrutura do compilador de alto nível, no runtime e no coletor de lixo, o que resultou em ganhos significativos de velocidade em todos os aspectos.

No Chrome M117 introduzimos um novo compilador otimizador: Maglev. Maglev está entre nossos compiladores existentes Sparkplug e TurboFan, e desempenha o papel de um compilador otimizador rápido que gera código suficientemente bom de forma rápida.

Até 2021, o V8 tinha dois principais níveis de execução: Ignition, o interpretador; e TurboFan, o compilador otimizador do V8 focado no desempenho máximo. Todo código JavaScript é primeiro compilado para bytecode do Ignition e executado interpretando-o. Durante a execução, o V8 rastreia como o programa se comporta, incluindo o monitoramento dos formatos e tipos de objetos. Tanto os metadados de execução em tempo de execução quanto o bytecode são usados pelo compilador otimizador para gerar código de máquina de alto desempenho, frequentemente especulativo, que é executado significativamente mais rápido do que o interpretador.

A palavra-chave super pode ser usada para acessar propriedades e funções no pai de um objeto.

Anteriormente, acessar uma propriedade super (como super.x) era implementado através de uma chamada em tempo de execução. A partir do V8 v9.0, reutilizamos o sistema de cache inline (IC) em códigos não otimizados e geramos o código otimizado adequado para acesso à propriedade super, sem precisar recorrer à execução em tempo de execução.

Introdução​

Graças ao trabalho recente no Chrome e Emscripten, agora você pode usar até 4GB de memória em aplicações WebAssembly. Isso é um aumento em relação ao limite anterior de 2GB. Pode parecer estranho que tenha havido um limite - afinal, nenhum trabalho foi necessário para permitir que as pessoas usassem 512MB ou 1GB de memória! - mas acontece que há algumas coisas especiais acontecendo no salto de 2GB para 4GB, tanto no navegador quanto na cadeia de ferramentas, que descreveremos neste post.