В списке рассылки разработчиков PHP объявлено (http://news.php.net/php.internals/73888) о начале тестирования проекта phpng (https://wiki.php.net/phpng), в рамках которого ведётся работа над следующим поколением интерпретатора для языка программирования PHP, отличающегося переходом на новый вариант движка Zend Engine, в котором будут воплощены новые идеи по организации работы с памятью и применения технологий JIT-компиляции. Итогом разработки станет выпуск PHP 5.7, примечательный существенным увеличением производительности выполнения скриптов. В настоящее время начальная версия phpng уже доступна (https://wiki.php.net/phpng) для сборки и тестирования.
Сообщается, что с момента выпуска PHP 5.0 наблюдается значительный прогресс в области увеличения производительности PHP - скорость выполнения синтетических тестов увеличилась в 6 раз, а ускорение выполнения реальных приложений оценивается в два раза. При разработке новой ветки большое внимание уделяется экспериментам с технологиями JIT-компиляции. В частности, на базе LLVM подготовлен прототип встроенного в OPCache JIT-компилятора, что позволило по сравнению с PHP 5.5 увеличить скорость выполнения тестового набора в 10 раз, но в реальных приложениях ускорение составило всего несколько процентов.
Различия в показателях тестов и реальных приложений заставили задуматься разработчиков и провести более глубокую ревизию возможных узких мест, устранение которых позволило бы добиться более ощутимого прогресса в оптимизации. Сама по себе виртуальная машина уже достаточно хорошо оптимизирована, но проблема оказалась в методах работы с памятью и организации хранения структур данных. В текущем виде при работа со структурами данных приводит к большому числу операций выделения и перераспределения памяти, а также подсчёта ссылок на структуры для работы сборщика мусора. В итоге типичное PHP-приложение тратит примерно 20% времени на выполнение задач менеджера памяти, 10% на обработку хэш-таблиц, 30% на вызов внутренних функций и только 30% на выполнение кода в виртуальной машине.
При подготовке PHPNG основное внимание уделено изменению методов работы с памятью и переход на новые структуры (https://wiki.php.net/phpng-int) хранения данных, которые минимизируют число операций в куче. Идея переработки структур была связана с определённым риском, связанным с появлением непредсказуемых результатов глобального рефакторинга. Сейчас уже доступны первые результаты проделанной работы, которые показали, что разработчиками был выбран правильный путь, который привёл к существенному повышению производительности, снижению потребления памяти и стал хорошей предпосылкой к внедрению новых 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.
URL: http://news.php.net/php.internals/73888
Новость: http://www.opennet.me/opennews/art.shtml?num=39724
Т.е. теперь JS-истерика по переписыванию всего чего не надо на JS прекратится и начнётся PHP-истерика. Ведь PHP теперь сравним с Си:)
> PHP теперь сравним с Си:)это у тебя какой-то свой, принципиально новый, Си, раз с ним пхп можно сравнить?
Нет, это у тебя какой-то свой принципиально новый парсер шуток, проглатывающий смайлики.
s/новый парсер шуток, проглатывающий смайлики/фильтр тупых шуток/
Не-а. Если бы это был фильтр, то он просто бы эту шутку не увидел и не ответил бы.
Стоп! Тут принципиальный момент! На каком языке ваш парсер шуток написан? С или PHP? ;-/
На PHP и так написано подавляющее большинство сайтов. Так что ничего переписывать не надо.
Да кому сейчас сдались сайты, веб приложения вот где бабки.
> Да кому сейчас сдались сайты, веб приложения вот где бабки.О-о. Смышленый парень :-)
Хе-х. Лично я на тему перешел уже.
а просто парсер для LLVM написать слабо?
И как это повлияет на:
> но проблема оказалась в методах работы с памятью и организации хранения структур данных.?
Ускорение выполнение скриптов.. Извините а зачем оно надо? пользователь несколько милисикунд подождет, ничего с ним не случится. В пхп большая проблема с поддержание большого количества паралельных конектов, вот что нужно пилить. Чтобы 1000 одновременных запросов сервак держал, железо вполне позволяет, а пхп валится!
http://daemon.io/
сайт opennet отдает контент в 100 раз быстрее, чем php.
* отдаёт контент в 100 раз быстрее, чем php.
Это битрикс, детка! Привыкай.
> поддержание большого количества паралельных конектов, вот что нужно пилить. Чтобы 1000
> одновременных запросов сервак держал, железо вполне позволяет, а пхп валится!очень смешно, что коннекты забота php, я то думал что это проблема веб сервера, а интерпретатор работает с потоками.
иногда, когда погромисты на пхп слишком долго делают своё нечто, проблема пхп становится проблемой сервера.
Каким боком проблема php стала проблемой сервера, это даже 2 разные программы
> очень смешно, что коннекты забота php, я то думал что это проблема
> веб сервера, а интерпретатор работает с потоками.Первая мысль при прочтении заголовка -- "и как они собрались интерпретировать новое поколение?.."
По описанию особой "поколенности" не заметил -- скорее текущая работа по втягиванию того, что сто лет в обед надо было втянуть, заметив отечественный MMcache.
Молодцы, они придумали LLVM.
llvm как бы шире и глубже и раза в 4 старше.
>в 4 старшелолшто?
llvm? что хорошая штука?
Они попытались его применить, но не получили прироста производительности, потому что стадия разбора и выполнения кода и так уже достаточно быстра.К слову, производительность LLVM тоже далека от идеала.
Она даже от GCC далека
а есть вообще достойные альтернативы llvm?
Достойные по какому критерию?
Достойные альтернативы LLVM для использования в качестве чего?
> а есть вообще достойные альтернативы llvm?есть: forth, erlang
Представьте, если бы сайты на ASSEMBLER писали ? Вот это ДААААА. :) Сайт открывался бы за одну миллионную секунды :)
И закрывался бы также, фишка в том, чтобы ускорять только открытие...
Сайт открывался бы столько времени, сколько требуется на установку tcp-соединения и передачу данного объема данных пользователю.
Сайт открывался бы столько времени, сколько времени он тратил бы на IO и Базу, а разработка длилась бы столько времени, что программисту пришлось все-таки искать жену обзаводиться кучей детей. Есть шанс, что хоть они доживут до релиза.
> Сайт открывался бы столько времени, сколько требуется на установку tcp-соединения и передачу
> данного объема данных пользователю.Да гомно вопрос - кешируй в статику или используй статические страницы. Какой-нить сишный нжинкс тебе их вытрелит как из базуки. Хоть гигабит получи, если можешь столько откачать.
>Какой-нить сишный нжинкс тебе их вытрелит как из базуки.Ядро не даст. Больше пары сотен тысяч req/s - почти нереально.
>Хоть гигабит получи, если можешь столько откачать.
Говорить о bandwith в данном случае неверно - гигабит можно забить и одним огромным файлом.
Имеют значение пакеты в секунду и реквесты в секунду.
Угу, то-то на какой ASP-сайт не зайдешь, он от скорости аж поскрипывает. Особенно ASPX.
> Угу, то-то на какой ASP-сайт не зайдешь,StackOverflow?
...в котором от asp выпилили 90% всего
> StackOverflowЧто-то не заметил особой скорости. Быстро - это когда какой-нибудь nginx прямо выстреливает в тебя как из базуки всю страницу, за менее чем секунду, из кеша, как статику. Вот это реально быстро - пикнуть не успел, а тебе уже страницу показали.
на .net бинарники, может байт кодники?
внезапно - есть и такие SDK для Web-мастеринга.
и пакеты для "Web-писательства" на C++,к примеру.
но продаются оч. хреново, тк доминируют "неосиляторы".
когда последний раз кто-то писал что-то на нативном коннекте между SQL/NoSQL и Web-сервером ? то есть на бинарниках и UDF/DDL -онли ?
> Представьте, если бы сайты на ASSEMBLER писали ? Вот это ДААААА. :)
> Сайт открывался бы за одну миллионную секунды :)(пожимает плечами) есть vibe.d, например. статически типизированый компилируемый в native code язык плюс async i/o (хипстеры знают об этом из node.js). и что? для долбодятлов это всё равно чересчур сложно.
Хипстеры знают что async и nodejs это стильно, модно, молодежно.
> Хипстеры знают что async и nodejs это стильно, модно, молодежно.это да. (с ненавистью глядя на нодожысыкашу, в которой надо разобраться) удобство разработки им традиционно побоку.
типичное PHP-приложение тратит примерно 20% времени на выполнение задач менеджера памяти, 10% на обработку хэш-таблиц, 30% на вызов внутренних функций и только 30% на выполнение кода в виртуальной машинеблеск!
Интересно, есть ли сравнения с HHVM?
https://gist.github.com/hgfischer/7965620
> https://gist.github.com/hgfischer/7965620Зачем эта ссылка нужна? Там вообще не упоминается HHVM.
> Интересно, есть ли сравнения с HHVM?Тут есть http://www.techempower.com/benchmarks/
>> Интересно, есть ли сравнения с HHVM?
> Тут есть http://www.techempower.com/benchmarks/Очень странная таблица. Тут утверждается, что голый PHP работает быстрее HHVM. Притом в разы.
Ну так возьмите, проверьте, все исходники тестов выложены.
Поделитесь результатами.
Анон, подскажи: теперь с brand-new JIT движком, PHP будет таким же быстрым как Ruby, где его уже 8 год как впилили и лет 5 как крутят в продакшне?
>быстрым как RubyЭто была шутка такая?
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
>>быстрым как Ruby
> Это была шутка такая?Признавайтесь, зачем вы фракталы строите или блинную сортировку юзаете на сабже?
Я этого не делаю, но руби известен медленным интепретатором.Anyway, основная проблема уже не столько в пхп, сколько в выборках данных с бд.
> Признавайтесь, зачем вы фракталы строите или блинную сортировку юзаете на сабже?Не вижу чем построение фракталов, сортировка или любой иной алгоритм так уж плохи в целях бенчмаркинга и сравнения. А, понимаю, при этом не получается хвалить фетиш - становится понятно что это булшит :).
> Не вижу чем построение фракталов, сортировка или любой иной алгоритм так уж
> плохи в целях бенчмаркинга и сравнения.в том, что это очень специфические задачи.
Я не часто строю фракталы на руби, но когда я это делаю, я использую биндинги к OpenCL.
Эти бенчмарки имели бы хоть какой-то смысл, если бы в них использовались не дженерики, а объекты, и были бы задачи, которые используют встроенные либы, например работа со строками, регекспы, и т.д. потому что в реале все упирается в создание объектов и GC. И, кстати заметьте, еще over 10y ago, на PHP строго на строго рекомендовалось не использовать ООП, так ВК до сих пор и не использует, в то время как на руби за такой СиСтайл влегкую можно получить по морде кирпичом. Разные подходы.
И расскажите мне плиз, как они в этих бенчмарках умудрились получить такую странную правую колонку с распределением CPU по ядрам, если Ruby по определению однопоточный?
> И, кстати заметьте, еще over 10y ago, на PHP строго на строго рекомендовалось не использовать ООПВ PHP4 были большие проблемы с ООП в связи с костыльностью транслятора. Начиная с PHP5 с ООП никаких проблем нет, производительность не хуже процедурного варианта. К 5.3 вылизали чуть ли не до идеального варианта. Немножко не хватает шаблонов, как в сях, увы, и возможности перегрузки методов и функций.
>шаблонов, как в сяхТы наверное имел в виду темплейты из крестов? Упаси б-же.
Темплейты из крестов, на мой взгляд, — полумера. /Не видел кода(но слышал) на PHP уже 5 лет/ Дайте народу миксины, рефлекшны и Object.metod_missing?. PHP имхо не хватает ООП не в стиле крестов@11||14, а в стиле Java, ну и back-to-the-roots Smalltalk. Но тут, конечно, я очень субьективен и разбиваю ваши мечты.
И еще, без всякого троллинга, в PHP уже появились и широко используются атавизмы функционального программирования типа лямбд? На руби можно писать очень быстрый код в 100% функциональном стиле, convention over configuration, вот это все.
да, анонимные функции появились в 5.3насчет reflection не понял, если ты имел в виду reflection api, то да - такое есть.
Миксины сделали в 5.4 виде traits, по сути с другого боку, но всё оно же. Рефлекшн есть с 5.1 начиная, если память не изменяет. Лямбды (если речь об анонимных функциях-замыканиях) начиная с 5.3 есть.Вообще язык очень сурово подрос с момента 4.х и даже 5.0, в последнее время даже не вызывает потребностей вида "блин, ну когда уже эта фича".
> Миксины сделали в 5.4 виде traits, по сути с другого боку, но
> всё оно же.даже не знаю, то ли смеяться, то ли обнять и плакать…
Скорее бы в стабильный релиз новый интерпретатор попал. Вот это было бы реально круто. Как не крути, а PHP - самый популярный ЯП для бекэнда.
> Скорее бы в стабильный релиз новый интерпретатор попал. Вот это было бы
> реально круто. Как не крути, а PHP - самый популярный ЯП
> для бекэнда.Он еще и реально удобный. Как по синтаксису (C-подобен), так и по возможностям. Причём для бэкенда не обязательно вёбного. Главное - не перебарщивать с кодом, максимум встроенных функций, минимум велосипедов.
а я продолжу спрашивать, какое логичное там применение для сигилов.
> а я продолжу спрашивать, какое логичное там применение для сигилов.1) variadic variables/functions/methods - наверное, основное и единственное применение: $myObject->$varMethod($params), к примеру
2) явное наследие перла
3) всё-таки с баксом перед переменными код на самом деле слегка читабельнее
> 1) variadic variables/functions/methods - наверное, основное и единственное применение:
> $myObject->$varMethod($params), к примеруи никто не применяет. да и сигил в php — не совсем обычный оператор, в отличие от sh, например, где это именно оператор.
> 2) явное наследие перла
где сигилов много, и они таки имеют смысл.
> 3) всё-таки с баксом перед переменными код на самом деле слегка читабельнее
ну да: пишешь — и сразу баксы видишь. ;-)
проще говоря: сигилы в php — это карго-культ в основном.
> и никто не применяет. да и сигил в php — не совсем обычный операторЯ бы сказал - совсем не оператор, а именно variable prefix. Что же до юза:
$instance = new $class();
- весьма типовая и применительная конструкция, инстанциация объекта заранее не известного (определяемого на этапе выполнения) класса.
> Я бы сказал - совсем не оператор, а именно variable prefix.«consistency? не, не слышали! чо? хреново скопировали sh, не понимая, как там что работает? да пошёл ты!»
Что насчет standalone приложений. Уже можно наконец-то будет потоки или сопля к апачу?
> Что насчет standalone приложений. Уже можно наконец-то будет потоки или сопля к
> апачу?Пока все внешние библиотеки не превратятся в thread safe - не будет. Потоки номинально есть, но требуют сборки с ZTS, и грозят костылями.
Новые «standrd restrictions»?
JIT в PHP бы не помешал, а то Node.js + JavaScript понемногу начинают вытеснять PHP.