Самое интересное в PHP 819.12.2019 13:48

PHP 7.4 только-только объявлена stable, а нам уже подавай еще больше усовершенствований. И лучше всех о том, что ждет PHP, может рассказать Дмитрий Стогов — один из ведущих разработчиков Open Source PHP и, наверное, старейший активный контрибьютор.

Все доклады Дмитрия только о тех технологиях и решениях, над которыми он работает лично. В лучших традициях Онтико под катом текстовая версия рассказа о самых интересных с точки зрения Дмитрия нововведениях PHP 8, которые могут открыть новые use-case-ы. В первую очередь JIT и FFI — не в ключе «потрясающих перспектив», а с подробностями реализации и подводными камнями.

Для справки: Дмитрий Стогов познакомился с программированием в 1984, когда еще далеко не все из читателей появились на свет, и успел внести существенный вклад в развитие инструментов разработки, и PHP в частности (хоть Дмитрий повышает производительность PHP не специально для российских разработчиков, они выразили свою благодарность в виде Премии HighLoad++). Дмитрий автор Turck MMCache для PHP (eAccelerator), майнтейнер Zend OPcache, лидер проекта PHPNG, легшего в основу PHP 7, и лидер разработки JIT для PHP.

Развитие производительности PHP

Работать над производительностью PHP я начал 15 лет назад, когда пришел в Zend. Тогда мы выпустили версию 5.0 — первую, в которой язык стал по-настоящему объектно-ориентированным. С тех пор нам удалось повысить производительность на синтетических тестах в 40 раз, а на реальных приложениях в 6 раз.

За это время было два прорывных момента:

• Версия 5.1, в которой мы смогли существенно повысить скорость интерпретации. Мы реализовали специализирующий интерпретатор, и это повлияло в первую очередь на синтетические тесты.
• Версия 7.0, в которой переработали все ключевые структуры данных и таким образом оптимизировали работу с памятью и кэшем процессора (подробнее об этих оптимизациях читайте здесь). Это привело к более чем двукратному ускорению и на синтетических тестах, и в реальных приложениях.

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

На диаграмме видно, что как в конце разработки 5-й версии, так и в конце цикла разработки 7-й версии мы выходим на плато и замедляемся. Так за последний год работы над v7.4 удалось добиться только 2% прироста производительности. И это неплохо, потому что появились такие новые фичи как typed properties и ковариантные типы, которые замедляют PHP (об этих новинках на PHP Russia рассказывал Никита Попов).

И теперь всем интересно, что ждать от 8-й версии, сможет ли она повторить успех v7?

To JIT or not to JIT

Идеи по усовершенствованию интерпретатора еще не исчерпаны, но все они требуют очень существенной проработки. Многие из них приходится отбросить на этапе proof of concept, потому что выигрыш, который удается получить, оказывается несоизмерим с усложнением или налагаемыми техническими ограничениями.

Но остается надежда на новую прорывную технологию — конечно, вспоминается JIT и история успеха JavaScript-движков.

На самом деле работы над JIT для PHP ведутся еще с 2012 года. Было 3 или 4 реализации, мы работали с коллегами из Intel, JavaScript-хакерами, но как-то все не получалось включить JIT в главную ветку. В конце концов в PHP 8 мы включили JIT в компилятор и увидели двукратное ускорение, но только на синтетических тестах, а на реальных приложениях наоборот — замедление.

Разумеется, это не то, к чему мы стремимся.

В чем же дело? Может, мы что-то делаем не так, может быть, WordPress такой плохой, и никакой JIT ему не поможет (да, на самом деле это так). Может, мы уже сделали слишком хороший интерпретатор, а в JavaScript он хуже. На вычислительных тестах это действительно так: интерпретатор PHP один из лучших.

На тесте Mandelbrot он обгоняет даже такие жемчужины, как LuaJIT — интерпретатор, написанный на ассемблере. На этом тесте мы уступаем всего в 4 раза оптимизирующему компилятору GCC-5.3. С помощью JIT мы могли бы получить лучшие результаты в тесте Mandelbrot. Собственно, мы уже это делаем, то есть способны генерировать код, который конкурирует с компилятором C.

