Компилятор PHP от Roadsend

[master_x]

Компилятор PHP от Roadsend

Заявленный на www.roadsend.com компилятор, умеет компилировать PHP-код в модули для Apache и естественно в исполняемые файлы для nix-платформ и для Win тоже.
Означает ли это новый виток в эволюции PHP? Означает ли это, что язык PHP пригоден для написания серъезных систем в мире коммерческого софта?
Профессиональная версия компилятора стоит на 500 долларов дороже самой дешевой версии Zend Encoder, однако позволяет делать намного больше.
Естественно, что скомпилированный модуль для Apache будет работать во много раз быстрее чем скрипт. Это позволяет быстро (ведь как никак при тестировании PHP остается интерпретируемым языком) создавать приложения в которых критическими параметрами являются скорость и нагрузка.
Еще один приятный момент состоит в том, что PHP опять таки утирает нос платформе .NET

Смущает только одно: Apache- бесплатный, PHP- бесплатный, а вот за компилятор, выпускающий модули для бесплатного сервера, написанные на бесплатном языке, придется платить...

В общем ваши соображения по этому поводу, кто как видит будущее.

 

[confguru]

Не всякий поставит сторонний модуль в apache
тем более что php5 и Apache2 не поддерживается..
Хотя идея интересная..

 

[alexhemp]

Не вижу ничего революционного. По моему это естественный путь зарабатывания денег на раскрученном продукте.

есть же в конце концов perl2exe ;-)

open source не значит что нельзя поставлять утилиты за деньги.

Тем более, если компилятор не использует кода Zend Engine то он может быть вполне коммерческим продуктом. Ведь существуют коммерческие компиляторы скажем с языка C.

 

[master_x]

open source не значит что нельзя поставлять утилиты за деньги.

Это понятно, меня вышеуказанное просто *смущает*

-~{}~ 05.09.05 19:51:

Не всякий поставит сторонний модуль в apache

Если модуль нужен большой компании, то поставят. А на shared хостинге кто с этим возиться станет.

-~{}~ 05.09.05 19:52:

есть же в конце концов perl2exe

он умел компилировать код в мод для Апач?

 

[безграмотный]

Интересно, действительно ли компилируется с его помощью php код в нативный код платформы или только запаковывается байткод в исполняемый exe файл? Возможно ли в принципе скомпилировать php код в нативный код?

 

[alexhemp]

безграмотный
почему нет?

master_x
ABI исполнимого файла и ABI апачевского модуля - одинаковы. Нет в этом ничего принципиально невозможного.

 

[Profic]

alexhemp
И как ты скомпилишь

include (isset($_GET['page']) ? basename($_GET['page']) : 'main') . '.inc.php';

?

 

[alexhemp]

Profic

А что тут, позвольте, сложного. Например логика include может быть такая - смотрим есть ли в приложении скрипт с именем указанном в аругменте и переходим к исполнению его скопилированного кода, по окончании возвращаемся обратно.
А задача разработчика - закинуть в приложение все нужные скрипты - ведь они из воздуха не беруться.

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

Есть же понятие Runtime Library где такие-ф-ции могут быть реализованым. Конечно eval и include портят жизнь разработчику компилятора, но традиционно Web-приложение состоит не из одного скрипта, а из нескольких, поэтому этот момент достаточно легко учесть.

 

[Profic]

Согласен, пример не совсем иллюстрирует проблему. Я имел ввиду, что делать с кодом генерящимся на лету? Или берущимся из базы данных? Я конечно понимаю, что в нормальных приложениях такого не должно встречаться. Но интеритируемый язык невозможно скомпилировать так, чтобы не потребовался интерпритатор.
Возможно, если этот компилятор таки компилирует в бинарный код, в нем нет поддержки того же eval-а.

 

[ONK]

Profic, для полный совместимости с документированным ПХП, модулю придётся дополнительно таскать с собой стандартный ПХП экзекутор, впрочем он может включаться в бинарник только если в скрипте встречаются eval или динамические вызовы include* require* с заранее неизвестными путями.
Вот если выкинуть eval и наложить некоторые другие ограничения, то можно обойтись и без экзекутора. Но в этом случае лучше сразу заняться разработкой ВМ, которая бы преобразовывала бы ПХП опкод в оптимизированный поток процессорных инструкции и кэшировала бы их на подобии ZA (с опкодом). Может это будет ПХП 7?

 

[Profic]

Дык bytecode cache уже в 6 хотят включить. (Но не значит что включат.)

Про include (eval видимо так же):

Handling Include Files
...
At compile time, if PCC encounters one of the include functions, it will attempt to find the source file to be included (searching the current INCLUDE_PATH) for inclusion in the build. If it finds the file, that file will also be compiled and will be included as part of the resulting binary (or library).

If the file was not found, however, it is not a fatal error. When the compiled code is run, the file to be included will be searched for at runtime (based on the current runtime INCLUDE_PATH), and if found will be interpreted on the fly. While this may be convenient and useful in some situations, remember that interpreting code at runtime is always slower than compiling the code into the binary.
...

