Компилятор PHP в байт код Си

Здравствуйте,
Есть несколько вопросов, для любопытных цели вопросов описал ниже.

1) PHP полностью написан на Си?

2) В момент выполнения код php транслируется в Си, а потом компилится в байт код Си?? Или сразу компилится в байт код??

3) Если верен первый результат, то логично что из PHP интерпретатора реально реализовать транслятор из php в Си, или нет??

4) Если нет, то в любом случае можно же создать официальный компилятор на в основе движка самого интерпретатора?


Цель моих вопросов в том, что хочу создать компилятор php -> Си -> байт код Си.
И реализовать на fastCGI, но при этом сохранить мелкоразмерные файлы подобия движков CMS, для возможного редактирование "на ходу", в данном случае "на ходу" это быстрое редактирование, компилирование и заливка мелких файлов.

Как мне сказали "тру-программеры" это повысит производительность не учитывая БД, -до коэффициента в 100 раз (СИшный байт-код).

Плюсы:
1) С помощью компилятора "php -> Си -> байт код Си" можно будет писать программы на php, но получать производительность байт кода языка Си без интерпретации(причем он будет в памяти висеть в случае с fastCGI).

2) Оставляя мелкоразмерные файлы можно так же будет мгновенно отлаживать небольшие файлы и быстро компилировать и заливать на сайт без остановки его работы (на подобие как сейчас с php, только нужно будет компилировать еще).

3) Компилятор поможет сообщать о некоторых ошибках сразу при компиляции, а не на сайте (а на модуле можно и уронить апачь)

4) Программистам поможет внедрять в код триал версии программы и предоставлять разработчикам его ограничивая по времени и скрывая исходный код, не боясь что его "кинут".

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

6) Для, хостеров будет выгодней держать больше пользователей с той же нагрузкой. Сами представьте когда на мощном сервере можно уместить еще в 10-30 раз больше пользователей (следовательно и прибыль в 10-30 раз).

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

Основная теория возможного выигрыша в том, что при быстром выполнение кода он будет меньше тратить процессорное время, а значит это процессорное время можно будет тратить даже на ту же БД или на сторонни задачи - что и есть выигрыш.

Жду вашего мнения, только скепсис и пессимизм просьба аргументировать.

(Отредактировано автором: 27 Января, 2009 - 19:01:25)

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

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

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

О самом fastcgi в php http://dklab[dot]ru/chicken/nablas/49[dot]html
Дальше по пунктам:

1. да.
2. байткод
3. см. 2
4. ничего не понял.. Что такое официальный компилятор на основе движка интерпретатора ?
Интерпретатор сам по себе это название разновидности компиляторов.

Сравнение акселераторов РНР: http://club[dot]shelek[dot]ru/viewart.php?id=300#post_p2
В другом случае я бы вам предложил сразу братсья за СИ и писать всё на нём.

Теперь по поводу премуществ:
1. Мы выяснили что чтоб превратить php в C потребуется еще третий средний интерпретатор
2. Придётся останавливать все процессы, заливать новый код и запускать всё заново. Помимо того как делить на маленькие части я не понял.
3. Когда об ошибках сообщает не важно в принципе. Главное чтоб сообщил и ты исправил.
5,6 . За свой скрипт я не волнусь, потому что за него отвечает хостер, а он у меня хороший. А за хостера я не отвечаю. Пусть делает что хочет. Главное чтоб у меня хорошо работало.
Кроме того это ему видимо придётся ставить все эти расширения и программы чтоб работал мой СИ байт код.

4. Тоесть расчитано на то, что код в нередактиробельном виде ? Замечательно =)
Для этого вовсе не обязателег Си. Берешь zend engine и разделяешь на интерпретатор и виртуальную машину коими он является. Долго модифицируешь и в результате на сервера оставляешь
только виртуальную машину. Интерпретируешь у себя.

вообщем вывод один - гораздо проще, легче и быстрее выучить С. Особенно если РНР для тебя не новенькое.

-----
Truly yours, Sasha.

valenok, прежде всего спасибо за нормальный ответ. Сколько раз не пользовался вашим форумом всегда получал адекватные ответы (разместил этот вопрос для пробы в двух других ресурсах, темы уже засрами в стиле юмора баша).


fastcgi я привел как реализацию, там уже для себя можно выбрать что до как.


За свои поиски нашел один популярный компилятор который у меня в режиме cgi работал тормазнее самого php в 1,5 - 2 раза. Поэтому хотелось бы на основе официального что то а не такой самопал =).


Это скорее реализация для слабоскоростного интернета, чтобы не заливать один cgi весом 10-20 мб, а заливать так же по файлам 50 - 100кб (вроде через API организуется, или может через отдельную подгрузку на подобие не препроцессора uploads)



Изначально так и хотел, это как раз бы была практика изучение этого языка. Но потом подумал реализовать некий транслятор PHP в Си (а потом и компилятор в одном лице).

Если начать прям с пустого писать веб сайты на Си то в конечном итоге оптимизации кода приведет наверно снова к нечто похожему интерпретатору PHP =)).Подобие "велосипеда" php тоже не интересно создавать.

Поэтому основная идея это транслятор из PHP в Си ну и потом компилятор.

(Отредактировано автором: 27 Января, 2009 - 21:07:32)

Несколько раз прочитал пост и так и не понял, за счет чего должна производительность повышаться ? Если вы хотите выиграть на экономии трансляции из php в байт-код - то он и так акселераторами кэшируется (не видел ни одного хостинга без акселератора), на интерпретацию время почти не тратится. Если вы хотите как fast cgi процессы не закрывать - то для чего городьба с php? это чистый c++ fastcgi. Я что-то недопонимаю ?

Stierus
Акселераторы кушают память, процессорное время и прочие минусы в разных осбтоятельствах.
Бинарник бы работал лучше.

Основная цель трансляция php в С.
То есть к примеру взять этот форум и перевести си-байт код.
И грубо говоря получится что заказывать дедик придется не при 3-4к пользователей в сутки, а уже при 10 - 15к (ну так грубая аналогия)
.
Выигрышное процессорного временя может уже уйти на реализацию сложных задач - фичь для сайта или на ту же БД (пусть кушает сколько хочет).

И такой транслятор позволит и в дальнейшем писать на простейшем php, не утруждая себя изучением Си.

(Отредактировано автором: 27 Января, 2009 - 23:03:15)

Viraban009 Я конечно не могу полностю знать всю суть вашей задумки...
И транслятор в C/C++ код это конечно тоже полезно и интересно...
Но может все-таки вам будет интересно воспользоватьс услугами ZEND ENCODER + ZEND OPTIMISER
Вы также получите защищенный скопмилированный байт-код и кстати эту технологию применяются в некоторыз платный CMS

Stierus Да это батенька уже скорее к написанию *никсовых демонов относится
ИМХО писать незакрываемые PHP программы не есть очень гут уж если что писать демоны на Perlе

(Отредактировано автором: 28 Января, 2009 - 00:10:32)

Не мог бы описать, как ты представляешь работу акселератора, как работу "бинарника" и чем второе выигрышнее первого ? А то, может, я просто не совсем понял твою задумку, но пока, действительно, не вижу, на чём выигрыш.

OFF TOP

Почему не гут ?

Попробую аргументировать
1 PHP изначально предназначен всетаки для работы из-под Apache (Ну или из-под CGI) а Perl изначально наоборот
2 Инструменты для работы с сетью в Perlе получше чем в PHP да и работа с процессами особенно под *никсы там гораздо лучше (А демоны часто взаидодействую с дуригми процессами)

3 А вообще демоны лучше на C/C++ писать конечо

(Исправлено - убрано про time_limit)

(Отредактировано автором: 28 Января, 2009 - 11:27:42)

Соглашусь в плане работы с сетью, а так же в том, что Perl куда лучше работает с процессами (была, помнится, необходимость сделать нормальный форк - мучался на PHP, в итоге сделал только псевдомногопоточность)
Однако в плане time_limit .. все решается соответствующими настройками.

-----
Есть в мире две бесконечные вещи - это Вселенная и человеческая глупость. Но насчет первой .. я не уверен.

Кстати... А что если человек хотел транслятор с РНР на Си...
Следите за руками... раааз, а вот и...

пример из жизни
Помню в универе нашем, матфаковцы все писали на паскале, а потом транслировали в Си и сдавали преподу... Ибо 3-и курса их учили паскалю, а потом препод сменился.

Возможно чел хотел автоматический транслятор+компилятор... Запускается РНР разборщик, смотрит на РНР код, переводит его на СИ, затем скармливает с предустановками GCC, и бинарники складывает в кеш...
И собственно выполняется уже не РНР файл а скомиленный из него бинарник.

(Отредактировано автором: 28 Января, 2009 - 12:24:51)

-----
Тамбовский каджит тебе товарищ

именно это я и хотел

нечто по теме
http://au2.php.net/manual/en/intro.bcompiler.php

ну. как говорится.

Осталось только подождать.

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

Резюмирую
Сейчас все компиляторы для РНР, работают как VB6, что очень медленно. Если же РНР можно будет компилировать "по настоящему", это реально может понравится многим "не web" программистам.

(Отредактировано автором: 28 Января, 2009 - 19:57:08)

-----
Тамбовский каджит тебе товарищ

ZEND ENCODER & Co это точно не то что вам надо?

JustUserR
в действительности я не ищу этот транслятор, я хочу сам его написать для тренинга изучения языка С (ну то есть и изучение и чтение кода в данном случае PHP интерпретатора).

Первое что я хотел от темы это получить ответы на вопросы 1-4 (ответы получил).
Второе узнать мнение по моей цели, вопросы 1-6 (ответы получил).
Ну и перестраховаться если есть уже готовые трансляторы в Си (чтобы велосипед не изобретать).


Принципе на все вопросы я получил ответы, тему можно сносить в архив (или закрыть).

PS Сам процесс такое моего проекта пройдет в длительном времени, так как является по большей части стимулом для изучение Си.

(Отредактировано автором: 29 Января, 2009 - 09:41:43)