Быстрый запуск JavaScript является ключом к отзывчивости веб-приложений. Даже с продвинутыми оптимизациями V8, парсинг и компиляция критически важных JavaScript во время запуска могут оставаться узкими местами производительности. Знание функций JavaScript, которые нужно скомпилировать при первоначальной компиляции скрипта, может ускорить загрузку веб-страниц.
Финальный уровень оптимизирующего компилятора V8 — Turbofan — известен тем, что является одним из немногих крупномасштабных компиляторов, использующих Море узлов (SoN). Однако, почти три года назад мы начали избавляться от Моря узлов и вернулись к более традиционному графу управления потоком (CFG) промежуточному представлению (IR), который мы назвали Turboshaft. На данный момент весь бэкенд JavaScript в Turbofan использует Turboshaft, и WebAssembly использует Turboshaft на протяжении всего своего конвейера. Две части Turbofan все еще используют некоторые элементы Моря узлов: встроенный конвейер, который мы постепенно заменяем на Turboshaft, и фронтенд JavaScript конвейера, который мы заменяем на Maglev, другое промежуточное представление на основе CFG. В этом посте объясняются причины, которые привели нас к отказу от Моря узлов.
В V8 мы постоянно стремимся улучшать производительность JavaScript. В рамках этих усилий мы недавно пересмотрели набор бенчмарков JetStream2, чтобы устранить узкие места производительности. В этом посте описывается конкретная оптимизация, которую мы внедрили, что привело к значительному улучшению результата async-fs в 2.5x, способствуя заметному улучшению общего счета. Оптимизация была вдохновлена этим бенчмарком, но подобные шаблоны действительно встречаются в реальном коде.
Вы когда-нибудь задумывались, откуда взялись undefined, true и другие основные объекты JavaScript? Эти объекты являются основами любых пользовательских объектов и должны существовать первыми. V8 называет их неизменяемыми корнями, которые располагаются в собственной куче – только для чтения. Так как они постоянно используются, быстрый доступ крайне важен. А что может быть быстрее правильного угадывания их адреса в памяти на этапе компиляции?
Добро пожаловать в захватывающий мир V8, где скорость — это не просто функция, а образ жизни. Наступил момент попрощаться с 2023 годом и отпраздновать впечатляющие достижения, которых V8 достиг в этом году.
Благодаря инновационным оптимизациям производительности V8 продолжает расширять границы возможного в постоянно меняющемся ландшафте Веба. Мы представили новый компилятор среднего уровня и реализовали множество улучшений в инфраструктуре компилятора высокого уровня, среде выполнения и сборщике мусора, что привело к значительному увеличению скорости работы.
В Chrome M117 мы представили новый оптимизирующий компилятор: Maglev. Maglev расположен между нашими существующими компиляторами Sparkplug и TurboFan, выполняя роль быстрого оптимизирующего компилятора, который создает достаточно хороший код достаточно быстро.
До 2021 года V8 имел два основных уровня исполнения: Ignition, интерпретатор; и TurboFan, оптимизирующий компилятор V8, ориентированный на максимальную производительность. Весь код JavaScript сначала компилируется в байт-код Ignition и исполняется путем интерпретации. Во время выполнения V8 отслеживает поведение программы, включая формы объектов и типы. Метаданные выполнения и байт-код поступают в оптимизирующий компилятор для генерации высокопроизводительного, часто спекулятивного машинного кода, который работает значительно быстрее, чем интерпретатор.
В V8 версии 9.1 мы временно отключили встроенные функции на настольных компьютерах. Хотя использование встроенных функций значительно улучшает использование памяти, мы поняли, что вызовы функций между встроенными функциями и кодом, скомпилированным JIT, могут привести к значительным потерям в производительности. Эта стоимость зависит от микроархитектуры процессора. В этом посте мы объясним, почему это происходит, как это влияет на производительность и что мы планируем сделать для долгосрочного решения проблемы.
super может быть использован для доступа к свойствам и методам родителя объекта.
Ранее доступ к свойству super (например, super.x) выполнялся через вызов времени выполнения. Начиная с V8 v9.0, мы используем систему кеширования inline (IC) в неоптимизированном коде и генерируем правильный оптимизированный код для доступа к свойствам super, без необходимости перемещаться к выполнению времени.
Благодаря недавней работе в Chrome и Emscripten теперь вы можете использовать до 4 ГБ памяти в приложениях WebAssembly. Это больше предыдущего ограничения в 2 ГБ. Может показаться странным, что вообще было ограничение, ведь не требовалось никаких изменений, чтобы использовать 512 МБ или 1 ГБ памяти! - но оказывается, что в переходе от 2 ГБ к 4 ГБ происходят особенные вещи, как в браузере, так и в цепочке инструментов, о которых мы расскажем в этом посте.