8 мая 2014 в 12:03

PHP New Generation перевод

PHP*
Немного вольный перевод письма Дмитрия Стогова на internal рассылку PHP сообщества, написанного 5-го мая.

Для знающих меня людей не секрет, что улучшение производительности PHP является моей главной обязанностью и увлечением в Zend. Вообще, начиная с PHP 5.0 мы уже шестикратно ускорили PHP в синтетических тестах и примерно двукратно в реальных проектах. Мы не прекращали улучшать ядро PHP и OPCache. Но все же, с релизом PHP 5.5 у нас не получалось сильно продвинуться дальше и вместе с остальным мы начали экспериментировать с менеджерами памяти, технологией JIT и другими потенциальными решениями.

Я потратил очень много времени экспериментируя с JIT, и даже сделал прототип прозрачного, основанного на LLVM, JIT компилятора встроенного в OPCache. Результаты для bench.php были восхитительны (0,219 секунд против 2,175 — десятикратный прирост для PHP 5.5), но для реальных проектов мы получили всего-лишь пару процентов прироста производительности. Это заставило нас всмотреться глубже в характеристики исполняемой среды и в то, что было по-настоящему бутылочным горлышком. Ясно, что виртуальная машина уже была хорошо оптимизирована, но она работала со структурами данных, постоянно требующими выделение и освобождение памяти и подсчет ссылок на значения. Обычное реальное PHP приложение тратит примерно 20% процессорного времени в менеджере памяти, 10% при операциях с хэш-таблицами, 30% во встроенных функциях PHP и всего-лишь 30% в виртуальной машине. Конечно же мы пробовали JIT только для кода виртуальной машины и в большинстве случаев этот код все равно делал теже самые операции с памятью. Поэтому мы решили сменить фокус и работать над этим крупным бутылочным горлышком. Идея состояла в изменении типов данных для оптимизации выделения кусков памяти. Это было очень трудным решением, так как нам нужно было начать огромный рефакторинг и мы понятия не имели повлияет ли он на что-нибудь вообще.

Я с радостью представляю вам результат нашей работы за последние четыре месяца. Это  рефакторинг ядра PHP, который существенно повышает производительность и улучшает  использование памяти, и главное дает фундамент для крупных улучшений в будущем, включая JIT. Я упущу технические детали (подробности опубликованы тут wiki.php.net/phpng), но  если двумя словами, то мы изменили фундамент попытавшись сохранить бОльшую часть здания  без изменений. Уже сейчас новое ядро дает 10-30% прироста производительности  не только в тестах, но также и в реальных проектах!