Почему же тогда мы не можем ускорить реальные приложения? Чтобы разобраться, расскажу, как мы делаем JIT. Начнем с самых азов.

Как работает PHP

Сервер принимает запрос, компилирует его в байт-код, который в свою очередь поступает на исполнение виртуальной машине. Виртуальная машина, исполняя байт-код, может вызывать и другие PHP-файлы, которые опять перекомпилируются в байт-код и опять исполняются.

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

Но скорее всего никто не использует PHP в голом виде, все его используют с OPcache.

PHP + OPcache

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

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

В эту схему JIT уже можно встроить, что мы и сделаем. Но сначала покажу, как работает интерпретатор.

Интерпретатор — это в первую очередь цикл, который для каждой инструкции вызывает свой обработчик.

У нас используются два регистра:

• execute_data — указатель на текущий фрейм активации;
• opline — указатель на текущую исполняемую виртуальную инструкцию.

Эти два вида регистров с помощью расширения gсcмапятся на реальные хардварные регистры, и за счет этого работают очень быстро.

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

Важно отметить, что адрес обработчика записывается непосредственно в байт-код. Для одной инструкции может быть несколько разных обработчиков. Первоначально это было придумано для специализации, чтобы обработчики могли специализироваться по типам операндов. Эта же технология используется для JIT, поскольку если записать в качестве обработчика адрес на новый сгенерированный код, то JIT-обработчики будут запускаться безо всякого изменения в интерпретаторе.

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

Из этого описания генерируются специализированные функции. Так как было три возможных первых операнда, три возможных вторых, то получается 9 разных функций.

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

Гибридная виртуальная машина

Еще одно усложнение, которое мы сделали в версии 7.2 — это так называемая гибридная виртуальная машина.

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

Казалось, раньше делали один косвенный вызов, теперь два: косвенный переход и прямой вызов, и такая система должна работать медленнее. Но на самом деле она работает быстрее, потому что мы помогаем процессору предсказывать переходы. Раньше была одна точка, из которой осуществлялся переход в разные места. Процессор часто ошибался, так как просто не мог запомнить, что надо прыгать сначала на одну инструкцию, потом на другую. Теперь после каждого прямого вызова идет косвенный переход на следующую метку. В результате, когда выполняется PHP-цикл, виртуальные PHP-инструкции выстраиваются в стабильные последовательности, которые потом выполняются практически линейно.

Гибридная виртуальная машина позволила поднять производительность еще на 5–10%.

PHP + OPcache + JIT

JIT реализуется как часть OPcache.

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

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

Слева на PHP написана некая функция, которая считает сумму чисел от 0 до 100. Справа сгенерированный байт-код. Первая инструкция присваивает сумме 0, вторая то же делает для i, потом безусловный переход по метке. На метке L1 проверяется условие выхода из цикла: если оно выполнилось, то выходим, если нет, то идем в цикл. Дальше прибавляем к сумме i, записываем результат в сумму, увеличиваем i на 1.

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

Первая инструкция QM_ASSIGN скомпилирована всего в две машинные инструкции (2–3 строка). В регистре %esi лежит указатель текущего фрейма активации. По смещению 30 лежит переменная сумма. Первая инструкция записывает значение 0, вторая записывает 4 — это идентификатор целого типа (IS_LONG). Для переменной i компилятор понял, что она всегда long, и для нее не нужно хранить тип. Более того, её можно хранить в машинном регистре. Поэтому здесь просто XOR регистра c самим с собой — самая простая и дешевая инструкция обнуления.

Дальше точно так же безусловный переход, проверяем, не произошло ли какое-то внешнее событие, проверяем условие цикла, идем в цикл. В цикле проверяется, является ли сумма целым: если да, то читаем целое значение, прибавляем к нему значение i, проверяем, не произошло ли переполнение, записываем результат обратно в сумму и прибавляем 1 к %edx.

