The OpenNET Project / Index page

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



"В рамках проекта Lwan развивается новый высокопроизводительн..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Отдельный RSS теперь доступен для каждого обсуждения в форуме и каждого минипортала.
. "В рамках проекта Lwan развивается новый высокопроизводительн..." +1 +/
Сообщение от Аноним (-), 24-Апр-16, 23:24 
> И че? Вам шашечки (выполнять любые скрипты) или ехать
> (конкретное приложение, т.е. в этом случае http)?

Только скорость и потребление ресурсов будет раз в 50 хуже. До оптимизации системных вызовов как в lwan дело не дойдет. Какой смысл уменьшать количество системных вызовов, если большинство команд идущих в проц - логика интерпретатора, а не программы?

> Анонимам не угодишь.

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

> Нет. Динамичный язык компилять не сложно. Сложно найти динамичный (не игрушечный) язык,
> который бы не компилялся как минимум в байткод.

Байткод может быть и всего лишь более компактной заменой ключевых слов. Это не отменяет нужды его интерпретировать. Проблемы начинаются когда хочется сгенерить машинный код (посмотри в вике что это). Поскольку язык ДИНАМИЧЕСКИЙ, заранее все рассчитать становится очень нетривиально и вместо компилятора начинает требоваться AI, способный осознать что делает эта программа. В частности как она может менять типы во всех возможных случаях, а если там еще и что-то типа eval() есть - надо к программе еще и компилятор весь подшить, бонусом. Как максимум - или jit делают, со своими проблемами, или компилируют статичски типизированный субсет, где все сильно упрощается.

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

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

> Т.е. скомпилировать "классическим" методом невозможно, но зато Just In Time домкраты тормозят,
> память трескают, но исправно компиляют не только подмножество стремительных механизмов
> для подъема тяжестей? o_O.

Jit делают достаточно сложный анализ в рантайме и кодогенерацию. Все это и проца прилично требует и памяти кушает очень даже. В скомпилированных программах все это тоже было, но 1 раз и на этапе компиляции. Которую, возвожно, вообще другой компьтер производил. А в jit сам изволь, еще и с превышением.

> Не, я понимаю, что одно упоминание питона вызывает у вас какие-то очень
> неприятные воспоминания и соответствующую реакцию, но все же – на счет
> питона, это вам все же в соседнюю ветку, в новость про пай-пай.

Это вы тут с какими-то "приложениями" приперлись. При том что на питоне они заведомо не конкурент штуке где дошло дело до оптимизации системных вызовов.

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

Оглавление
В рамках проекта Lwan развивается новый высокопроизводительн..., opennews, 24-Апр-16, 10:50  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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