(с) http://www.roadsend.com/p/manual/viewManual.php?pageID=faq&doc=index.html&prIDX=2&doc=ch03s06.html
Что и требовалось доказать

 

[master_x]

ну разве же сложно писать программу без:

с кодом генерящимся на лету? Или берущимся из базы данных?

как мне кажется ради скорости и прочих фич можно пожертвовать "неизвестными путями" и кодом из базы...

Я вот думаю они наверное должны предоставлять гарантию того, что мой скрипт будет работать нормально, если я откомпилирую его их продуктом? Я имею в виду, что они должны обезопасить разработчиков от ошибок, которые они допустили в компиляторе и библиотеках (если таковые имеются). А если нет? То получается, что они меня снабжают обновлениями за те деньги, что я им заплатил, а я в свою очередь подсовываю эти библиотеки клиенту? Нехорошо получается, и так n раз? Пока их продукт не достигнет соверщенства? Ведь во всяком продукте имеются ошибки...

-~{}~ 05.09.05 23:08:

Вообще было бы интересно, если бы Zend выпустил подобную вещь...
Еще хотелось бы, чтобы был компилер (опен-сорс) для создания модов для апача (на PHP). вучит наверное глупо... но все же.

 

[ONK]

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

 

[jdoe]

master_x

повтори свои рассуждения, заменив "компилятор PHP от Roadsend" на, например, "компилятор C++ от Microsoft", и пойми, что сказал фигню. =)

--

я очень сомневаюсь, кстати, что в этом компиляторе не используется zend engine, ибо компилировать в натив-инструкции много проще из zend-опкода. да и правильнее это, иначе запаришься все время переписывать компилятор.

 

[master_x]

повтори свои рассуждения, заменив "компилятор PHP от Roadsend" на, например, "компилятор C++ от Microsoft", и пойми, что сказал фигню. =)

И что же мы имели в виду? Даже интересно.

-~{}~ 06.09.05 00:06:

что PHP опять таки утирает нос платформе .NET

тебе не нравятся эти слова, так я еще раз их повторю, потому, что действительно утирает. Если раньше нельзя было компилировать в бинарники на PHP (как в .NET) то теперь можно, а PHP сам по себе легче, на нем писать гораздо быстрее, и процесс отладки быстрее. Теперь подумай сам, почему я сказал эту "фигню". И впредь по внимательнее читай посты и анализируй, анализируй.

-~{}~ 06.09.05 00:07:

хотя я вообще-то не телепат,

 

[jdoe]

>Я вот думаю они наверное должны предоставлять гарантию того, что мой скрипт будет работать нормально, если я откомпилирую его их продуктом?

я про это.

гарантий, кстати, на софт не предоставляет вообще НИКТО. приписка AS IS есть всегда.

 

[master_x]

ну тогда ты вообще не прав, ты сравнил компилятор С++, с компилятором PHP... ты меня умиляешь. Еще раз говорю, анализируй. Слишком дорог этот продукт чтобы продавать его AS IS

 

[jdoe]

смешной ты.
почитай лицензионные соглашения.

 

[svetasmirnova]

jdoe
Для коммерческих программ?

 

[jdoe]

ARTICLE IV: WARRANTY

Section 4.01 -- Warranty: Customer hereby acknowledges and agrees that
Roadsend, Inc (including Roadsend, Inc officers, employees, agents,
directors, independent contractors, affiliates, distributors and
successors) has not made or granted any warranties concerning the System,
the Services and Roadsend Compiler for PHP. Specially including but not
limited to warranty of suitability for any particular purpose.

...

Section 4.03 -- Limitation of Damages: Roadsend, Inc shall not be liable
to Customer in connection with or relating to this Agreement, the System,
Roadsend Compiler for PHP and any transactions involving Roadsend
Compiler for PHP for any direct, indirect, lost profits, consequential,
exemplary, incidental or punitive damages, regardless of the form of
action, whether in contract or in tort, including breach of warranty and
negligence, regardless of whether Roadsend, Inc has been advised of the
possibility of such damages in advance or whether such damages are
reasonably foreseeable. Notwithstanding anything to the contrary, the
liability of Roadsend, Inc for any reason and for any cause of action
whatsoever in connection with or relating to this Agreement, the System
Roadsend Compiler for PHP and any transactions involving Roadsend
Compiler for PHP shall be limited to the license fee for Roadsend
Compiler for PHP.

да. скачал, смотрю. zend engine вообще не используется. процесс компиляции позабавил: php-код транслируется в bigloo-код, который транслируется в Си-код, который, свою очередь, компиляется с помощью gcc

-~{}~ 06.09.05 01:48:

да, на каких основаниях они распространяют в рамках своей ну совсем не open source compatible лицензии gpl-ный софт, пока что я не очень понял. но по моему кто то охренел слегка.