Некоторые тесты производительности:
Wordpress 3.6 – 20.0% прирост (253 vs 211 req/sec)
Drupal 6.1 – 11.7% прирост (1770 vs 1585 req/sec
Qdig – 15.3% прирост (555 vs 482 req/sec)
ZF test app – 30.5% прирост (217 vs 166 req/sec)

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

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

Но как нам кажется, мы достаточно уверены, чтобы открыть его для ривью, фидбека и поддержки сообщества. … Нужно еще много сделать для поддержки всех расширений PHP и продолжить дополнительно улучшать ядро.

Попробуйте отрефакторенный PHP и дайте ваш фидбек по производительности, использованию памяти и любым проблемам.
Ветку *phpng* можно найти на php.net. Есть также немного инструкций тут wiki.php.net/phpng. …

Я хотел бы отдельно поблагодарить Xinchen и Nikita за значительную часть проделанной работы!

Я надеюсь, что это новое ядро может сделать новую версию PHP, о которой мы так много говорим, намного интересней.

Всем спасибо!


От себя хочу отметить, что на прошлогодней конференции devconf, Дмитрия спрашивали про JIT и он как раз рассказал про их не совсем удачный опыт с ним. Но это письмо дает нам понять, что PHP все еще торт.

Также хочу отметить, что упомянутые Никита Попов (переводы его статей по php не однократно появлялись на хабре) и Xinchen Hui (и его проекты тоже светились на хабре) совсем молодые парни, влившиеся в сообщество всего пару лет назад. На таких энтузиастах держится не одно сообщество.

*Все ошибки в переводе или опечатки, грамматику и орфографию присылайте в личку, спасибо!
Автор оригинала: Dmitry Stogov
Александр @Irker
карма
109,5
рейтинг 0,0

Комментарии (73)

  • +10
    Кажется я начал понимать, как альтернативная реализация PHP, на виртуальной машине, написанной на каком-либо другом языке, может быть быстрее, чем нативная реализация PHP.

    А действительно, глобально парни за дело взялись. С задором.
    • 0
      альтернативная реализация PHP, на виртуальной машине, написанной на каком-либо другом языке, может быть быстрее, чем нативная реализация PHP.
      Вы под «PHP» подразумеваете интерпретатор языка PHP или приложения, написанные на языке PHP? Потому что и ВМ, и интерпретатор PHP, как я понимаю, оба написаны на С(++).
      • 0
        Виртуальная машина работает быстрее интерпретатора + оставляет простор для многопроходной оптимизации с помощью JIT.

        Это принципиально разные подходы к исполнению программ, и на чем что там написано не играет никакой роли, C++ иногда тоже бывает очень медленным.
        • 0
          Я об этом, собственно, и писал. Непонятно, что такое «нативная реализация» PHP. Не на PHP же она написана, и не в исполняемые двоичные файлы транслирует.
  • +12
    Будет здорово, если они изменят основной bottleneck PHP — умирать после каждого запроса, как в недавнем ReactPHP. Конечно, это куча работы, это будет опционально, но если это будет уже в самом PHP с должной поддержкой, то люди начнут перестраиваться.
    • –1
      Я думаю, что максимум, что можно сделать без переписывания кода это доработать ядро + менеджер процессов. А именно, сделать возможность хранить в памяти скомпилированный код, а после выполнения очередного запроса очищать память. Соответственно, придется только вручную управлять сбросом кеша кода при его изменении.
      • +9
        Так и работает OPCache
      • +2
        Возможность хранить в памяти даже не скомпилированный код (байткод т.е.), а сущности классов и функций, вот это невозможно сделать в пхп из-за его динамизма, когда например тело класса может поменяться, например в extends стоит название класса, который грузится через загрузчик классов, загрузчик классов может в разных ситуациях грузить физически разные классы под одним названием, с разными методами и телом. Из этого выливается то, что при каждом запросе пхп формирует каждый класс заново, на что уходит тоже много времени.
        • +1
          вы можете отключить это в opcache, и единыжды загруженный кэш до релоада сервера не будет меняться. Собственно это даже рекомендуется для продакшен экружения, ибо позяоляет не обращаться лишний раз к файловой системе за проверками.

          Собственно то что вы описываете не является сейчас узким местом. Узкое место это парсинг аргументов, выделение памяти, вызовы функций и т.д.
          • 0
            Если включается полное кеширование, то происходит всего лишь: поиск кеша по имени файла -> его загрузка без обращения к файлу. Однако загружается лишь байткод, из байткода еще нужно построить тело классов и функций, нет возможности держать классы и функции уже загруженными в разделяемой памяти.

            Вызовы и выделение памяти является также узким местом, я не спорю. На счет парсинга аргументов не совсем понимаю, проблема скорости парсера? Зачем над ней работать если есть кешер байткода.
    • +2
      Так у вас же есть ReactPHP, php-cli, php-pm и т.д. Причем тут ядро? Изменения в ядре помогут ускорить выполнение всего этого чуда, а умирать приложению после каждого запроса или передавать в воркеры и т.д. это уже вам решать. Так что это проблема не zend engine или php в целом, а конкретно инструментов. Вы уже сейчас можете взять тот же reactphp и писать на нем в стиле node.js или twisted.

      По поводу же «умирать», opcache как раз решает эту проблему. Если его настроить, у вас оверхэд на старт будет минимальным.
      • +1
        Кеш байткода как раз не решает проблему умирания, он только уменьшает затраты на лексический разбор кода. Скрипт все равно вынужден инициализироваться, загружать фреймворк, создавать его фабрики, объекты, и т.п, включая сборщики запросов для разных ORM и прочих моделей, драйверы кеша и базы данных, и уж потом прогонять по всей созданной структуре данных параметры запроса, передавая результат в шаблонизатор, который тоже предварительно должен быть инициализирован. После выполнения запроса все эти объекты оказываются не у дел и уничтожаются. В этом вся суть «создан умирать», в отличие от полноценной асинхронной архитектуры, где окружение инициализируется один раз и живет постоянно (создавая риски для утечек памяти, но это уже совсем другая история).
        • +1
          Опять же, это проблема не php а инструментов. В php есть реализация и event loop, есть многопоточность (пусть и не из коробки, но и в js ее из коробки нету)…
          • 0
            Многопоточность не относится к проблеме умирания. Выходом из проблемы умирания является демонизация работающего php-сценария. Для этого есть соответствующие решения. Но здесь как раз на передний план вылезают такие элементы ядра, как менеджер памяти и эффективный сборщик мусора.
            • +1
              Со сборкой мусора проблем последние года два я не особо наблюдал если честно, демоны-воркеры работают месяцами и не текут. А вот менеджмент памяти да, но это так же собираются рефакторить.
              • 0
                Сборка мусора, все же, отнимает существенную долю процессорного времени, порядка нескольких процентов. Его опимизация и рефакторинг, а так же настройка, могут повлиять на производительность и поведение сервера. Для примера, настройка по умолчанию сборки мусора в высоконагруженном потоке nodejs (порядка 1000 хитов в секунду) вызывает периодичесике пики 100% нагрузки. У php, насколько мне известно, сборка мусора основана на лимите ссылок. Хотелось бы получить больше информации об этом аспекте работы php на реальных проектах, если есть такой практический опыт.
    • +9
      Используйте не php. Там это уже давно так :] А пока в php от cgi модели не отойдут так все и будет работать.
      • +6
        Ну, я уже давно и не использую. Перешёл на Go.
      • –2
        Я с вас удивляюсь. Что мешает взять и отойти-то? Какое принципиальное ограничение?
        • 0
          Официально не поддерживается. Технически все php ПО работает по классической CGI модели. Там есть конечно костыли и подпорки которые это как-то улучшают, но перехода к FastCGI там даже не пахнет, так-как в этом случае придется менять принятые подходы к разработке на php.
          • 0
            Вы не ответили на мой вопрос. Что вам мешает написать настоящий FastCGI-сервер на PHP? Изучить спецификацию и написать?
            • 0
              Насколько я знаю попытки были. Но ничем хорошим они насколько я понимаю не закончились. Так-как php сам по себе в своей модели подразумевает только достаточно короткий цикл выполнения и смерть. Так что в случае долгоживущих процессов вылезут утечки памяти и фиговая работа сборщика мусора.
              • +1
                Во-первых, в PHP относительно недавно появился новый, годный сборщик мусора и демоны на PHP работают у нас неделями (их приходится перезагружать, но совершенно по другой причине).
                Во-вторых, течёт не сам PHP (это редкость), а всякие поделки с PECL, а их можно не использовать.
                • 0
                  Во-первых на данный момент нет официальной спеки на FastCGI у php. Во вторых те самые поделки из PECL часто нужны. И да эта же проблема мешает везде использовать php в паре чем-то отличным от mpm-fork в apache.
                  • +1
                    Да о чём вы говорите? Какой официальной спеки? FastCGI — открытый серверный протокол. Прочитайте и реализуйте на PHP сервер. Если поделки из PECL нужны, то проверьте, вдруг вам повезло и нужные не текут. А если текут, ничего не мешает написать свои или исправить существующие.
                    • 0
                      Да о чём вы говорите? Какой официальной спеки?

                      Я про разработчиков php имею ввиду. А что вы там сами на ваяете это ваше личное дело, только будет проблема с переносимостью и сопровождением вашего ПО.

                      FastCGI — открытый серверный протокол. Прочитайте и реализуйте на PHP сервер.

                      Я в курсе что он открытый. Вопрос именно в том что в этом случае вы создаете свое уникальное ПО. Которое никем кроме вас не будет поддерживаться в отличии к примеру от WSGI или PSGI которые стандартизированы.

                      Я вам как бы хочу мысль донести, что пока нет официальной поддержки для приложений по типу WSGI или PSGI, от того что на php можно сделать FastCGI демон, смысла никакого.
                      • 0
                        Ну вы знаете, вообще программисты только и делают, что создают своё уникальное ПО. В этом и заключается суть профессии.
                        • 0
                          Хороший программист, не создает проблемы тем кто будет эксплуатировать его ПО на ровном месте. Если есть штатный метод запуска, то и его и стоит использовать. Либо продвигать стандарт, а не заниматься стоянием в гамаке.
                          • 0
                            Конечно не создаёт. Только я не вижу как создание собственной реализации FastCGI создаёт проблемы. А вы рассматриваете это так, как будто одно вытекает из другого. Если вам нужно создать выскопроизводительный проект и скорость обработки запросов интерпретатором PHP ваше узкое место, собственный FastCGI — то, что необходимо сделать. Никаких проблем я тут не вижу.
                            • 0
                              Конечно не создаёт. Только я не вижу как создание собственной реализации FastCGI создаёт проблемы.

                              Создает. Для того чтобы запустить ваше приложение, стандартный php хостинг не подойдет. Там просто нет такой опции. Т.е. это надо будет брать VPS и настраивать там под ваше ПО. Так-как стандарта под FastCGI на данный момент в php нет.

                              Если вам нужно создать выскопроизводительный проект и скорость обработки запросов интерпретатором PHP ваше узкое место, собственный FastCGI — то, что необходимо сделать.

                              Тут есть ровно два противоречивых слова выскопроизводительный и PHP. Все эти рефакторинги, создание отдельных трансляторов, компиляторов php не от хорошей жизни.

                              И замечу, что в остальных языках, будь то java, perl, python, ruby есть стандартные методы взаимодействия веб-сервера с приложением. Это позволяет под них делать хостинги и хорошо повторяемые инсталляции.
                              • 0
                                Создает. Для того чтобы запустить ваше приложение, стандартный php хостинг не подойдет. Там просто нет такой опции. Т.е. это надо будет брать VPS и настраивать там под ваше ПО.
                                Какой хостинг вы о чём? Какие проблемы с производительностью у сайтиков на шаред-хостинге?
                                Тут есть ровно два противоречивых слова выскопроизводительный и PHP. Все эти рефакторинги, создание отдельных трансляторов, компиляторов php не от хорошей жизни.
                                Нет тут никакого противоречия. Вполне удаётся создавать такие проекты и на PHP. Рефакторинг есть везде, а создание компиляторов и интерпретаторов — естественный процесс эволюции, он у любого интерпретируемого языка происходит. Посмотрите на Пайтон (PyPy, Cython, Jython), Джаву (Dalvik), Руби (JRuby, Rubinius, MagLev), ДжаваСкрипт (V8, SpiderMonkey) и так далее.
                                • 0
                                  Какой хостинг вы о чём? Какие проблемы с производительностью у сайтиков на шаред-хостинге?

                                  Очень часто ПО начинает свой путь с сайтега на шаред-хостинге.

                                  Нет тут никакого противоречия. Вполне удаётся создавать такие проекты и на PHP.

                                  Угу. А потом начинается, рефакторинг и прочее.

                                  Рефакторинг есть везде, а создание компиляторов и интерпретаторов — естественный процесс эволюции, он у любого интерпретируемого языка происходит. Посмотрите на Пайтон (PyPy, Cython, Jython), Джаву (Dalvik), Руби (JRuby, Rubinius, MagLev), ДжаваСкрипт (V8, SpiderMonkey) и так далее.

                                  А что мне на них смотреть? Еще раз вам говорю, на данный момент в php нет стандартного метода разработки FastCGI приложений. Ни один существующий фреймворк этого не умеет и уметь не может. Так-как в стандартной модели работы веб-приложения на php, FastCGI нет. То что вы можете сделать свой велосипед я верю.
                                  • 0
                                    если это какой-то хоть сколько нибудь серьезный проект, но начинает он свой путь хотя бы с vds баксов за 5, а иногда сразу с aws и прочих облаков.

                                    Что до рефакторингов, это нормальная часть разработки. Без рефакторинга писать что-то серььезное с течением времени становится все сложнее и сложнее.

                                    Возьмите ReactPHP, его должно хватить для реализации того, о чем вы говорите. Запускается он как демон, можно на него проксировать запросы с nginx, для него есть биндинги фреймворков на базе HttpKernel, а это Symfony/Silex/Laravel.
                                    • 0
                                      Что до рефакторингов, это нормальная часть разработки. Без рефакторинга писать что-то серььезное с течением времени становится все сложнее и сложнее.

                                      Проблема в том что если изначально выбрана плохая арихитектура или не удачный язык. То все будет плохо.

                                      Возьмите ReactPHP, его должно хватить для реализации того, о чем вы говорите. Запускается он как демон, можно на него проксировать запросы с nginx, для него есть биндинги фреймворков на базе HttpKernel, а это Symfony/Silex/Laravel.

                                      Это не стандарт. Вы сами отлично должны это понимать. Плюс вот сейчас все что делается на этом поприще никак в официальную часть php не входит. Да на любом языке можно написать все что угодно. Вопрос трудоемкости. Я не вижу смысла брать для больших проектов php. Просто в силу самого php.
                                      • 0
                                        Любой другой инструмент так же не входит в стандарт, так что, его использовать уже нельзя? это глупо. В python так же нету подобных вещей из коробки, но есть twisted, который является дефакто-стандартом для подобных задач.

                                        Вы слишком привязываетесь к слову «стандарт». Наличие из коробки не всем нужно, а решения есть.
                                        • 0
                                          Для веба в Python как раз таки есть стандарт WSGI. У php тоже есть свой, но с CGI-моделью.
                                          • 0
                                            Вы так говорите, как будто это данность свыше и ничего менять не нужно. Twisted и WSCGI занимаются всё-таки разными вещами.
                                            • 0
                                              Вы так говорите, как будто это данность свыше и ничего менять не нужно. Twisted и WSCGI занимаются всё-таки разными вещами.

                                              Я говорю, что сначала надо подумать, что это даст и как это потом сопровождать. Я видел кучу ПО сделанного программистами, которое сложно сопровождать и ставить. Причем ПО может быть сколь угодно хорошим.
                                              • 0
                                                Это вопрос культуры разработки, этого хватает с любыми языками и технологиями.
                                                • 0
                                                  Проблема как раз в том что, сейчас культура разработки в php только втягивается.
                                              • 0
                                                Я не против того чтобы думать. У нас с вами специфика разная, я так понял. Я участвую в разработке выскононагруженного софта, срок жизни которого с десяток лет, а вы занимаетесь небольшими сайтами, я так понял.

                                                Отсюда и недопонимание.
                                                • 0
                                                  У нас с вами специфика разная, я так понял. Я участвую в разработке выскононагруженного софта, срок жизни которого с десяток лет, а вы занимаетесь небольшими сайтами, я так понял.

                                                  Высоконагруженный софт на PHP? Не завидую правда. Посмотрите на что в итоге это выливается на примере twitter и e-bay.
                                                  • 0
                                                    twitter — раньше ruby теперь scala+ruby, ebay насколько я помню так же не на php написан. И причем тут php?
                                                    • 0
                                                      У твиттера больше java чем scala. ebay был написан на perl в результате сейчас нагруженные части на c++/java. Это пример как люди в итоге отказываются от тех средств что не предназначенные под высокие нагрузки. А те кто остаются с php начинают писать костыли. Смотрим hip-hop и прочее.
                                                      • +1
                                                        Это нормально. Лучше потратить n времени написал проект на php/ruby и т.д, запустить бизнес раньше и получать прибыль раньше, чем потратить 3n времени, написать все круто на c++/d и утратить тот момент, когда проект взлетит. Если проект выстреливает — можно уже заниматься переписью узких мест. Это вполне нормальное явление, темболее что проектов масштаба twitter/facebook и т.д. не так уж и много.
                                                  • +2
                                                    Да нет, нормально всё. Чаще упирается в базу, а не в PHP.
                                  • +1
                                    Да забудте вы про shared, если там проблемы с производительностью, то надо переходить на отдельную виртуалку, а не писать собственный FastCGI.
                                    А потом начинается, рефакторинг и прочее.
                                    Рефактиринг будет всегда, если проект живёт длительное время, это никакая не проблема, а нормальный рабочий процесс.
                                    А что мне на них смотреть? Еще раз вам говорю, на данный момент в php нет стандартного метода разработки FastCGI приложений. Ни один существующий фреймворк этого не умеет и уметь не может.
                                    Ну и что? Все эти фреймворки (как и сам PHP) начаты как велосипед, что с того-то? Как будто это аргумент какой-то. php-fpm тоже начинался как патч одного человека к PHP и существовал отдельно. Ничего, теперь стандарт.

                                    Если что-то решает ваши проблемы, надо это использовать.
                                    • 0
                                      Да забудте вы про shared, если там проблемы с производительностью, то надо переходить на отдельную виртуалку, а не писать собственный FastCGI.

                                      Вот и я про то же. Очень часто можно вообще не писать свой велосипед.

                                      Рефактиринг будет всегда, если проект живёт длительное время, это никакая не проблема, а нормальный рабочий процесс.

                                      Конечно, только вот можно или сделать себе удобно или не удобно.

                                      Ну и что? Все эти фреймворки (как и сам PHP) начаты как велосипед, что с того-то? Как будто это аргумент какой-то. php-fpm тоже начинался как патч одного человека к PHP и существовал отдельно. Ничего, теперь стандарт.

                                      То что переход с CGI модели на FastCGI модель дело очень не быстрое. И смысла это делать в php сейчас, не вижу. И если у вас уже CGI модель, то перейти на FastCGI будет ой как сложно. Так что на данный момент я бы если мне уж сильно приспичило использовать PHP в FastCGI то я бы взял как раз ReactPHP и биндинг в один из фреймворков.

          • 0
            php-fmp насколько я помню это реализация именно fastcgi сервера. Собственно как мне помниться, развитие этих идей получилось в создании phpdeamon а уже потом в reactphp.
            • 0
              php-fpm не совсем то. Это, конечно, сервер FastCGI, но внутри он запускает PHP в режиме CGI.
            • +1
              php-fpm реализует интерфейс fastcgi для связи с веб-сервером типа nginx или apache, но делает это абсолютно прозрачно для приложения — для него (почти) нет разницы запускается оно как php-fpm, mod_php или просто cgi-«бинарник». php-fpm — оптимизация запуска интерпретатора, но не приложение — на каждый запрос оно полностью инициализируется.

              Php-daemon можно использовать как основу для своего fastcgi-сервера (собственно он уже реализован), но просто «скопипастить» вордпресс или джумлу не получится.
    • –1
      А что вам мешает на PHP-то написать правильный FastCGI?
  • +1
    The cake is a lie!
  • 0
    У кого-нибудь получилось собрать?
    • +3
      Собрал под Mint 15 (ubuntu 12.04) x64.

      PHP 5.7.0-dev:
      /bench.php — 0.838
      /micro_bench.php — 5.227

      PHP 5.4.9-4ubuntu2.4:
      /bench.php — 1.393
      /micro_bench.php — 6.711
      • 0
        Неплохо. У меня под freebsd не собирается
        • 0
          Можно попробовать собрать под 8.2 или 9.2. Но это займет побольше времени…
  • –2
    Одна просьба — если что-то революционное делать, то не называть это старым именем. Назовите не PHP NG, а PHN, хотя бы (но не PNG!), чтобы, разыскивая инфу в Гугле на тему нового варианта языка (а будет в Гугле поначалу 10 ссылок), не приходилось вслепую фильтровать для себя из 100 000 000 ссылок про «старый» вариант.

    • 0
      Это не новый вариант языка. Язык никак не изменяется.

      From: Dmitry Stogov

      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).
      • 0
        Да, это я заметил.

        Но, заметьте, по факту изменения серьезные, пусть и не в самом языке, но в том, как код исполняется. Хочется про 100% верить, но… не факт, что так и окажется (не сейчас, а по мере перехода на 5.7 и переносу туда всего многообразия модулей и библиотек). Так что подстраховаться с названием не мешает ))
        • 0
          По сути вас не должна беспокоить внутренняя кухня интерпритатора (ну как, должна но не в контексте ваших приложений), в этом же вся суть. То что не все расширения готовы — ну так 5.7 еще не скоро думаю выйдет, так что время на тестирование и прочее будет.
        • +2
          Довольно серьезные внутренние изменения в Zend VM были, например, между 5.3 и 5.4. Не думаю, что вы это заметили, если только не смотрели в исходный код ;)
  • 0
    Интереснейшее видео в тему от Facebook о проекте HHVM: www.youtube.com/watch?v=zBV9TkTXxg0 (рассказ об оптимизации начинается c ~ 27:00). Идея в измении структур данных таким образом, что бы минимизировать время чтения из памяти. Разница между скоростью доступа к RAM и L1/L2/L3 cache — огромна. Простой пример — если массив строк представлен как linked list, каждый элемент отдельно придется тянуть с памяти, и вероятность того, что все строки окажутся в кэше очень мала. С другой стороны, если все строки массива хранить в одном месте, вероятней всего железо сможет поместить весь блок в кэш.
    • +1
      Подобные вещи (про иерархию памяти, про принцип локальности данных и т.д.) должен знать каждый, кто пишет на языках программирования с ручным управлением памятью, хотя вообще про такие вещи полезно знать.
  • 0
    Главное это наличие Thread из коробки под обе платформы. Это позволит писать standalone приложения и выведет PHP с уровня запрос-приложение, на уровень сервер-приложения. Вообщем прирост скорости и необходимость разработки в многопоточной среде сразу даст мощьный пинок развития всем говнокодерам на PHP… Хотя надо ли это?
    • +2
      Говнокодерам на PHP треды из коробки не помогут, только вызовут больше проблем. А для не говнокодеров на php, они уже давно есть в виде экстеншена.
      • 0
        Последняя сборка 5.5.12 для Windows выдает следующее на мои попытки завести потоки

        Fatal error: Class 'Thread' not found in C:\Downloads\daemon.php on line 3

        Таким образом приходиться вести разработку только под Linux платформу, а мне (и возможно многим) это может оказаться неудобно.
        • 0
          Не удобно по началу, на самом деле есть масса инструментов облегчающих жизнь, которые под windows просто не запустятся (ансибл, докер), жить с нормальным башем как-то лучше чем с mingw… Да и что уж говорить про git для windows. Я хоть и не поклонник всех этих линуксов, но для работы и конкретно для backend разработки пожалуй лучше особо ничего и нету.

          Словом, если вам нужны потоки (именно нужны, а не просто прихоть), то поставите себе линукс или в крайнем случае завернете окружение в виртуальную машину и будете шарить через вагрант, что так же довольно удобно.
          • +2
            > Не удобно по началу, на самом деле есть масса инструментов облегчающих жизнь, которые под windows просто не запустятся…

            Это тема отдельного разговора, а мы тут про PHP.

            > Словом, если вам нужны потоки (именно нужны, а не просто прихоть), то поставите себе линукс

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

            > в крайнем случае завернете окружение в виртуальную машину и будете шарить через вагрант, что так же довольно удобно.

            Да, этот обходной прием сейчас часто и приходиться использовать, а это требует все большего количества инструментов и развития все более сложной инфраструктуры. А это требует поддержания еще и конфигурации, а это требует отдельного Configuration Manager.
          • +1
            Да и что уж говорить про git для windows.

            И какие же с ним проблемы? (давным давно использую и как-то не замечал проблем)
  • –9
    PHP6 и всякие попытки модернизации терпели фиаско. Им как бы ничего больше не остаётся, кроме как наращивать производительность.
  • 0
    Жаль что поддержки mysqli нет еще. Поддержка deprecated модуля mysql есть, а mysqli нет :(
    • 0
      Вы можете помочь проекту. :) Там портирование в основном сводится к замене ряда вызовов на другие по ряду правил. Если сравнить изменения в «старом» и «новом» ext/mysql — можно портировать mysqli по аналогии (разве что еще в каком-то из портированных расширений надо подсмотреть, как правильно портировать классы).

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