The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Компания Facebook открыла код высокопроизводительного PHP тр..., opennews (?), 02-Фев-10, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


12. "Компания Facebook открыла код высокопроизводительного PHP тр..."  –5 +/
Сообщение от Gambler (ok), 03-Фев-10, 00:22 
>Знаете, самое издевательское во всей скриптовой байде то что ПРОЦ НЕ УМЕЕТ
>ВЫПОЛНЯТЬ СКРИПТЫ :). В проц в любом случае пойдет поток команд.
>Потому что это единственное что он умеет выполнять. И весь вопрос
>лишь в том насколько черезжопным и неоптимальным методом этот поток будет
>получен.

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

Ответить | Правка | Наверх | Cообщить модератору

13. "Компания Facebook открыла код высокопроизводительного PHP тр..."  +/
Сообщение от User294 (ok), 03-Фев-10, 00:35 
>Неа. Вопрос не весь. Еще есть такая штука, как архитектура.

А тут все просто. По умолчанию подразумеваются равные стартовые условия для всех... ;).Т.е. более-менее адекватный архитект не делающий откровенных ляпов.

Ответить | Правка | Наверх | Cообщить модератору

24. "Компания Facebook открыла код высокопроизводительного PHP тр..."  +/
Сообщение от Карбофос (ok), 03-Фев-10, 09:27 
>Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый

это шедевр. а примеры будут?

>Зато ясно, где будет меньше багов

о, да. в одном случае получаем Parse error: syntax error, в другом кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

54. "Компания Facebook открыла код высокопроизводительного PHP тр..."  –2 +/
Сообщение от Gambler (ok), 03-Фев-10, 21:00 
>>Если оптимальный скомпилированный код будет требовать в триста раз больше вызовов функций, чем непотимальный интерпретируемый
>
>это шедевр. а примеры будут?

Java EE. И не надо говорить что она не компилируется - все нормальные VMы давно уже поддерживают JIT компиляцию.

Ответить | Правка | Наверх | Cообщить модератору

56. "Компания Facebook открыла код высокопроизводительного PHP тр..."  +2 +/
Сообщение от Карбофос (ok), 03-Фев-10, 21:58 
тут кто-то говорит, что ява не компилируется? ужас, если вам такое послышалось, или показалось. в таких случаях креститься надо.
так в чем там заключается выражение "в триста раз больше вызовов функций"? вообще-то есть такая вещь, как библиотека. ее можно и статично прикрутить к бинарнику. да и выбрать библиотеку можно по потребностям. жабакодеры, вон, все писькомерством занимаются, сравнивая приложение, запущенное как серверный апплет с бинарником с внешними либами. меряют они скорость вызова функций. только лукавят, паразиты. в серверной апликации все в памяти, все вызываемые внешние функции. а умалчивают они о том, что бинарник можно статично компильнуть.
jit компиляция. ну давайте компильнем проектик какой-нибудь, а? ну я не знаю, фильтрование фотографий по алгоритму Гаусса, чтоли... размер фотографий - произвольный, цветовая гамма - тоже. но можно и ограничиться в 24 бита...
Ответить | Правка | Наверх | Cообщить модератору

69. "Компания Facebook открыла код высокопроизводительного PHP тр..."  +2 +/
Сообщение от User294 (ok), 06-Фев-10, 00:08 
>это шедевр. а примеры будут?

Можно пример. Скажем если есть массив из 100 000 000 записей, лобовой перебор такого числа записей с целью найти нужную на си проиграет быстрому поиску по b-дереву или хэш-таблице даже на тормозном интерпретируемом языке. За счет неоптимальности подхода. Но, заметьте, это изначально жульнические стартовые условия.

>о, да. в одном случае получаем Parse error: syntax error, в другом
>кривые очумулые ручки приводят к segmentation fault, либо к умиранию объекта.

По моим наблюдениям - багов в скриптоподелиях обычно как минимум не меньше. А зачастую больше, т.к. ориентированность на рапидную разработку не оставляет времени для отлова багов а возможность быстро генерить навороченные конструкции приводит к массе багов и неожиданных посторонних эффектов. А потом начинаются - не buffer overflow так лажа в протоколах, SQL иньекции, иньекции кода, XSS, ...

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

71. "Компания Facebook открыла код высокопроизводительного PHP тр..."  +/
Сообщение от Карбофос (ok), 06-Фев-10, 15:31 
>Но, заметьте, это изначально жульнические стартовые условия.

конечно, как и все тесты производительности java vs c/c++ где первая по результатам - быстрее. ;) сравнения плюсов с дотнет - из той же оперы.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру