Понимание Jit В Php 8

Это означает, что При использовании JIT некоторые коды операций не требуют интерпретации виртуальной машиной Zend, такие инструкции будут выполняться непосредственно как инструкции уровня процессора.

Это слышно во многих блогах и сообществах — вокруг этого много шума, но подробностей о работе JIT я пока не нашел.

После неоднократных попыток и разочарований в поиске полезной информации я решил изучить исходный код PHP. Объединив мои небольшие знания языка C и всю разрозненную информацию, которую мне удалось собрать на данный момент, мне удалось подготовить эту статью и надеюсь, что она поможет вам лучше понять JIT PHP. Чтобы упростить ситуацию: когда JIT работает должным образом, ваш код не будет выполняться через виртуальную машину Zend, а будет выполняться непосредственно как набор инструкций на уровне процессора.

В этом вся идея.

Но чтобы лучше это понять, нам нужно подумать о том, как работает PHP внутри.

Это не очень сложно, но требует некоторого представления.

Я уже написал статью с кратким описанием обзор того, как работает PHP .

Если эта статья покажется вам слишком сложной, просто прочтите предыдущую и вернитесь к ней.

Это должно немного облегчить задачу.

Но что это на самом деле означает? Всякий раз, когда вы хотите выполнить код PHP, будь то фрагмент или целое веб-приложение, вам придется использовать интерпретатор PHP. Наиболее часто используемые из них — PHP FPM и интерпретатор CLI. Их работа очень проста: получить php-код, интерпретировать его и вернуть результат. Это общая картина для каждого интерпретируемого языка.

Некоторые шаги могут отличаться, но общая идея одна и та же.

Если вы используете PHP, вам, вероятно, следует включить Opcache. Что он делает, так это добавляет слой общего онлайн-кэша для кодов операций.

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

Вот схема того же процесса с учетом расширения Opcache:



Процесс интерпретации PHP с помощью Opcache. Если файл уже был проанализирован, php извлекает для него кэшированный код операции, а не анализирует его снова.

Просто поразительно, как красиво пропускаются этапы лексического анализа, синтаксического анализа и компиляции.

JIT генерирует скомпилированный код во время выполнения, поэтому php может пропустить виртуальную машину Zend и перейти непосредственно к процессору.

.

Теоретически мы должны получить от этого производительность.

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

Но на самом деле это вполне возможно.

JIT-реализация в PHP использует библиотеку DynASM (динамический ассемблер) , который отображает набор инструкций ЦП в определенном формате в ассемблерный код для множества различных типов ЦП.

Таким образом, компилятор Just In Time преобразует операционный код в машинный код, зависящий от архитектуры, с помощью DynASM. Хотя одна мысль все еще не давала мне покоя.

Если фронтальная загрузка может разобрать код PHP в рабочий код перед выполнением, а DynASM может скомпилировать рабочий код в машинный код (компиляция «точно в срок»), почему, черт возьми, мы не скомпилируем PHP на месте, используя компиляцию с опережением времени?! Одна из вещей, о которой заставил меня задуматься этот эпизод подкаста, заключалась в том, что PHP слабо типизирован, а это означает, что часто PHP не знает, какого типа переменная, пока виртуальная машина Zend не попытается выполнить определенный код операции.

Это можно понять, посмотрев тип объединения zend_value , который имеет множество указателей на различные представления типов переменной.

Всякий раз, когда виртуальная машина Zend пытается извлечь значение из zend_value, она использует такие макросы, как ЗSTR_VAL , которые пытаются получить доступ к указателю строки из объединения значений.

Например, этот обработчик виртуальной машины Zend должен обрабатывать «меньше или равно» (<=) expression. See how it branches into many different code paths to guess the operand types. Дублирование такой логики вывода типа с использованием собственного кода невозможно и потенциально может еще больше замедлить работу.

Окончательная компиляция после оценки типов также не является хорошим вариантом, поскольку компиляция в машинный код — это задача, нагружающая процессор.

Поэтому компилировать ВСЕ во время выполнения — плохая идея.

Мы также знаем, что компиляция во время выполнения стоит дорого.

Чем JIT может быть полезен для PHP? Чтобы сбалансировать это уравнение, JIT PHP пытается скомпилировать только те несколько кодов операций, которые, по его мнению, того стоят. Для этого он профилирует коды операций, выполняемые виртуальной машиной Zend, и проверяет, какие из них имеет смысл компилировать.

(в зависимости от вашей конфигурации) .

Когда определенный код операции компилируется, он делегирует выполнение этому скомпилированному коду, а не виртуальной машине Zend. Это выглядит так, как показано на схеме ниже:



Процесс интерпретации PHP с помощью JIT. Если они уже скомпилированы, коды операций не выполняются через Zend VM. Таким образом, расширение Opcache имеет пару инструкций, которые определяют, следует ли компилировать определенный операционный код или нет. Если да, то компилятор преобразует его в машинный код с помощью DynASM и выполняет этот новый сгенерированный машинный код. Интересно, что, поскольку текущая реализация имеет ограничение в МБ на скомпилированный код (также настраиваемый), выполнение кода должно иметь возможность плавно переключаться между JIT и интерпретируемым кодом.

Кстати, этот доклад Бенуа Жакмона о JIT из php Мне ОЧЕНЬ помогло во всем этом разобраться.

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

Скомпилированные коды операций обычно распределяются по нескольким запросам, если вы используете PHP FPM, но это все равно не изменит правила игры.

Это связано с тем, что JIT оптимизирует операции ЦП, а большинство PHP-приложений в наши дни в большей степени основаны на вводе-выводе, чем что-либо еще.

Не имеет значения, компилируются ли операции обработки, если вам все равно нужен доступ к диску или сети.

Тайминги будут очень похожими.

Если только.

Вы делаете что-то, что не требует ввода-вывода, например обработку изображений или машинное обучение.

Все, что не связано с вводом-выводом, выиграет от компилятора Just In Time. Это также причина, по которой люди теперь говорят, что они больше склоняются к написанию собственных функций PHP, написанных на PHP, а не на C. Накладные расходы не сильно изменились бы, если бы такие функции все равно были скомпилированы.

Интересное время для работы PHP-программистом.