Видно, что код близок к оптимальному. Можно было бы оптимизировать его еще больше, избавившись от проверки суммы на тип на каждой итерации цикла. Но это уже достаточно сложная оптимизация, мы пока таких не делаем. Мы развиваем JIT как достаточно простую технологию, не пытаемся делать то, что пытается делать Java HotSpot, V8 — у нас сил меньше.

Что не так с JIT

Почему же при таком хорошем ассемблерном коде мы не можем ускорить реальные приложения?

Собственно, а должны ли?

• Если узкое место не в CPU, то JIT не поможет.
• Генерируется слишком много кода (code bloat).
• Статический вывод типов работает не всегда.
• Честный код (для случаев, которые никогда не исполняются).
• Поддержка консистентного состояния виртуальной машины (а вдруг exception).
• Классы живут только в течение одного запроса.

Если приложение 80% времени ждет ответа от базы данных, то JIT не поможет. Если мы вызываем внешние ресурсоёмкие функции, например, сопоставление с регулярным выражением, то JIT точно также будет вызывать те же самые функции. Более того, если приложение строит большие структуры данных — деревья, графы, а потом читает их, то с помощью JIT мы генерируем код, который будет выполнять чтение за меньшее количество инструкций, но чтобы подгрузить сами данные, потребуется все то же время, а кроме того потребуется грузить еще и код.

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

Скромные планы на PHP 8

Одно из усовершенствований, которого мы хотим добиться в PHP 8, — это генерировать меньше кода. Сейчас, как я сказал, мы генерируем нативный код для всего скрипта, который грузим на этапе загрузки. Но половина функций наверняка не будет вызываться. Поэтому мы пошли немного дальше и ввели некий триггер, который позволяет сконфигурировать, когда мы хотим запускать JIT. Его можно запускать:

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

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

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

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

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

Подобная схема используется и в HotSpot Java VM, и в V8. Но адаптация технологии к PHP имеет ряд сложностей. В первую очередь это то, что мы имеем shared байт-код и shared нативный код, используемый из разных процессов. Мы не можем их менять непосредственно в shared memory, нужно сначала куда-то копировать, изменять, а потом уже коммитить обратно в shared memory.

Preloading. Проблема связывания классов

На самом деле, многие идеи усовершенствований PHP, уже давно включенных в PHP 7 и даже PHP 5, пришли из работ, связанных с JIT. Сегодня я расскажу еще об одной такой технологии — это preloading. Эта технология уже включена в PHP 7.4 и дает возможность задать набор файлов, загрузить их при старте сервера и сделать все функции из этих файлов постоянными.

Одна из проблем, которую решает preloading-технология — это проблема связывания классов. Дело в том, что когда мы просто компилируем файлы в PHP, каждый файл компилируется отдельно от других. Делается это потому, что каждый из них может изменяться отдельно. Нельзя связать класс из одного скрипта с классом из другого скрипта, потому что при следующем запросе один из них может измениться, и что-то пойдет не так. Более того, в нескольких файлах может быть одноименный класс, и при одном запросе один из них используется в качестве parent, а при другом —используется другой класс из другого файла (с тем же именем, но совсем другой). Получается, что генерируя код, который будет выполняться на нескольких запросах, нельзя ссылаться ни на классы, ни на методы, потому что они каждый раз пересоздаются заново (время жизни кода превышает время жизни классов).

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

Эта технология помогает не только для связывания классов. Что-то подобное реализовано в Java как Class Data Sharing. Там эта технология в первую очередь предназначена для ускорения старта приложений и уменьшения общего количества потребляемой памяти. Те же самые плюсы получаются и в PHP, поскольку теперь связывание классов не делается в runtime, а выполняется единожды. Кроме того связанные классы теперь хранятся не в адресном пространстве каждого процесса, а в shared memory, и следовательно общее потребление памяти падает

Использование preloading так же помогает при глобальной оптимизации всех PHP-скриптов, полностью убирает накладные расходы OPcache и позволяет генерировать более эффективный JIT-код.

Но есть и минусы. Загруженные при старте скрипты нельзя заменить без рестарта PHP. Если мы что-то загрузили и сделали постоянным, то уже не можем это выгрузить. Поэтому технология может быть использована со стабильными фреймворками, но если вы деплоите приложение по нескольку раз в день, скорее всего, она вам не подойдет.

Технология задумывалась как транспарентная, то есть позволяла подгружать имеющиеся приложения (или их части) без каких-либо изменений. Но уже после реализации оказалось, что это не совсем так, Не все приложения работают так, как задумано, если они загружены с помощью preload. Например, если в приложении вызывается код по результатам проверки функции function_exists или class_exists, а функция стала постоянной, соответственно, function_exists всегда возвращает true, и код, который раньше по задумке вызывался, вызываться перестает.

Технически preloading включается с помощью всего одной директивы конфигурации opcache.preload, на вход которой вы даете файл сценария — обычный PHP-файл, который будет запущен на этапе старта приложения (не просто загружен, а именно выполнен).

#include 
static void activate(GtkApplication* app, gpointer user_data) {
    GtkWidget *window = gtk_application_window_new(app);
    gtk_window_set_title(GTK_WINDOW(window), "Hello from C");
    gtk_window_set_default_size(GTK_WINDOW(window), 200, 200);
    gtk_widget_show_all(window);
}

int main() {
    int status;
    GtkApplication *app;
    app = gtk_application_new("org.gtk.example", G_APPLICATION_FLAGS_NONE);
    g_signal_connect(app, "activate", G_CALLBACK(activate), NULL);
    status = g_application_run(G_APPLICATION(app), 0, NULL);
    g_object_unref(app);
    return status;
}

", "libgtk-3.so.0");

function activate($app, $user_data) {
    global $ffi;

    $window = $ffi->gtk_application_window_new($app);
    $ffi->gtk_window_set_title($window, "Hello from PHP");
    $ffi->gtk_window_set_default_size($window, 200, 200);
    $ffi->gtk_widget_show_all($window);
}

$app = $ffi->gtk_application_new("org.gtk.example", 0);
$ffi->g_signal_connect_data($app, "activate", "activate", NULL, NULL, 0);
$ffi->g_application_run($app, 0, NULL);
$ffi->g_object_unref($app);

#define FFI_SCOPE "GTK"
#define FFI_LIB "libgtk-3.so.0" 

gtk_application_new("org.gtk.example", 0);
        self::$ffi->g_signal_connect_data($app, "activate",
            function($app, $data) use ($title) {
                $window = self::$ffi->gtk_application_window_new($app);
                self::$ffi->gtk_window_set_title($window, $title);
                self::$ffi->gtk_window_set_default_size($window, 200, 200);
                self::$ffi->gtk_widget_show_all($window);
            }, NULL, NULL, 0);
        self::$ffi->g_application_run($app, 0, NULL);
        self::$ffi->g_object_unref($app);
    }
}

gtk_application_new("org.gtk.example", 0);
        self::$ffi->g_signal_connect_data($app, "activate",
            function($app, $data) use ($title) {
                $window = self::$ffi->gtk_application_window_new($app);
                self::$ffi->gtk_window_set_title($window, $title);
                self::$ffi->gtk_window_set_default_size($window, 200, 200);
                self::$ffi->gtk_widget_show_all($window);
            }, NULL, NULL, 0);
        self::$ffi->g_application_run($app, 0, NULL);
        self::$ffi->g_object_unref($app);
    }
}

$ php -d opcache.preload=gtk.php -r 'GTK::create_window("Все просто!");'

x = $x;
    $points[$x]->y = $x * $x;
}

var_dump($points[25]->y); // 625
var_dump(FFI::sizeof($points)); // 800 байт

foreach ($points as &$p) {
    $p->x += 10;
}

var_dump($points[25]->x); // 35

for ($k=0; $k<1000; $k++) {
    for ($i=$n-1; $i>=0; $i--) {
        $Y[$i] += $X[$i];
    }
}