HipHop PHP

Статус
В этой теме нельзя размещать новые ответы.

PHP_Master

Хранитель порядка
Регистрация
3 Фев 2008
Сообщения
2.639
Реакции
601
Высказываем свои мысли, господа.

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

С доработкой тоже проблем особых не вижу, так как в продакшене сначала всё обкатывается на dev-серверах.

Меня больше интересует прирост производительности, а с этим не всё понятно и однозначно.
 
То что они пишут насчет производительности 50% скорее всего так и есть поскольку компилированный С всегда будет быстрей PHP. Они вроде обещали выложить все исходники, что бы и другие могли пользоваться, некто не видел?
 
На заборе тоже много чего написано...

Возможно, производительность чистого PHP и возрастёт на 50%. Может и больше.
Но как часто используется чистый PHP?
От того, что скрипт будет переведён в нативный бинарник, скорость работы с БД или файловой системой особо не возрастёт.
 
А откуда прирост производительности берется? Я что-то из англ. статьи не особо понял. Ну хранят они бинарники, ну чем это так уж лучше APC иже с ним? Что в apc типа отдельно в памяти php висит и как бы "выполняет" псевдокод? Ну так замени весь псевдокод на call <функция либы> и перенеси libphp в *.so - то же самое ведь фактически будет по скорости. И при чем тут вообще Си, почему не Фортран? Результатом ведь есть бинарник, зачем вообще говорить, на каком языке был к нему исходник (тем более что мы-то знаем, на php он был)?

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

Короче мое мнение - оно не будет особо выигрывать по сравнению с кешем опкода. Толку от того, что ты вынесешь всю php-либу из одного бинарника и всунешь ее в другой.

Но реально думать и рассуждать можно долго. Надо раз потестить и все станет ясно.
 
А откуда прирост производительности берется?
Оттуда, что нативный бинарник и опкод (даже кэшированный) - это не одно и то же.
Ну так замени весь псевдокод на call <функция либы> и перенеси libphp в *.so - то же самое ведь фактически будет по скорости.
Ты пробовал?
И при чем тут вообще Си, почему не Фортран? Результатом ведь есть бинарник, зачем вообще говорить, на каком языке был к нему исходник (тем более что мы-то знаем, на php он был)?
Бинарники полученные с разных языков не одинаковы по скорости выполнения.
 
Бинарники полученные с разных языков не одинаковы по скорости выполнения.

Все от компилятора зависит, и от либ. Да, есть там различия fastcall/stdcall и пр., но это все совсем уж слезы, тем более на современных процах. Остаются либы - либы тут все так и остались из PHP. И судя по тому, что сам PHP и так писан на сях, что-любо ускорять внутри этих либ особо не собираются.

Что еще? Переключение контекста? Его и так нет, и выполнение опкода, и "вкомпиленный" бинарник выполняются одинаково. Дальние вызовы? Ну может быть, я в такие дебри zend не лазил. Хотя тоже вряд ли, скорее всего там обычные 0xC9 xx xx xx xx.

Что еще остается? Memory management, весь i/o - все это стандартное от php. Остается еще время на разбор опкода против времени на выполнение "собранного" бинарника. Собирать бинарник можно по-разному, но что-то мне подсказывает что тут "транслированный" опкод сразу на eip. Это в лучшем случае, в худшем - все тот же опкод+обработчик. Ну ладно, считаем что в фейсбуке не дураки и реально генерят шитый код из php'шного опкода. Да, это должно быть быстрее, но опять же - на сколько? При нынешних-то гигагерцах..

Что я упустил? Откуда 50% ускорения? Может это если сравнивать с парсингом?
 
Да, есть там различия fastcall/stdcall и пр., но это все совсем уж слезы, тем более на современных процах.
Слёзы для хомяка. А если каждый день отдаются миллионы страниц, приличная экономия получается.
но что-то мне подсказывает что тут "транслированный" опкод сразу на eip. Это в лучшем случае, в худшем - все тот же опкод+обработчик.
Откуда такие страшные догадки?
Исходя из статьи, там анализ php-кода -> трансляция в c++ -> полноценная оптимизация/компиляция нативного бинарника.
Да, это должно быть быстрее, но опять же - на сколько?
Собственно, с этого вопроса я и начал топик :)
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху