PHPNG

grigori

( ͡° ͜ʖ ͡°)
Команда форума

В списке рассылки разработчиков PHP объявлено о начале тестирования проекта phpng, в рамках которого ведётся работа над следующим поколением интерпретатора для языка программирования PHP, отличающегося переходом на новый вариант движка Zend Engine, в котором будут воплощены новые идеи по организации работы с памятью и применению технологий JIT-компиляции. Итогом разработки станет выпуск PHP 5.7, примечательный существенным увеличением производительности выполнения скриптов. В настоящее время начальная версия phpng уже доступна для сборки и тестирования.

Сообщается, что с момента выпуска PHP 5.0 наблюдается значительный прогресс в области увеличения производительности PHP - скорость выполнения синтетических тестов увеличилась в 6 раз, а ускорение выполнения реальных приложений оценивается в два раза. При разработке новой ветки большое внимание уделяется экспериментам с технологиями JIT-компиляции. В частности, на базе LLVM подготовлен прототип встроенного в OPCache JIT-компилятора, что позволило по сравнению с PHP 5.5 увеличить скорость выполнения тестового набора в 10 раз, но в реальных приложениях ускорение составило всего несколько процентов.

Различия в показателях тестов и реальных приложений заставили задуматься разработчиков и провести более глубокую ревизию возможных узких мест, устранение которых позволило бы добиться более ощутимого прогресса в оптимизации. Сама по себе виртуальная машина уже достаточно хорошо оптимизирована, но проблема оказалась в методах работы с памятью и организации хранения структур данных. В текущем виде, работа со структурами данных приводит к большому числу операций выделения и перераспределения памяти, а также подсчёта ссылок на структуры для работы сборщика мусора. В итоге, типичное PHP-приложение тратит примерно 20% времени на выполнение задач менеджера памяти, 10% на обработку хэш-таблиц, 30% на вызов внутренних функций и только 30% на выполнение кода в виртуальной машине.

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

В среднем изменения позволили добиться увеличения производительности реальных приложений на 10-30%:

  • Wordpress 3.6 – 20.0% (было 211, стало 253 запросов в секунду)
  • Drupal 6.1 – 11.7% (1585/1770 запросов в секунду)
  • Qdig – 15.3% (482/555 запросов в секунду)
  • ZF test app – 30.5% (166/217 запросов в секунду)
Из идей по проведению дальнейших оптимизаций отмечается:
  • Оптимизация вызова и возврата из функций;
  • Замена Zend Memory Manager на xx_malloc, что позволит увеличить производительность приблизительно на 2%;
  • Переработка очень медленного API zend_parse_parameters();
  • Сокращение объёма данных, копируемых из областей разделяемой памяти OPCache в память процесса;
  • Переход на libpcre с поддержкой JIT-компиляции регулярных выражений;
  • Замена ext/json на pecl/jsond.


таки JIT.
https://wiki.php.net/phpng
http://news.php.net/php.internals/73888

 
Последнее редактирование модератором:

HraKK

Мудак
Команда форума
Только смысла нет, Расмус 146% зарежет.
 
  • Like
Реакции: AmdY

tony2001

TeaM PHPClub
1) про совместимость в userspace:
I would say it must be 100% compatible at the end, may be with exception
for very rare and unclear cases that worked just because of existing
implementation. (e.g. mixing foreach and next() on the same array).
про совместимость API:
Yes it does require changes in the extensions. I must say we’ve been able to hammer through them pretty quickly but it does require change due to the refactoring of the data types. It’s a refactoring exercise though not a rewrite. So relatively speaking not too painful and I think we’ve already worked through many of them so there are a lot of examples.
2) про Расмуса:
вы с Линусом не путаете?
это Линус - "благожелательный диктатор"(с), а Расмус - один из участников комьюнити.
 

HraKK

Мудак
Команда форума
Один из, но имея большой авторитет он влияет на коммьюнити.

про совместимость API:
Интересно, а Zephir как затронут данные изменения, если таки выкатят.
 

hell0w0rd

