Привет, меня зовут Николай Крапивный, я руковожу отделом server-side разработки в Badoo. В Badoo PHP — один из основных языков, на нем написана бóльшая часть бизнес-логики нашей системы. Поэтому мы следим за новостями из мира PHP, активно участвуем в развитии языка и стараемся развивать сообщество вокруг PHP.
Сегодня я бы хотел поделиться переводом письма Zeev Suraski, одного из основателей Zend Technologies, которое обрисовывает дальнейшее развитие PHP и проливает свет на то, чего нам ждать в PHP 8.
Я собирался написать об этом немного позднее, но раз уж подняли тему PHP 8, похоже, пришло время начать обсуждение.
Подчеркну: цель этого письма — не обсудить в подробностях каждое упомянутое мною изменение, а скорее закрепить наши планы: собираемся ли мы после 7.3 сосредоточиться на PHP 8, в основе которого лежат некоторые из наших исследовательских проектов и экспериментальные разработки.
Есть ряд направлений, на развитие которых, как мне кажется, нужно направить ресурсы в следующей основной версии.
JIT
Вероятно, многие из вас знают, что мы потратили много сил на реализацию JIT поверх инфраструктуры PHP 7. Есть хорошие и плохие новости. Хорошие: как и в случае с экспериментами с JIT, которые мы проводили в 2014-м, мы получили впечатляющие результаты бенчмарков с интенсивными нагрузками на CPU. А плохие новости в том, что JIT по нашим тестам не дает большого выигрыша на типичных веб-нагрузках.
Иными словами, в отличие от ситуации в 2014-м, мы считаем, что JIT не улучшит производительность при обработке типичных рабочих веб-нагрузок, поскольку исполнение PHP-кода больше не является узким местом.
Но я по-прежнему считаю, что нам нужно включить JIT в следующую основную версию PHP. Как минимум по двум причинам:
- Это позволит PHP обрабатывать новые типы рабочих нагрузок (не веб).
- Это позволит написать для PHP новую встроенную функциональность, которая повысит безопасность кода (например, PHP-реализацию
unserialize()вместо версии на C).
Кроме того, всегда есть вероятность, что мы что-то упускаем в своих бенчмарках, и что существуют веб-нагрузки, обработка которых ускорится (прим. Badoo: хороший пример. На нашем масштабе потребление CPU критично, мы достаточно много занимаемся оптимизацией потребления CPU и обычно сильно выигрываем от оптимизаций языка).
Стоит отметить, что, по всей вероятности, в рамках работы над JIT мы захотим сделать OPcache (или хотя бы его большую часть) элементом основного движка, а не отдельным расширением.
- (Бонус) в сочетании с некоторыми другими разработками, это всё-таки может улучшить производительность веб-приложений.
Чтобы вы понимали, о каком приросте производительности идёт речь, я записал сравнение бенчмарков PHP 7.0 и экспериментальной JIT-разработки: https://www.youtube.com/watch?v=dWH65pmnsrI
Асинхронность
Мы должны сконцентрироваться на улучшении поддержки долгоживущей (long-running), асинхронной модели исполнения, ориентированной на микросервисы. Вероятно, не секрет, что одной из главных причин популярности Node.js является его умение очень эффективно обрабатывать огромное количество одновременных подключений, генерирующих относительно лёгкие запросы. Это хорошо соответствует особенностям современных микросервисных архитектур. Есть уже несколько проектов, которые реализуют в PHP аналогичную функциональность, например, ReactPHP и более свежий Swoole.
Но главная проблема в том, что большинство операций ввода-вывода в PHP не поддерживают асинхронное исполнение. Я считаю, нам нужно добавить как можно больше поддержки асинхронного ввода-вывода в различных расширениях и потоках, чтобы расширить круг задач, где имеет смысл применять инструменты типа Swoole. Точнее, нужно предложить авторам расширений механизмы, которые те могли бы использовать для реализации опциональной асинхронности своих расширений/функций, не делая всю работу самостоятельно. Мы уже провели некоторые исследования в этом направлении, и нужно сделать гораздо больше, но я оптимистично настроен. Возможно, для решения этой задачи мы возьмем libuv, и, возможно, перепишем или отрефакторим некоторые части системы PHP-потоков.
Интерфейс внешних функций (Foreign Function Interface)
Это позволит подключать PHP к нативным библиотекам, написанным на С или С++, без необходимости создавать расширение. Я понимаю, это может выглядеть не сильно лучше, чем расширения, но если оценить не только сложность реализации, но и возможное влияние этого нововведения, то станет понятен его масштаб. Это позволит гораздо чаще использовать PHP в сочетании с «передовыми» технологиями, такими как искусственный интеллект и машинное обучение; да и не только с уже существующими сегодня — это своеобразный «задел» для использования в будущем с технологиями, которые будут появляться. Дмитрий (прим.: Дмитрий Стогов) уже добился определённых результатов в этом направлении. Последние пару недель он потратил на создание биндингов TensorFlow для PHP, и написал, судя по всему, первую нейросеть на PHP: она распознаёт рукописные цифры с точностью 98%. Думаю, что в сочетании с JIT это превратит PHP в настоящую рабочую лошадку для исполнения тяжёлых приложений, не ставя под угрозу продуктивность разработчиков. Кстати, чтобы этот механизм работал действительно быстро (особенно в паре с JIT), мы, скорее всего, объединим его с основным движком, а не будем делать его отдельным расширением.
Поддержка предзагрузки
Мы обсуждали это несколько раз на высоком уровне, но если внедрим JIT в PHP 8, то поддержка предзагрузки может неплохо его дополнить. Она позволит разрабатывать «расширения» на PHP, а не только на С (или FFI). В сочетании с JIT стоимость написания логики на PHP сильно упадет, и это будет лучше с точки зрения и простоты и безопасности. Кроме того, предзагрузка может значительно повысить скорость работы веб-приложений, поскольку мы сможем разрешать определённые зависимости (в основном, наследование) именно в ходе компилирования, а не исполнения. (прим.: Дмитрий Стогов дал нам более конкретное описание этой идеи: «Идея — загружать PHP-скрипты при старте PHP; функции и классы, определённые в них, будут доступны всем request-ам без всяких include/require. По сути, это даёт возможность писать стандартные библиотеки на PHP». Обсуждение этого можно почитать тут.)
Замечу, что этот список:
- Неполон. Если здесь не упомянута какая-то фича, это не означает, что её не будет в PHP 8.
- Не высечен на камне. Нам, конечно же, нужно иметь RFC по каждой упомянутой идее, но мы можем не справиться с реализацией каких-то из этих идей.
Этот список — ряд направлений, в которых мы провели определённые исследования (в некоторых — даже очень серьезные, как в случае с JIT), и которые являются прочной основой для начала дискуссии о PHP 8 и превращения PHP 7.3 в последний релиз в семействе PHP 7.x. Если бы нам пришлось на основе всего вышеупомянутого сформулировать предположения о сроках готовности PHP 8 к выпуску, то, вероятно, это будет через 2—2,5 года (то есть середина/конец 2020-го). Также можем обсудить очень скромный релиз PHP 7.4 где-нибудь в 2019-м, в котором не будет добавлено нового функционала, но который позволит нам объявить устаревшим (deprecate) всё, что действительно того заслуживает, и что мы забыли объявить устаревшим в PHP 7.3, чтобы позволить всем заранее подготовиться к PHP 8.
С помощью этого письма я хотел бы понять отношение к переносу усилий на создание PHP 8 после релиза 7.3, а также послушать ваше мнение о вышеописанных фичах. Если отзывы будут положительными, думаю, следующим шагом станет написание RFC «PHP 8 как следующий feature-релиз PHP», с возможными положениями о 7.4; а затем отдельные обсуждения всех вышеупомянутых (а также других) нововведений. Можем попробовать сформулировать некий график, но какие-то пункты могут быть сдвинуты вправо (до определенного предела), если их исследование/разработка/доводка потребует больше времени.
От себя добавлю, что радостно видеть активное развитие языка в последние годы и здравое стремление команды работать как над производительностью, так и над «генерализацией» языка и улучшением его возможностей. Все направления работы выглядят многообещающими, особенно интересными для нас являются улучшения потребления CPU и возможность работы с асинхронным вводом-выводом.
А что вы думаете об описанных планах на PHP 8 и перспективах PHP в целом? Делитесь вашими мыслями в комментариях.
