https://opennet.dev/openforum/vsluhforumID3/63498.html Разработчики социальной сети Facebook представили (http://developers.facebook.com/news.php?blog=1&story=358) проект "HipHop" - новый открытый транслятор для языка PHP, распространяемый в рамках свободной лицензии PHP. HipHop трансформирует код PHP скриптов в высоко оптимизированное представление на языке C++, пригодное для дальнейшей компиляции при помощи g++ в машинные инструкции. Обратной стороной высокой производительности является принципиальное отсутствие поддержки некоторых PHP конструкций, таких как eval().<br><br><br><br>В состав пакета входит транслятор кода, переработанный PHP runtime и набор переписанных с целью повышения производительность стандартных библиотек и расширений. По заявлению разработчиков использование HipHop позволяет увеличить скорость выполнения PHP скриптов как минимум в два раза. HipHop содержит более 300 тыс. строк кода и 5 тыс. unit-тестов, загрузить исходные тексты транслятора можно будет через несколько часов с сервиса GitHub (http://github.com/).<br><br>URL: http://developers.facebook.com https://opennet.dev/openforum/vsluhforumID3/63498.html#77 Sat, 20 Feb 2010 18:52:32 GMT Наконец вчера открыли.<br><br>лежит тут:<br>http://github.com/facebook/hiphop-php<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#76 Tue, 09 Feb 2010 00:15:26 GMT выпустили README:<br><br>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.<br><br>Within the next few days (and maybe even sooner) we'll release an initial copy of the source code&lt;...&gt;<br>Want to know more, take a look at the [http://groups.google.com/group/hiphop-php-dev/browse_thread/thread/2babfd7c38ccea06 thread] on the developer list.<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#75 Mon, 08 Feb 2010 09:54:06 GMT 8 февраля и опять ничего :)<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#74 Mon, 08 Feb 2010 05:49:41 GMT чисто технически, если это большой екзешник, то и делает он много. если работа с stdin и прочим проходит без буфера обмена и других вещей, то работу с памятью предугадать сложнее. это будет зависеть напрямую от организации внутренних областей памяти по умолчанию. <br>в яве еще нужно приплюсовать время на создание объектов, даже для работы со строками (стандартной) нужно создание объектов. даже, если происходит работа с текстовыми константами. вполне вероятно, что у сановской явы включены по умолчанию ключи оптимизации. в конечном итоге испробуйте оптимизацию -O2 или -O3. <br><br>ну и здесь можно посмотреть как раз по инициализации статичных классов (опции):<br>http://gcc.gnu.org/onlinedocs/gcj/Code-Generation.html<br><br>где-то должна быть разница. кстати, ява все-таки очень интенсивно работает со стеком, но, скорее всего, дело не в этом. <br> https://opennet.dev/openforum/vsluhforumID3/63498.html#73 Mon, 08 Feb 2010 00:40:43 GMT Тестовая программка оформлена как берущая вход со stdin, и выдающая в stdout.<br>Кроме этого никаких особенных данных не обрабатывалось, всё остальное - константы внутри class-файла, или соответственно, экзешника, в сегменте данных, если так удобнее Вам представить. Экзешник, кстати, должен был бы весь загрузиться в память функцией mmap (или CreateFileMapping/MapViewOfFile в случае Windows)- свободной памяти на машине для этого было предостаточно.<br><br>Вопрос о вхождении стека в экзешник, по-моему, отношения к делу не имеет.<br><br>То есть, да, в основном внутри.<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#72 Sun, 07 Feb 2010 12:36:20 GMT pagefault обычно возникают при пересечении границ памяти. чем корявее работа с данными (или сам код), тем больше количество pagefault. а у этого огромного екзешника и данные тоже внутри? то есть вы полагаете, что область данных и стека тоже входит в ваш екзешник? o_O<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#71 Sat, 06 Feb 2010 12:31:34 GMT &gt;Но, заметьте, это изначально жульнические стартовые условия. <br><br>конечно, как и все тесты производительности java vs c/c++ где первая по результатам - быстрее. ;) сравнения плюсов с дотнет - из той же оперы.<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#70 Fri, 05 Feb 2010 21:10:49 GMT &gt;Очередной костыль. <br>&gt;лучше бы нормальный fastcgi сделали - это решило бы проблему производительности для <br>&gt;сложных проектов! <br><br>Хинт: сам PHP от этого быстрее не заработает...<br> https://opennet.dev/openforum/vsluhforumID3/63498.html#69 Fri, 05 Feb 2010 21:08:27 GMT &gt;это шедевр. а примеры будут? <br><br>Можно пример. Скажем если есть массив из 100 000 000 записей, лобовой перебор такого числа записей с целью найти нужную на си проиграет быстрому поиску по b-дереву или хэш-таблице даже на тормозном интерпретируемом языке. За счет неоптимальности подхода. Но, заметьте, это изначально жульнические стартовые условия. <br><br>&gt;о, да. в одном случае получаем Parse error: syntax error, в другом <br>&gt;кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта. <br><br>По моим наблюдениям - багов в скриптоподелиях обычно как минимум не меньше. А зачастую больше, т.к. ориентированность на рапидную разработку не оставляет времени для отлова багов а возможность быстро генерить навороченные конструкции приводит к массе багов и неожиданных посторонних эффектов. А потом начинаются - не buffer overflow так лажа в протоколах, SQL иньекции, иньекции кода, XSS, ... <br>