Продвинутый новичок
HraKK, я так понимаю, что затронут. Но зефир, я думаю, поддержит это вполне быстро, когда будет переписан с нуля:)
в зефире хорош синтаксис, более-менее работает парсер, код внутри - это жесть, которую нужно переписать с нуля. Сейчас зефир покрыт грубо говоря функциональными тестами - но сам компилятор тестами не покрыт и внутри реальная жесть.
https://github.com/phalcon/zephir/blob/master/Library/ClassDefinition.php#L613 - начиная от супер гигантских методов, заканчивая отсутствием кастов \Reflection* к \Zephir\*Defenition.
С другой стороны недавно был переписан let-statement, то есть все что связанно с присваиванием - вот это была самая жесть.
А может и не затронет https://github.com/phalcon/zephir/tree/master/runtime
 

Вурдалак

Продвинутый новичок
В свете появления hacklang я не понимаю увлечения зефиром. Да и до production ready, я уверен, первый быстрее дойдет.
 
Последнее редактирование:

hell0w0rd

Продвинутый новичок
Вурдалак, это два совершенно разных подхода.
hack - php-based язык, запускающийся только под hhvm, да, там все круче чем в php, много вкусных фишек, но это другой язык.
zephir - это штука, позволяющая с удобным php-based синтаксисом писать расширения под php. Какие-то узкие куски кода совершенно спокойно можно вынести в чистый си и главное не вдаваясь в внутреннее устройство php. То есть при большом желании все это можно допилить до использования в той же hhvm
 

AmdY

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

Вурдалак

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

И да, php-based, ога. В обоих случаях это новые языки, причём hacklang — это superset, а Zephir — это вообще что-то непонятное.
 
Последнее редактирование:

HraKK

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

Если что-то пойдет не так с хаком - у меня такой возможности нет.
 

HraKK

Мудак
Команда форума
Эм. Ну нельзя как бы из пыха юзать хаковские классы) мб я что-то пропустил) но по-моему, это не совместимые языки)

Для наглядности - я переписываю фреймворк на зефир, и потом мне не важно фреймворк у меня как пхп или как модуль. А с хаком такое не прокатит.
 

AmdY

Пью пиво
Команда форума
HraKK, т.е. ты поддерживаешь две ветки кода - библиотеку на пыхе и её аналог на зефире?
 

HraKK

Мудак
Команда форума
AmdY, типо того. Но, если честно - это еще до продакшена не дошло, так что все пока в теории и на песочной практике.

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

Koc

Новичок
как-то слишком много возни ради 30%. Поддерживать параллельно 2 версии - дело непростое. Я там понимаю, если б в 2-3 раза быстрее было.

Не могу понять, в чем сложность зефиру поддерживать нативный пхп? чем их синтаксис так кардинально отличается, что его легче парсить?
 
  • Like
Реакции: AmdY

HraKK

Мудак
Команда форума
как-то слишком много возни ради 30%
Согласен, поэтому мы только очень нагруженные участки поддерживаем. А так в принципе - да, не айс из-за того что не совместим.

Времени кстати уходит не много, можно самому наверное написать парсер пхп в зефир, легко переделать.
 

hell0w0rd

Продвинутый новичок
Koc, есть некоторые отличия. Ну и если втупую писать на зефире - прирост конечно небольшой. Например если используется рекурсии - прироста не то что не будет, скорее будет все наоборот, а если рекурсию пихнуть в си - все будет в шоколаде.
https://github.com/phalcon/zephir/issues/177
Тут вот человек как раз про рекурсию спросил и привел пример с числами фибоначи. Вот вам мои замеры:
Код:
Zephir time: 0.0059828758239746
Zephir without C time: 23.107372999191
PHP time: 22.278899908066
И так во всем. По сути сейчас зефир - это немного другой байткод, а выигрыш идет за счет того, что он уже загружен в оперативку и оптимизируется gcc.
С другой стороны у Андреса, на сколько я знаю, есть идея, как транслировать код в нативный си, а методы php просто биндить к этому нативному си, тогда внутренние вызовы функций (внутри библиотеки, которую вы пишите) будут полностью на си, то есть никакого оверхеда на вызов, переменные будут передаваться нативно, возврат из функции тоже нативен. Такой подход сейчас используется в DI пхалкона.
 

tony2001

TeaM PHPClub
Фибоначчи - это хорошо, конечно.
Очевидно, что PHP (и почти любой другой скриптовый язык) проиграет тут C с разгромными числами.
Однако, веб-приложения в своём большинстве не состоят целиком из математических вычислений, поэтому разница в 440 000% достижима только в подобных синтетических тестах.
Собственно, именно поэтому тот же Стогов сразу говорит именно о приложениях, а не о каких-то бенчмарках вычисления степени или взятия корня.
 
Сверху