Разработчики социальной сети Facebook представили (http://developers.facebook.com/news.php?blog=1&story=358) проект "HipHop" - новый открытый транслятор для языка PHP, распространяемый в рамках свободной лицензии PHP. HipHop трансформирует код PHP скриптов в высоко оптимизированное представление на языке C++, пригодное для дальнейшей компиляции при помощи g++ в машинные инструкции. Обратной стороной высокой производительности является принципиальное отсутствие поддержки некоторых PHP конструкций, таких как eval().В состав пакета входит транслятор кода, переработанный PHP runtime и набор переписанных с целью повышения производительность стандартных библиотек и расширений. По заявлению разработчиков использование HipHop позволяет увеличить скорость выполнения PHP скриптов как минимум в два раза. HipHop содержит более 300 тыс. строк кода и 5 тыс. unit-тестов, загрузить исходные тексты транслятора можно будет через несколько часов с сервиса GitHub (http://github.com/).
URL: http://developers.facebook.com/news.php?blog=1&story=358
Новость: http://www.opennet.ru/opennews/art.shtml?num=25268
Отличное название!
Я всегда говорил что любая интерпретируемая дрянь все равно надо или поздно вернется к нативному коду.
Да. Чем больше популярность языка, тем выше к нему требования, включая производительность.
Знаете, самое издевательское во всей скриптовой байде то что ПРОЦ НЕ УМЕЕТ ВЫПОЛНЯТЬ СКРИПТЫ :). В проц в любом случае пойдет поток команд. Потому что это единственное что он умеет выполнять. И весь вопрос лишь в том насколько черезжопным и неоптимальным методом этот поток будет получен. Есть более прямые и быстрые методы, есть менее прямые. А результат - одинаковый с точки зрения проца. Поток команд на выполнение. А вот его скорость работы может заметно варьироваться. Даже выполнение самого дебильного и тормозного интерпретатора вызовет в конечном итоге поток команд в процессор. Только сгенеренный очень уж неоптимально и сильно разбавленный бесполезными для решения задачи командами самого интерпретера (потому то интерпретеры без jit-компилера и всасывают по полной).
>Знаете, самое издевательское во всей скриптовой байде то что ПРОЦ НЕ УМЕЕТ
>ВЫПОЛНЯТЬ СКРИПТЫ :). В проц в любом случае пойдет поток команд.
>Потому что это единственное что он умеет выполнять. И весь вопрос
>лишь в том насколько черезжопным и неоптимальным методом этот поток будет
>получен.Неа. Вопрос не весь. Еще есть такая штука, как архитектура. Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый, то еще неизвестно кто кого обгонит. Зато ясно, где будет меньше багов.
>Неа. Вопрос не весь. Еще есть такая штука, как архитектура.А тут все просто. По умолчанию подразумеваются равные стартовые условия для всех... ;).Т.е. более-менее адекватный архитект не делающий откровенных ляпов.
>Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемыйэто шедевр. а примеры будут?
>Зато ясно, где будет меньше багов
о, да. в одном случае получаем Parse error: syntax error, в другом кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта.
>>Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый
>
>это шедевр. а примеры будут?Java EE. И не надо говорить что она не компилируется - все нормальные VMы давно уже поддерживают JIT компиляцию.
тут кто-то говорит, что ява не компилируется? ужас, если вам такое послышалось, или показалось. в таких случаях креститься надо.
так в чем там заключается выражение "в триста раз больше вызовов функций"? вообще-то есть такая вещь, как библиотека. ее можно и статично прикрутить к бинарнику. да и выбрать библиотеку можно по потребностям. жабакодеры, вон, все писькомерством занимаются, сравнивая приложение, запущенное как серверный апплет с бинарником с внешними либами. меряют они скорость вызова функций. только лукавят, паразиты. в серверной апликации все в памяти, все вызываемые внешние функции. а умалчивают они о том, что бинарник можно статично компильнуть.
jit компиляция. ну давайте компильнем проектик какой-нибудь, а? ну я не знаю, фильтрование фотографий по алгоритму Гаусса, чтоли... размер фотографий - произвольный, цветовая гамма - тоже. но можно и ограничиться в 24 бита...
>это шедевр. а примеры будут?Можно пример. Скажем если есть массив из 100 000 000 записей, лобовой перебор такого числа записей с целью найти нужную на си проиграет быстрому поиску по b-дереву или хэш-таблице даже на тормозном интерпретируемом языке. За счет неоптимальности подхода. Но, заметьте, это изначально жульнические стартовые условия.
>о, да. в одном случае получаем Parse error: syntax error, в другом
>кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта.По моим наблюдениям - багов в скриптоподелиях обычно как минимум не меньше. А зачастую больше, т.к. ориентированность на рапидную разработку не оставляет времени для отлова багов а возможность быстро генерить навороченные конструкции приводит к массе багов и неожиданных посторонних эффектов. А потом начинаются - не buffer overflow так лажа в протоколах, SQL иньекции, иньекции кода, XSS, ...
>Но, заметьте, это изначально жульнические стартовые условия.конечно, как и все тесты производительности java vs c/c++ где первая по результатам - быстрее. ;) сравнения плюсов с дотнет - из той же оперы.
Ерунда. Основные тормоза у дисковой подсистемы и базы данных.
И у фейсбука, как я понял, только часть кода скомпилирована с помощью этой новой хрени.
Может есть резон сразу писать на Си или чем ином, для экономии не только ресурсов но и времени? А что будет - PHP или ASP - уже не так важно.
Если бы был нормальный компилируемый язык с GC, OO и нормальной работой со троками, то очень может быть, что на нем бы многие и писали.
буквально ради этого начал разбирать с D
там кстати открыли исходники родного компилятора, а gdc пока сливает
>буквально ради этого начал разбирать с D
>там кстати открыли исходники родного компилятора, а gdc пока сливаетЯ пока жду книги по D2. Выйдет - куплю, тоже начну разбираться.
Такой язык есть, это C++ :-)http://www.hpl.hp.com/personal/Hans_Boehm/gc/simple_example....
Тогда фейсбук был бы написан к 2100 году.
> Может есть резон сразу писать на СиМожно сразу писать на Си.
Но потом вы выделите часто использующиеся функции в отдельный модуль и с чистой совестью назовете его PHP2 ;)
Просто не воспринимайте PHP как язык программирования - это приведет к тому, что его действительно придется компилировать.
PHP - удобный интерфейс скриптов, обращающихся к часто использующимся функциям, которые кто-то до вас уже написал и оптимизировал. На Сях, конечно. При таком отношении к PHP переписывание чего-либо с начала теряет смысл. А вот если вы на нем начнете сочинять сложные конструкции... в общем, эта дорожка уже протоптана Фейсбуком ;)
Интересная ситуация получается. Автор пхп его разработал как раз для того чтобы не писать часто используемые функции на си. Сейчас фейсбук сделал обратную работу, вернул скрипты написанные в пхп обратно в си. Получается теперь мы пишем си программу с помощью каких-то макросов (пхп) которые уже транслируются в си. Очень смахивает на удаление гланд через опу.Тут как раз еще одна утилитка была бы кстати. Весь тот сишный мусор который будет выдавать хип-хоп обрабатывать ей и на выходе получать код на ассемблере! Эдак еще можно производительность повысить на несколько процентов.
php++ is alive.
Очередной костыль.
лучше бы нормальный fastcgi сделали - это решило бы проблему производительности для сложных проектов!
чем именно решило бы? Убрать затраты на вызов - да, добавить оптимизатор gcc - нет. Для среднесложных и сложных проектов затраты на вызов и БД - 10-20% времени. Товарищи пытаются оптимизировать остальные 80-90%, что, безусловно, благо.
>лучше бы нормальный fastcgi сделалиЧем FPM не устроил?
> это решило бы проблему производительности для сложных проектов!
Бред. Оверхед динамической типизации и интерпритации гораздо больше, чем оверхед серверного интерфейса.
обработка запросов в php-fastcgi,mod-php,FPM принципиально ничем не отличаются.
FPM это это улучшение, а не принципиальное изменение.Оверхед серверного интерфейса крайне незначителен.
Проблема в принципе работы PHP.Посмотрите как fastcgi реализовано у всех остальных и сравните с PHP.
Разница принципиальная!
>Очередной костыль.
>лучше бы нормальный fastcgi сделали - это решило бы проблему производительности для
>сложных проектов!Хинт: сам PHP от этого быстрее не заработает...
>Обратной стороной высокой производительности является принципиальное >отсутствие поддержки некоторых PHP конструкций, таких как eval().Интерстно а в нем можно частично перегнать пхп проект в С++ чтобы например теже eval оставить в PHP, и интестно как после пребразования будет осуществляться взаимодествие с PECL
пц )))
говорял я им использовать java )))
>пц )))
>говорял я им использовать java )))Да-да-да! я обеими руками за создание High-Performance Java-to-C++ compiler, и open-source-ного! вот это было бы дело.
А щас... ну, впрочем, может с этого HighPerformance-ПеХоПе удастся создать Python-to-C++ compiler, настоящий, а не костыляку в виде Shed Skin
> Да-да-да! я обеими руками за создание High-Performance Java-to-C++ compiler, и open-source-ного! вот это было бы дело.А что с gcc (gcj - GNU Compiler for Java) или VMKit? Чем не подходят?
gcj - на моих мелких тестах был втрое медленнее, чем оригинальная Sun-овская Java, даже c ключом -client, не то что "java -server". Я так и не понял почему, заметил лишь, что time показывал втрое большее число pagefault-ов - это-то один огромный экзешник, у которого все по-идее внутри!
Если бы GCJ хотя бы на 50% уступал java -server-у можно было бы заморачиваться, а так...
Кстати, у gcj вышла проблема с подгрузкой второго JAR-а, коим оказался junit, уж его-то можно было бы скомпилить без проблем.про VMKit не знал, - спасибо, гляну. при поиске по проектам LLVM не заметил - искал пакет полного цикла с компилятором - как Excelsior, скажем.
pagefault обычно возникают при пересечении границ памяти. чем корявее работа с данными (или сам код), тем больше количество pagefault. а у этого огромного екзешника и данные тоже внутри? то есть вы полагаете, что область данных и стека тоже входит в ваш екзешник? o_O
Тестовая программка оформлена как берущая вход со stdin, и выдающая в stdout.
Кроме этого никаких особенных данных не обрабатывалось, всё остальное - константы внутри class-файла, или соответственно, экзешника, в сегменте данных, если так удобнее Вам представить. Экзешник, кстати, должен был бы весь загрузиться в память функцией mmap (или CreateFileMapping/MapViewOfFile в случае Windows)- свободной памяти на машине для этого было предостаточно.Вопрос о вхождении стека в экзешник, по-моему, отношения к делу не имеет.
То есть, да, в основном внутри.
чисто технически, если это большой екзешник, то и делает он много. если работа с stdin и прочим проходит без буфера обмена и других вещей, то работу с памятью предугадать сложнее. это будет зависеть напрямую от организации внутренних областей памяти по умолчанию.
в яве еще нужно приплюсовать время на создание объектов, даже для работы со строками (стандартной) нужно создание объектов. даже, если происходит работа с текстовыми константами. вполне вероятно, что у сановской явы включены по умолчанию ключи оптимизации. в конечном итоге испробуйте оптимизацию -O2 или -O3.ну и здесь можно посмотреть как раз по инициализации статичных классов (опции):
http://gcc.gnu.org/onlinedocs/gcj/Code-Generation.htmlгде-то должна быть разница. кстати, ява все-таки очень интенсивно работает со стеком, но, скорее всего, дело не в этом.
уже есть )
http://www.excelsior-usa.com/jet.htmlтолько он не нужен )
>уже есть ) >http://www.excelsior-usa.com/jet.html
>только он не нужен )1. Есть: коммерческий и с закрытыми исходниками
Были б были открытые я бы кое-что подправил, есть одна хорошая идея.2. Почему не нужен, кому не нужен, по какой причине?
Java - самый распространённый ЯП по индексу TIOBE, 20% программистов
Вдвое обгоняя C. (10%). Но это в теории.А на практике на нем есть написанных куча серьезных опенсорсных программ.
Вот тем, кто их использует и не хочет изобретать велосипедов - нужен.
> А щас... ну, впрочем, может с этого HighPerformance-ПеХоПе удастся создать Python-to-C++ compiler, настоящий, а не костыляку в виде Shed SkinЕсть Pyrex и Cython, правда не в C++, а в обычный си.
Опять же, никому не нужно перекомпилировать весь проект из питона в си. Достаточно только самые много раз выполняемые участки кода типа циклов.
>>может с этого удастся создать Python-to-C++ compiler, настоящий, а не костыляку в виде Shed Skin
>
>Есть Pyrex и Cython, правда не в C++, а в обычный си.Насколько я помню, в них обоих, в скомпилированной программе, все равно есть питонтво, проявляется в том, что специально не указанные объекты там - все равно питоньи. И куча программного кода конвертирования объектов Python->C и C->Python. Вносящего ненужные задержки.
Идея Shed Skin-а как раз-таки чертовски хорошая (а реализация подкачала, сильно):
Получить автоматически zero-overhead код, все выводы типов сделает транслятор. Это же можно сделать автоматически, в конце концов!!то есть, базовая идея, что в HiPHoP, что в Shed Skin та же самая (может еще где, не знаю)
: а) Писать код на высокопродуктивном для прототипирования языке, динамическом, скриптовом, etc.
б) В продакшн компилировать исходники, отдельным инструментом, в нативный высокооптимизированный код. желательно без eval-ов.В итоге - создаем программу быстро. тестируем, и т.п. А в продакшн запускаем - тоже оптимальный код. но создается он не ручным конвертированием, а автоматически.
Тестироваине никто не отменял, но это уже детали.
>Опять же, никому не нужно перекомпилировать весь проект из питона в си.
>Достаточно только самые много раз выполняемые участки кода типа циклов.В теории да. Но не во всех случаях: в моем случае, для того Питон-проекта, он останется в меньшинстве, потому и желательно чтоб и вовсе не было.
>HipHop трансформирует код PHP скриптов в высоко оптимизированное представление на языке C++
>принципиальное отсутствие поддержки некоторых PHP конструкций, таких как eval()другими словами, патчей для оригинальной реализации не дождёмся. ценность для индустрии ноль целых ноль десятых
>другими словами, патчей для оригинальной реализации не дождёмся. ценность для индустрии ноль
>целых ноль десятыхвообще-то они сотрудничают с зенд-коре тим. Так что полюбому не пустая трата времени.
Патчей для оригинальной реализации? Так это метакомпилятор, это другое совсем. Это не JIT какой-нибудь чтобы его вделать в обычный пахапе и всё работало, но ускоренно.
>Патчей для оригинальной реализации? Так это метакомпилятор, это другое совсем. Это не
>JIT какой-нибудь чтобы его вделать в обычный пахапе и всё работало, но ускоренно.напомню фразу из статьи
>переработанный PHP runtime и набор переписанных с целью повышения производительность стандартных библиотек и расширений
>По заявлению разработчиков использование HipHop позволяет уменьшить нагрузку на CPU примерно на 50%.Только вот ведь недавно говорили что на 80%)
50 тоже очень не мало. Тут я думаю все зависит от специфики оптимизированного кода.
Дело не в том много или мало, а в том насколько достоверны данные, которые так быстро меняются
Кому-нибудь удалось найти исходники? Очень очень хочеться посмотреть !!!
Их девять утра это по-ходу ближе к вечеру будет.А github они уже зарегистрировали http://github.com/facebook/hiphop-php/
Пока можешь полюбоваться исходниками Roadsend PHP на Лиспе (точнее Scheme, ещё точнее Bigloo) :)
Ага, я с Roadsend как-то полгода назад баловался, тестировал - в большинстве случаев производительность наравне или хуже чем у оригинального php 5.2, синтаксис не на 100% поддерживает. Долго думал зачем он вообще существует.
>в большинстве
>случаев производительность наравне или хуже чем у оригинального php 5.2, синтаксис
>не на 100% поддерживает. Долго думал зачем он вообще существует.А ты как код гонял? Если plain CGI против modphp - то результат ожидаемый. А если при прочих равных, тогда гм...
cli , несколько бенчмарков на типовые операции, циклом на 10000 проходов. Я не хотел тестировать время загрузки скрипта, парсинг итд., мне нужна была только производительность.
До каких-то CGI или modphp тестов дело просто не дошло потому что это поделие банально не смогло нормально распарсить нашу фирменную cms (papaya cms), изза каких-то недопониманий синтаксиса. Можно было бы конечно повозиться недельку и адаптировать, но смысл?
>>в большинстве
>>случаев производительность наравне или хуже чем у оригинального php 5.2, синтаксис
>>не на 100% поддерживает. Долго думал зачем он вообще существует.
>
>А ты как код гонял? Если plain CGI против modphp - то
>результат ожидаемый. А если при прочих равных, тогда гм...если в сети покопаться можно аналогичные результаты найти, мне просто тогда убедиться хотелось
upd. Да, здесь де ссылок на существующие альтернативы не давали. Исправляю оплошность:* http://www.roadsend.com/ - roadsend. Компилятор php->c. Написан на Scheme
* http://www.phpcompiler.org/ - PHC. Ещё php->c. Использует исходники Zend'а, flex/bison и ещё немного haskell. Классический GNUтый проект. Его код лёг в основу PHP для Parrot'а
* http://www.php-compiler.net/ - Phalanger. Не путать с предыдущим проектом. Этот делает код под .Net (mono вроде поддерживается) и распространяется под одной из microsoftовских OpenSource лицензий.
* http://www.caucho.com/ - Quercus - компилятор PHP в JVM, распространяется в составе Java веб-сервера Resin. Двойное лицензирование. OpenSource версия вроде урезана.
upd. Точнее сам phс haskell код не использует, но использует некую bison подобную утилитку maketea, на нём написанную.
вот интересно, зачем было придумывать себе трудности, а потом геройски их решать? может надо было выбрать что-нибудь другое, а не PHP?
> может надо было выбрать что-нибудь другое, а не PHP?да вы что, это же нужно думать перед тем, как начинать делать. человекам в целом это не свойственно.
единственные, наверное, ваятели крупных соцсетей, которые подумали до того, как начать писать -- linkedin.
> может надо было выбрать что-нибудь другое, а не PHP?им надо было выйти на рынок как можно быстрее а лучше еще быстрее чем можно, а не сделать красивый проект к 2015 году just for fun.
facebook начинался как студенческое поделие, отсюда и похапе. рынки тут не при чём совершенно.
>facebook начинался как студенческое поделиедаконечно. начинали как студенческий сайтег и через несколько лет отгрохали датацентр.
сами в это верите?>отсюда и похапе
нет блин, надо было писать на перле и всю жизнь ловить глупые баги
>даконечно. начинали как студенческий сайтег и через несколько лет отгрохали датацентр.
>сами в это верите?разумеется. рост социальной сети - вещь совершенно не прогнозируемая.
>нет блин, надо было писать на перле и всю жизнь ловить глупые
>багине блин, надо было писать на java и c(++).
Оно бы да - надо. Да только что же поделаешь если кто то _уже_ написал код который делает то что нужно. Переписывать? Опять же - хорошо бы, да только вот кто оплатит банкет?Впрочем поживём увидим, если SugarCRM и Wordpress скомпилируют и оно заработает - тады ДА!
О! Кстати тады уродам из Zend - капец! :)
4 февраля, ХипХопа никто не видел. На GitHub пусто.
>4 февраля, ХипХопа никто не видел. На GitHub пусто.У нас ещё 3-е :)
Поправьте новость, ничего они не открывали, не колумбы все же... Ведь скачать ничего нельзя, а значить это брехня....
8 февраля и опять ничего :)
выпустили README:This is a placeholder file (это они об этом самом Readme.md) as we work towards releasing the HipHop source code. We really wanted to have it out by now, but have run into some build/compilation issues when removing certain Facebook-specific extensions.
Within the next few days (and maybe even sooner) we'll release an initial copy of the source code<...>
Want to know more, take a look at the [http://groups.google.com/group/hiphop-php-dev/browse_thread/... thread] on the developer list.
Наконец вчера открыли.лежит тут:
http://github.com/facebook/hiphop-php