собственно разбор многомерного массиве $_GET
Скажите как выглядет такой запрос "многомерный" в URL?
Или тут просто программисты перестраховались на случай нововедений в будущее стандарты??
...в преимуществах и возможностях скорость не фигурирует...
блин, а нафиг они тогда бредом этим занимается (это я не автору поста, а авторам компиляторов).
Я чет совсем не пойму, создавать бредо-байт-код который там в каплю быстрей (а иногда может и на ровне или даже тормазнутей) - естественно стимула не какого (с легко редактируемого PHP переходить в CGI) не станет.
Если речь идет на разработку приложений для ОС'ей, то это как из самоката делать велосипед.
Самокат изначально для своих целей был создан.
PS
Я так понял именно из-за этих "супер компиляторов" у многих в голове отложилось то, что в бинарник переводить PHP не рентабельно.
Я вот чисто логически поросуждаю (на базе PHP + eAccelerator не fastCGI ):
Логика для веб ресурса - скажем форума или CMS.
Берется файл читается, парсится, переводится в байт код и прогоняется на вирт-машине PHP.
При повторном обращение, eAccelerator кэширует часть и уже получаем прирост от 11 - 22 (из обзоров сравнения акселераторов).
В этом моменте тратится ресурсы процессора на сам акселетор, его память + его кэш кода и еще что-то. Плюс память самого PHP и там виртуальной машины его (грубо говорю, так как не важно).
Что происходит с бинарником как CGI
Он без всяких акселераторов, без дополнительных расходов процессорного времени и лишней памяти выполняется посылая опкод процессору, читая просто с stdin и возвращая в stdout...
Отсюда по логики скорость CGI должно быть выше любого акселератора (так как не тратится время проца на сам акселератор), плюс больше памяти свободной (причем ощутима в масштабах).
Почему в реале не так?? На Си даже ядро ОСи и софт пишут, но вот он получается не быстрей чем интерпретируемый фреймворк, который там такую обработку проходит что уму не постижима...
PS
Не будем вдаваться в подробности работы PHP, я просто хотел показать логику рассуждения (а не точность).
компилятор я смотрел, на память не скажу какой, но в поиске он есть в топе и есть небольшие статьи о нем. Правда у некоторых скриптов производительно в cgi в разы меньше оригинала php (работа со строками), лично тестил.
(о нем вроде тут уже упоминал).
JustUserR
в действительности я не ищу этот транслятор, я хочу сам его написать для тренинга изучения языка С (ну то есть и изучение и чтение кода в данном случае PHP интерпретатора).
Первое что я хотел от темы это получить ответы на вопросы 1-4 (ответы получил).
Второе узнать мнение по моей цели, вопросы 1-6 (ответы получил).
Ну и перестраховаться если есть уже готовые трансляторы в Си (чтобы велосипед не изобретать).
Принципе на все вопросы я получил ответы, тему можно сносить в архив (или закрыть).
PS Сам процесс такое моего проекта пройдет в длительном времени, так как является по большей части стимулом для изучение Си.
Кстати... А что если человек хотел транслятор с РНР на Си...
Следите за руками... раааз, а вот и...
пример из жизни
Помню в универе нашем, матфаковцы все писали на паскале, а потом транслировали в Си и сдавали преподу... Ибо 3-и курса их учили паскалю, а потом препод сменился.
Возможно чел хотел автоматический транслятор+компилятор... Запускается РНР разборщик, смотрит на РНР код, переводит его на СИ, затем скармливает с предустановками GCC, и бинарники складывает в кеш...
И собственно выполняется уже не РНР файл а скомиленный из него бинарник.
Stierus
Акселераторы кушают память, процессорное время и прочие минусы в разных осбтоятельствах.
Бинарник бы работал лучше.
Основная цель трансляция php в С.
То есть к примеру взять этот форум и перевести си-байт код.
И грубо говоря получится что заказывать дедик придется не при 3-4к пользователей в сутки, а уже при 10 - 15к (ну так грубая аналогия)
.
Выигрышное процессорного временя может уже уйти на реализацию сложных задач - фичь для сайта или на ту же БД (пусть кушает сколько хочет).
И такой транслятор позволит и в дальнейшем писать на простейшем php, не утруждая себя изучением Си.
valenok, прежде всего спасибо за нормальный ответ. Сколько раз не пользовался вашим форумом всегда получал адекватные ответы (разместил этот вопрос для пробы в двух других ресурсах, темы уже засрами в стиле юмора баша).
Цитата:
Во первых когда твой процесс будет постоянно висеть в памяти, то загруженность сервера будет больше
чем если бы утром вася запустил скрипт на твоем сайте, а вечером петя другой сайт на том же хостинге.
О самом fastcgi в php http://dklab.ru/chicken/nablas/49.html
fastcgi я привел как реализацию, там уже для себя можно выбрать что до как.
Цитата:
Что такое официальный компилятор на основе движка интерпретатора ?
За свои поиски нашел один популярный компилятор который у меня в режиме cgi работал тормазнее самого php в 1,5 - 2 раза. Поэтому хотелось бы на основе официального что то а не такой самопал =).
Цитата:
Помимо того как делить на маленькие части я не понял.
Это скорее реализация для слабоскоростного интернета, чтобы не заливать один cgi весом 10-20 мб, а заливать так же по файлам 50 - 100кб (вроде через API организуется, или может через отдельную подгрузку на подобие не препроцессора uploads)
Цитата:
В другом случае я бы вам предложил сразу браться за СИ и писать всё на нём.
Изначально так и хотел, это как раз бы была практика изучение этого языка. Но потом подумал реализовать некий транслятор PHP в Си (а потом и компилятор в одном лице).
Если начать прям с пустого писать веб сайты на Си то в конечном итоге оптимизации кода приведет наверно снова к нечто похожему интерпретатору PHP =)).Подобие "велосипеда" php тоже не интересно создавать.
Поэтому основная идея это транслятор из 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 раз).
Единственный тормозящий ресурс тут будет база данных, но думаю можно будет реализовать кэш даже при динамичных изменениях (есть догадки).
Основная теория возможного выигрыша в том, что при быстром выполнение кода он будет меньше тратить процессорное время, а значит это процессорное время можно будет тратить даже на ту же БД или на сторонни задачи - что и есть выигрыш.
Жду вашего мнения, только скепсис и пессимизм просьба аргументировать.
Зачем в скрипте. Напишите shell-скрипт, сохраните его в Вашей системе. Там и укажите команду на sudo с паролем.
А в php-скрипте вызывайте написанный Вами шелл-скрипт. Это как вариант.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 83
