|
| 1.4, аноним (?), 23:18, 02/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Я всегда говорил что любая интерпретируемая дрянь все равно надо или поздно вернется к нативному коду.
| | |
| |
| 2.5, IGX (?), 23:38, 02/02/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
Да. Чем больше популярность языка, тем выше к нему требования, включая производительность.
| | |
| 2.7, User294 (ok), 23:52, 02/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
Знаете, самое издевательское во всей скриптовой байде то что ПРОЦ НЕ УМЕЕТ ВЫПОЛНЯТЬ СКРИПТЫ :). В проц в любом случае пойдет поток команд. Потому что это единственное что он умеет выполнять. И весь вопрос лишь в том насколько черезжопным и неоптимальным методом этот поток будет получен. Есть более прямые и быстрые методы, есть менее прямые. А результат - одинаковый с точки зрения проца. Поток команд на выполнение. А вот его скорость работы может заметно варьироваться. Даже выполнение самого дебильного и тормозного интерпретатора вызовет в конечном итоге поток команд в процессор. Только сгенеренный очень уж неоптимально и сильно разбавленный бесполезными для решения задачи командами самого интерпретера (потому то интерпретеры без jit-компилера и всасывают по полной).
| | |
| |
| 3.12, Gambler (ok), 00:22, 03/02/2010 [^] [^^] [^^^] [ответить]
| –5 +/– |
>Знаете, самое издевательское во всей скриптовой байде то что ПРОЦ НЕ УМЕЕТ
>ВЫПОЛНЯТЬ СКРИПТЫ :). В проц в любом случае пойдет поток команд.
>Потому что это единственное что он умеет выполнять. И весь вопрос
>лишь в том насколько черезжопным и неоптимальным методом этот поток будет
>получен.
Неа. Вопрос не весь. Еще есть такая штука, как архитектура. Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый, то еще неизвестно кто кого обгонит. Зато ясно, где будет меньше багов.
| | |
| |
| 4.13, User294 (ok), 00:35, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Неа. Вопрос не весь. Еще есть такая штука, как архитектура.
А тут все просто. По умолчанию подразумеваются равные стартовые условия для всех... ;).Т.е. более-менее адекватный архитект не делающий откровенных ляпов.
| | |
| 4.24, Карбофос (ok), 09:27, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый
это шедевр. а примеры будут?
>Зато ясно, где будет меньше багов
о, да. в одном случае получаем Parse error: syntax error, в другом кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта.
| | |
| |
| 5.54, Gambler (ok), 21:00, 03/02/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
>>Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый
>
>это шедевр. а примеры будут?
Java EE. И не надо говорить что она не компилируется - все нормальные VMы давно уже поддерживают JIT компиляцию.
| | |
| |
| 6.56, Карбофос (ok), 21:58, 03/02/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
тут кто-то говорит, что ява не компилируется? ужас, если вам такое послышалось, или показалось. в таких случаях креститься надо.
так в чем там заключается выражение "в триста раз больше вызовов функций"? вообще-то есть такая вещь, как библиотека. ее можно и статично прикрутить к бинарнику. да и выбрать библиотеку можно по потребностям. жабакодеры, вон, все писькомерством занимаются, сравнивая приложение, запущенное как серверный апплет с бинарником с внешними либами. меряют они скорость вызова функций. только лукавят, паразиты. в серверной апликации все в памяти, все вызываемые внешние функции. а умалчивают они о том, что бинарник можно статично компильнуть.
jit компиляция. ну давайте компильнем проектик какой-нибудь, а? ну я не знаю, фильтрование фотографий по алгоритму Гаусса, чтоли... размер фотографий - произвольный, цветовая гамма - тоже. но можно и ограничиться в 24 бита...
| | |
|
| 5.69, User294 (ok), 00:08, 06/02/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
>это шедевр. а примеры будут?
Можно пример. Скажем если есть массив из 100 000 000 записей, лобовой перебор такого числа записей с целью найти нужную на си проиграет быстрому поиску по b-дереву или хэш-таблице даже на тормозном интерпретируемом языке. За счет неоптимальности подхода. Но, заметьте, это изначально жульнические стартовые условия.
>о, да. в одном случае получаем Parse error: syntax error, в другом
>кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта.
По моим наблюдениям - багов в скриптоподелиях обычно как минимум не меньше. А зачастую больше, т.к. ориентированность на рапидную разработку не оставляет времени для отлова багов а возможность быстро генерить навороченные конструкции приводит к массе багов и неожиданных посторонних эффектов. А потом начинаются - не buffer overflow так лажа в протоколах, SQL иньекции, иньекции кода, XSS, ...
| | |
| |
| 6.71, Карбофос (ok), 15:31, 06/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Но, заметьте, это изначально жульнические стартовые условия.
конечно, как и все тесты производительности java vs c/c++ где первая по результатам - быстрее. ;) сравнения плюсов с дотнет - из той же оперы.
| | |
|
|
|
|
| 2.29, Чорная дипрессия 666 (?), 10:12, 03/02/2010 [^] [^^] [^^^] [ответить]
| –2 +/– |
 Ерунда. Основные тормоза у дисковой подсистемы и базы данных.
