Что такое базовый компилятор?

Question

Я изо всех сил пытался найти определение базового компилятора и базового интерпретатора , и я очень удивлен, что это нигде не упоминается.

Если я не ошибаюсь базовый компилятор будет компилировать код в байт-код, а не в машинно-зависимый машинный код, верно?

Answer 1

Я нахожу некоторую информацию о topi c в контексте JavaScript механизмов исполнения, особенно для веб-браузеров: Короче говоря, базовый компилятор - это определенный этап во время выполнения кода механизмом исполнения. Он будет генерировать машинный код очень быстро, но без оптимизации для машины, на которой этот код фактически выполняется. Таким образом, это действительно метод в рамках более широкой концепции компиляции "точно в срок" (JIT) и, следовательно, концептуально где-то между интерпретацией кода и компиляцией кода.

Эта статья дает некоторые сведения о JavaScript JIT-компиляции:

В итоге, после загрузки кода JavaScript исходный код преобразуется в древовидное представление, называемое абстрактным синтаксическим деревом или AST. После этого, в зависимости от механизма / операционной системы / платформы, либо компилируется базовая версия этого кода, либо создается байт-код для интерпретации. [...]

Когда фрагмент кода выполняется несколько раз, [...] интерпретатор теряет свою производительность, так как он должен интерпретировать один и тот же фрагмент кода снова и снова, когда это происходит профилировщик помечает этот фрагмент кода как «теплый» и базовый компилятор вступает в действие.

Когда этот фрагмент кода выполняется [...], JIT нужно только снова взять этот скомпилированный фрагмент. Когда теплый код вызывается несколько раз одним и тем же способом (например, одних и тех же типов), он помечается как горячий. [...]

Когда фрагмент кода помечен как горячий, компилятор оптимизатора создает еще более быструю версию этого кода.

Вот еще один источник объяснение понятия о «горячем» коде и различных уровнях выполнения кода.

В этом (старом) объявлении рассказывается о новом (тогда) новом движке Mozilla JavaScript и проблемах, которые решаются включенным базовым компилятором.

Эта другая статья блога Mozilla дает очень подробную информацию о выполнении кода, еще больше меняя концепцию из-за новых требований и условий:

Однако современные Сеть имеет такие большие кодовые базы, что даже относительно быстрый Baseline JIT Compiler потратил много времени на компиляцию. Чтобы решить эту проблему, Firefox 70 добавляет новый уровень, называемый базовым интерпретатором, в конвейер

С другой стороны, Chromium, похоже, ввел концепцию в 2010 в своем Двигатель V8 (называя его базовым компилятором), и чтобы сбросил его снова в 2017 .

Answer 2

После изучения многих статей и книг я смог определить значение «базового компилятора».

По сути, работа базового компилятора состоит в том, чтобы генерировать байт-код или машинный код как можно быстрее. Однако этот код не очень оптимизирован для процессора, поэтому он очень неэффективен и медленен во время выполнения.

С другой стороны, «компилятор оптимизации» создает эффективный код, однако для этого требуется гораздо больше времени .

Следовательно, базовый компилятор полезен, когда вы хотите как можно быстрее загрузить и запустить приложение, а затем оптимизировать код с помощью компилятора оптимизации в фоновом режиме.

Answer 3

Чтобы ответить на ваш вопрос, вы должны понять внутреннюю работу языка Javascript через его историю и последние события.

JavaScript определяется как интерпретируемый язык, но также скомпилированный на лету (JIT-Compiled).

Путаница еще больше усугубляется отсутствием информации в самой спецификации JavaScript.

Когда JavaScript выполняется, движок JavaScript браузера (V8 на Chrome, SpiderMonkey на Firefox) или сервер (V8 с Node.js) должны преобразовать исходный код в формат, понятный компьютеру.

Для этого есть два способа: интерпретация или компиляция исходного кода.

Интерпретация : Программа переведена на компьютер язык во время его исполнения (runtime). Каждая строка обрабатывается на лету, не ожидая стадии предварительной обработки.

С другой стороны, когда строка кода выполняется N раз (например, oop), интерпретатор должен повторять перевод машинного языка N раз.

Компиляция : Требуется предварительная фаза перевода на машинный язык для возможности выполнения. Весь код предварительно компилируется и оптимизируется компилятором, чтобы программа могла быть выполнена. Это услуга за услугу, чтобы облегчить проблему, связанную с упомянутыми выше переводчиками.

Появившись в середине 90-х, JavaScript использовался мало, мы нашли некоторые инструкции в теге и призываем к такие функции, как onclick или alert.

Интерпретация была намного проще и обеспечивала совершенно адекватную производительность для случаев использования времени.

В 2000-х годах гонка за производительностью веб-браузеров разгорелась до Дело в том, что это называлось Войной Браузеров. Это период, в течение которого основные веб-игроки (Mozilla, Google) пытаются максимально оптимизировать свой браузер.

Таким образом, Firefox представляет SpiderMonkey, самый первый JIT-компилятор, который позволил увеличить производительность примерно От 20 до 40% по сравнению со старой версией механизма JavaScript.

В ходе этого процесса Google сделал доступным браузер Chrome и его механизм исполнения V8, включая этап компиляции. Последний часто называют «Just in Time» или JIT.

Другие браузеры (Edge, et c.) Также изменили свой движок JavaScript, добавив фазу компиляции. Эта разработка повысила скорость JavaScript в 10 раз и стала рычагом ее использования на ранее немыслимых платформах, таких как серверное программирование (Node.js).

«Как раз вовремя» и компиляция

JIT-компилятор сочетает в себе скорость выполнения интерпретатора с оптимизацией, предоставляемой компилятором.

JavaScript движки, включая JIT, очень часто состоит из 4 основных строительных блоков:

Монитор (профилировщик), который играет роль проводника. Интерпретатор, который выполняет исходный код (время выполнения). Так называемый "basi c". Компилятор, который выполняет некоторые базовые c оптимизации. Компилятор, называемый «оптимизатором», позаботится о дальнейшей оптимизации в случае необходимости.

(упрощенный) процесс выполнения выглядит следующим образом:

1) Монитор вызывает переводчика для выполнения кода. Он на лету анализирует выполненные вызовы функций.

2) Если переводчик делает несколько вызовов одной и той же функции, монитор «помечает» ее как «горячую» функцию.

3) Как как только функция нагревается, монитор связывается с базовым компилятором, чтобы указать, что функция часто используется и что она должна быть скомпилирована.

4) Базовый компилятор выполняет некоторые оптимизации, генерируя оптимизированную версию (заглушка). ) каждой инструкции.

5) Если функция становится все более горячей, она помечается как горячая: ее необходимо дополнительно оптимизировать.

6) Затем монитор решает отправить эту функцию компилятору-оптимизатору, который создаст еще более оптимизированную версию, чем сгенерированный базовым компилятором.

7) Этот компилятор делает несколько предположений относительно этой функции Например, тип переменных. Зная, что JavaScript имеет динамическую c типизацию, вероятность ошибки не равна нулю. Компилятор может удалить свою оптимизацию и ссылаться только на версию, скомпилированную на шаге 4: это операция де-оптимизации.

8) Интерпретатор, которому вместо того, чтобы заново переводить функцию на машинный язык, будет напрямую использовать свою скомпилированную или оптимизированную версию для ускорения обработки.

Этап № 7 подвержен проблемам с производительностью. Действительно, де-оптимизация может замедлить процесс в том случае, если компилятор тратит свое время на оптимизацию, а затем де-оптимизацию кода. Вот почему некоторые JavaScript движки имеют ограничение цикла оптимизации.

Как только этот порог достигнут, компилятор перестанет пытаться оптимизировать и будет ссылаться на версию исходного кода в своем «сыром» виде. форма (та, что на шаге 1) или заглушка, созданная на шаге 4.

Уровень производительности и не вдаваясь в подробности каждого JavaScript двигателя для простоты, мы можем видеть, что он качается: V8 всегда в ведущий и показывает интересные исполнения.

Интерпретировано или скомпилировано?

Теперь, когда у нас есть общее представление о процессе выполнения, мы можем рискнуть пометить JavaScript как интерпретировано или скомпилировано.

JIT-компиляторы переводят исходный код (на машинном языке) на лету, и только для улучшения производительности, это не инициатива, определяющая c для ECMA TC39 или JavaScript.

JavaScript, следовательно, является интерпретируемым языком, который по мере использования и развития должен был сталкиваться с проблемами производительности и приводил к некоторому « гибридный »режим, смешивание интерпретации и компиляции.

Недавно Mozilla предложила эволюцию своего механизма исполнения (HolyJIT) с использованием языка Rust, направленную на повышение производительности и безопасности процесса компиляции.

В конце февраля 2017 года 4 основных браузера (Chrome, Safari, Edge и Firefox) объявили, что MVP (Miminum ценный продукт) в отношении WebAssembly (WASM) был завершен.

Это пьедестал, связанный с JIT-компиляторами, открывает поле возможностей, касающихся использования языков, отличных от JavaScript (C ++, Rust) в браузере.

Например модуль, разработанный на таком языке, как C или Rust, может быть встроен и использован в приложении JavaScript без влияния на браузер.

Все это не тривиально и требует, чтобы код был скомпилирован с помощью для этой цели предусмотрен компилятор, поэтому в качестве выходного файла создается файл .wasm.

Это интересная технология. Нужно следовать нологии, потому что тяжелая обработка (интенсивные вычисления через CPU или GPU) вполне может быть разработана на адаптированном языке (C или C ++), а остальная часть приложения разработана в JavaScript.

Вот несколько интересных статей, они более подробно затрагивают тему: V 110:

http://www.jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler

https://v8project.blogspot.fr/2016/08/firing-up-ignition-interpreter.html

http://www.jayconrod.com/posts/51/a-tour-of-v8-full-compiler

https://ponyfoo.com/articles/an-introduction-to-speculative-optimization-in-v8

https://v8project.blogspot.fr/2017/11/csa.html

Answer 4

Обмен моими выводами

Относительно Jikes RVM

Цель базового компилятора состоит в том, чтобы эффективно генерировать код, который «очевидно корректен». Он также должен быть простым для переноса на новую платформу и самодостаточным (весь базовый компилятор должен быть включен во все загрузочные образы Jikes RVM для поддержки динамической загрузки других компиляторов).

Ссылка: Jikes RVM Глава 13 Компиляторы

Базовый компилятор, который существует для целей отладки и проверки; он генерирует собственный код, который непосредственно реализует модель стека JVML настолько близко, насколько это возможно, и во многих отношениях сопоставим с интерпретатором.

Ссылка: Количественная оценка преимуществ мобильного кода на основе SSA

---

Относительно JavaScript

Первое объяснение

Когда код начинает выполняться, он обрабатывается интерпретатором. В фоновом режиме базовый компилятор генерирует код, содержащий информацию профиля. Этот базовый код вызывается позже. По мере выполнения и обнаружения популярных функций они перекомпилируются более продвинутым компилятором DFG. Наконец, для действительно актуальных функций самый продвинутый компилятор (FTL) создает очень специализированный, высокопроизводительный код.

Ссылка: NoMap: Ускорение JavaScript Использование аппаратной транзакционной памяти

Второе объяснение

Ссылка: Профилирование на стороне сервера для OptimizingClient-Side JavaScript Двигатели