И у фейсбука, как я понял, только часть кода скомпилирована с помощью этой новой хрени.
| | |
|
| 1.6, Altie (?), 23:43, 02/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Может есть резон сразу писать на Си или чем ином, для экономии не только ресурсов но и времени? А что будет - PHP или ASP - уже не так важно.
| | |
| |
| 2.8, Gambler (ok), 00:06, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Если бы был нормальный компилируемый язык с GC, OO и нормальной работой со троками, то очень может быть, что на нем бы многие и писали.
| | |
| |
| 3.14, ffsdmad (ok), 00:39, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
буквально ради этого начал разбирать с D
там кстати открыли исходники родного компилятора, а gdc пока сливает
| | |
| |
| 4.55, Gambler (ok), 21:11, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>буквально ради этого начал разбирать с D
>там кстати открыли исходники родного компилятора, а gdc пока сливает
Я пока жду книги по D2. Выйдет - куплю, тоже начну разбираться.
| | |
|
|
| 2.45, тоже Аноним (?), 14:01, 03/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Может есть резон сразу писать на Си
Можно сразу писать на Си.
Но потом вы выделите часто использующиеся функции в отдельный модуль и с чистой совестью назовете его PHP2 ;)
Просто не воспринимайте PHP как язык программирования - это приведет к тому, что его действительно придется компилировать.
PHP - удобный интерфейс скриптов, обращающихся к часто использующимся функциям, которые кто-то до вас уже написал и оптимизировал. На Сях, конечно. При таком отношении к PHP переписывание чего-либо с начала теряет смысл. А вот если вы на нем начнете сочинять сложные конструкции... в общем, эта дорожка уже протоптана Фейсбуком ;)
| | |
| |
| 3.64, igor (??), 18:01, 04/02/2010 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Интересная ситуация получается. Автор пхп его разработал как раз для того чтобы не писать часто используемые функции на си. Сейчас фейсбук сделал обратную работу, вернул скрипты написанные в пхп обратно в си. Получается теперь мы пишем си программу с помощью каких-то макросов (пхп) которые уже транслируются в си. Очень смахивает на удаление гланд через опу.
Тут как раз еще одна утилитка была бы кстати. Весь тот сишный мусор который будет выдавать хип-хоп обрабатывать ей и на выходе получать код на ассемблере! Эдак еще можно производительность повысить на несколько процентов.
| | |
|
|
| 1.10, Аноним (-), 00:16, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Очередной костыль.
лучше бы нормальный fastcgi сделали - это решило бы проблему производительности для сложных проектов!
| | |
| |
| 2.25, pro100master (ok), 09:44, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
чем именно решило бы? Убрать затраты на вызов - да, добавить оптимизатор gcc - нет. Для среднесложных и сложных проектов затраты на вызов и БД - 10-20% времени. Товарищи пытаются оптимизировать остальные 80-90%, что, безусловно, благо.
| | |
| 2.48, Аноним (-), 14:16, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>лучше бы нормальный fastcgi сделали
Чем FPM не устроил?
> это решило бы проблему производительности для сложных проектов!
Бред. Оверхед динамической типизации и интерпритации гораздо больше, чем оверхед серверного интерфейса.
| | |
| |
| 3.62, Аноним (-), 13:48, 04/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
обработка запросов в php-fastcgi,mod-php,FPM принципиально ничем не отличаются.
FPM это это улучшение, а не принципиальное изменение.
Оверхед серверного интерфейса крайне незначителен.
Проблема в принципе работы PHP.
Посмотрите как fastcgi реализовано у всех остальных и сравните с PHP.
Разница принципиальная!
| | |
|
| 2.70, User294 (ok), 00:10, 06/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Очередной костыль.
>лучше бы нормальный fastcgi сделали - это решило бы проблему производительности для
>сложных проектов!
Хинт: сам PHP от этого быстрее не заработает...
| | |
|
| 1.11, Аноним (-), 00:21, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>Обратной стороной высокой производительности является принципиальное >отсутствие поддержки некоторых PHP конструкций, таких как eval().
Интерстно а в нем можно частично перегнать пхп проект в С++ чтобы например теже eval оставить в PHP, и интестно как после пребразования будет осуществляться взаимодествие с PECL
| | |
| |
| 2.17, Mna (??), 01:21, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>пц )))
>говорял я им использовать java )))
Да-да-да! я обеими руками за создание High-Performance Java-to-C++ compiler, и open-source-ного! вот это было бы дело.
А щас... ну, впрочем, может с этого HighPerformance-ПеХоПе удастся создать Python-to-C++ compiler, настоящий, а не костыляку в виде Shed Skin
| | |
| |
| 3.19, Volodymyr Lisivka (?), 01:59, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Да-да-да! я обеими руками за создание High-Performance Java-to-C++ compiler, и open-source-ного! вот это было бы дело.
А что с gcc (gcj - GNU Compiler for Java) или VMKit? Чем не подходят?
| | |
| |
| 4.65, Mna (??), 19:01, 04/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
gcj - на моих мелких тестах был втрое медленнее, чем оригинальная Sun-овская Java, даже c ключом -client, не то что "java -server". Я так и не понял почему, заметил лишь, что time показывал втрое большее число pagefault-ов - это-то один огромный экзешник, у которого все по-идее внутри!
Если бы GCJ хотя бы на 50% уступал java -server-у можно было бы заморачиваться, а так...
Кстати, у gcj вышла проблема с подгрузкой второго JAR-а, коим оказался junit, уж его-то можно было бы скомпилить без проблем.
про VMKit не знал, - спасибо, гляну. при поиске по проектам LLVM не заметил - искал пакет полного цикла с компилятором - как Excelsior, скажем.
| | |
| |
| 5.72, Карбофос (ok), 15:36, 07/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
pagefault обычно возникают при пересечении границ памяти. чем корявее работа с данными (или сам код), тем больше количество pagefault. а у этого огромного екзешника и данные тоже внутри? то есть вы полагаете, что область данных и стека тоже входит в ваш екзешник? o_O
| | |
| |
| 6.73, Mna (??), 03:40, 08/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Тестовая программка оформлена как берущая вход со stdin, и выдающая в stdout.
Кроме этого никаких особенных данных не обрабатывалось, всё остальное - константы внутри class-файла, или соответственно, экзешника, в сегменте данных, если так удобнее Вам представить. Экзешник, кстати, должен был бы весь загрузиться в память функцией mmap (или CreateFileMapping/MapViewOfFile в случае Windows)- свободной памяти на машине для этого было предостаточно.
Вопрос о вхождении стека в экзешник, по-моему, отношения к делу не имеет.
То есть, да, в основном внутри.
| | |
| |
| 7.74, Карбофос (ok), 08:49, 08/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
чисто технически, если это большой екзешник, то и делает он много. если работа с stdin и прочим проходит без буфера обмена и других вещей, то работу с памятью предугадать сложнее. это будет зависеть напрямую от организации внутренних областей памяти по умолчанию.
в яве еще нужно приплюсовать время на создание объектов, даже для работы со строками (стандартной) нужно создание объектов. даже, если происходит работа с текстовыми константами. вполне вероятно, что у сановской явы включены по умолчанию ключи оптимизации. в конечном итоге испробуйте оптимизацию -O2 или -O3.
ну и здесь можно посмотреть как раз по инициализации статичных классов (опции):
http://gcc.gnu.org/onlinedocs/gcj/Code-Generation.html
где-то должна быть разница. кстати, ява все-таки очень интенсивно работает со стеком, но, скорее всего, дело не в этом.
| | |
|
|
|
|
| |
| 4.66, Mna (??), 19:08, 04/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>уже есть ) >http://www.excelsior-usa.com/jet.html
>только он не нужен )
1. Есть: коммерческий и с закрытыми исходниками
Были б были открытые я бы кое-что подправил, есть одна хорошая идея.
2. Почему не нужен, кому не нужен, по какой причине?
Java - самый распространённый ЯП по индексу TIOBE, 20% программистов
Вдвое обгоняя C. (10%). Но это в теории.
А на практике на нем есть написанных куча серьезных опенсорсных программ.
Вот тем, кто их использует и не хочет изобретать велосипедов - нужен.
| | |
|
| 3.30, Чорная дипрессия 666 (?), 10:15, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> А щас... ну, впрочем, может с этого HighPerformance-ПеХоПе удастся создать Python-to-C++ compiler, настоящий, а не костыляку в виде Shed Skin
Есть Pyrex и Cython, правда не в C++, а в обычный си.
Опять же, никому не нужно перекомпилировать весь проект из питона в си. Достаточно только самые много раз выполняемые участки кода типа циклов.
| | |
| |
| 4.67, Mna (??), 20:31, 04/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>может с этого удастся создать Python-to-C++ compiler, настоящий, а не костыляку в виде Shed Skin
>
>Есть Pyrex и Cython, правда не в C++, а в обычный си.
Насколько я помню, в них обоих, в скомпилированной программе, все равно есть питонтво, проявляется в том, что специально не указанные объекты там - все равно питоньи. И куча программного кода конвертирования объектов Python->C и C->Python. Вносящего ненужные задержки.
Идея Shed Skin-а как раз-таки чертовски хорошая (а реализация подкачала, сильно):
Получить автоматически zero-overhead код, все выводы типов сделает транслятор. Это же можно сделать автоматически, в конце концов!!
то есть, базовая идея, что в HiPHoP, что в Shed Skin та же самая (может еще где, не знаю)
: а) Писать код на высокопродуктивном для прототипирования языке, динамическом, скриптовом, etc.
б) В продакшн компилировать исходники, отдельным инструментом, в нативный высокооптимизированный код. желательно без eval-ов.
В итоге - создаем программу быстро. тестируем, и т.п. А в продакшн запускаем - тоже оптимальный код. но создается он не ручным конвертированием, а автоматически.
Тестироваине никто не отменял, но это уже детали.
>Опять же, никому не нужно перекомпилировать весь проект из питона в си.
>Достаточно только самые много раз выполняемые участки кода типа циклов.
В теории да. Но не во всех случаях: в моем случае, для того Питон-проекта, он останется в меньшинстве, потому и желательно чтоб и вовсе не было.
| | |
|
|
|
| 1.18, аноним (?), 01:38, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>HipHop трансформирует код PHP скриптов в высоко оптимизированное представление на языке C++
>принципиальное отсутствие поддержки некоторых PHP конструкций, таких как eval()
другими словами, патчей для оригинальной реализации не дождёмся. ценность для индустрии ноль целых ноль десятых
| | |
| |
| 2.26, pro100master (ok), 09:46, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>другими словами, патчей для оригинальной реализации не дождёмся. ценность для индустрии ноль
>целых ноль десятых
вообще-то они сотрудничают с зенд-коре тим. Так что полюбому не пустая трата времени.
| | |
| 2.31, Чорная дипрессия 666 (?), 10:16, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Патчей для оригинальной реализации? Так это метакомпилятор, это другое совсем. Это не JIT какой-нибудь чтобы его вделать в обычный пахапе и всё работало, но ускоренно.
| | |
| |
| 3.51, аноним (?), 18:54, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>Патчей для оригинальной реализации? Так это метакомпилятор, это другое совсем. Это не
>JIT какой-нибудь чтобы его вделать в обычный пахапе и всё работало, но ускоренно.
напомню фразу из статьи
>переработанный PHP runtime и набор переписанных с целью повышения производительность стандартных библиотек и расширений | | |
|
|
| 1.27, Below (ok), 10:05, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
>По заявлению разработчиков использование HipHop позволяет уменьшить нагрузку на CPU примерно на 50%.
Только вот ведь недавно говорили что на 80%)
| | |
| |
| 2.34, Aleksey (??), 12:10, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
50 тоже очень не мало. Тут я думаю все зависит от специфики оптимизированного кода.
| | |
| |
| 3.57, Below (ok), 22:31, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
Дело не в том много или мало, а в том насколько достоверны данные, которые так быстро меняются
| | |
|
|
| |
| |
| 3.37, Cobold (??), 13:20, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ага, я с Roadsend как-то полгода назад баловался, тестировал - в большинстве случаев производительность наравне или хуже чем у оригинального php 5.2, синтаксис не на 100% поддерживает. Долго думал зачем он вообще существует.
| | |
| |
| 4.41, be_nt_all (ok), 13:32, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>в большинстве
>случаев производительность наравне или хуже чем у оригинального php 5.2, синтаксис
>не на 100% поддерживает. Долго думал зачем он вообще существует.
А ты как код гонял? Если plain CGI против modphp - то результат ожидаемый. А если при прочих равных, тогда гм...
| | |
| |
| 5.46, Cobold (??), 14:12, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
cli , несколько бенчмарков на типовые операции, циклом на 10000 проходов. Я не хотел тестировать время загрузки скрипта, парсинг итд., мне нужна была только производительность.
До каких-то CGI или modphp тестов дело просто не дошло потому что это поделие банально не смогло нормально распарсить нашу фирменную cms (papaya cms), изза каких-то недопониманий синтаксиса. Можно было бы конечно повозиться недельку и адаптировать, но смысл?
| | |
| 5.47, Cobold (??), 14:15, 03/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>в большинстве
>>случаев производительность наравне или хуже чем у оригинального php 5.2, синтаксис
>>не на 100% поддерживает. Долго думал зачем он вообще существует.
>
>А ты как код гонял? Если plain CGI против modphp - то
>результат ожидаемый. А если при прочих равных, тогда гм...
если в сети покопаться можно аналогичные результаты найти, мне просто тогда убедиться хотелось
| | |
|
|
|
| 2.40, be_nt_all (ok), 13:29, 03/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– | |
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 версия вроде урезана.
| | |
| |
| 3.43, be_nt_all (ok), 13:46, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
upd. Точнее сам phс haskell код не использует, но использует некую bison подобную утилитку maketea, на нём написанную.
| | |
|
|
| 1.38, Аноним (-), 13:21, 03/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
вот интересно, зачем было придумывать себе трудности, а потом геройски их решать? может надо было выбрать что-нибудь другое, а не PHP?
| | |
| |
| 2.44, AlexGor (??), 13:54, 03/02/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> может надо было выбрать что-нибудь другое, а не PHP?
да вы что, это же нужно думать перед тем, как начинать делать. человекам в целом это не свойственно.
единственные, наверное, ваятели крупных соцсетей, которые подумали до того, как начать писать -- linkedin.
| | |
| 2.49, szh (ok), 16:06, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> может надо было выбрать что-нибудь другое, а не PHP?
им надо было выйти на рынок как можно быстрее а лучше еще быстрее чем можно, а не сделать красивый проект к 2015 году just for fun.
| | |
| |
| 3.50, AlexGor (??), 17:30, 03/02/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
facebook начинался как студенческое поделие, отсюда и похапе. рынки тут не при чём совершенно.
| | |
| |
| 4.52, аноним (?), 18:58, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>facebook начинался как студенческое поделие
даконечно. начинали как студенческий сайтег и через несколько лет отгрохали датацентр.
сами в это верите?
>отсюда и похапе
нет блин, надо было писать на перле и всю жизнь ловить глупые баги
| | |
| |
| 5.60, AlexGor (??), 09:41, 04/02/2010 [^] [^^] [^^^] [ответить]
| +/– |
>даконечно. начинали как студенческий сайтег и через несколько лет отгрохали датацентр.
>сами в это верите?
разумеется. рост социальной сети - вещь совершенно не прогнозируемая.
>нет блин, надо было писать на перле и всю жизнь ловить глупые
>баги
не блин, надо было писать на java и c(++).
| | |
|
|
|
| 2.53, Warhead Wardick (?), 19:33, 03/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
Оно бы да - надо. Да только что же поделаешь если кто то _уже_ написал код который делает то что нужно. Переписывать? Опять же - хорошо бы, да только вот кто оплатит банкет?
Впрочем поживём увидим, если SugarCRM и Wordpress скомпилируют и оно заработает - тады ДА!
О! Кстати тады уродам из Zend - капец! :)
| | |
|
| 1.63, Vaso Petrovich (?), 17:41, 04/02/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Поправьте новость, ничего они не открывали, не колумбы все же... Ведь скачать ничего нельзя, а значить это брехня....
| | |
| |
| 2.76, Mna (??), 03:15, 09/02/2010 [^] [^^] [^^^] [ответить]
| +/– | |
выпустили 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/2babfd7c38 thread] on the developer list.
| | |
|
|
