Цитата

---

А сам язык несравненно более удобен, чем Java/JavaScript.

---

Угу, каэшна, он один есть истина и свет во тьме.

Цитата

---

сотни тысяч или даже миллионы подключений

---

Хуясе, а чё не миллиарды?

Цитата

---

Вопрос в том, сможет ли такой сервер работать под большими нагрузками

---

В одиночку нет, если сверху поставить кеширующий сервер (++архивирующий, а ещё статику вынести на отдельный сервер), то сможет.

Цитата

---

А сам язык несравненно более удобен, чем Java/JavaScript.

---

Писать Java/JavaScript не совсем корректно, ибо JavaScript - это самостоятельный язык (диалект ECMAScript) и к Java не имеет никакого отношения.
Кстати, хорошие интерпретаторы JavaScript по производительности не уступают лучшим интерпретаторам Лиспа.

Цитата

---

Сборщик мусора справится и способен подгребать под себя много памяти, система расчитана на многоядерные сервера, как ведёт себя при превышении лимита памяти?

---

При нехватке памяти посылается исключение, которое можно перехватить и обработать.

то в жабе о них только говорят

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

rv82

---

А как соотносится производительность Racket с лучшими интерпретаторами Лиспа?

---

Я тестов не производил. Хотя с кем сравнивать? Реализации CL не поддерживают продолжения. А если среди Scheme, то Racket, пожалуй, самая быстрая реализация. Как вам уже известно, слабое место любой платформы с поддержкой продолжений - циклы.

megamanx

---

безопасность (о которой вообще ничего не известно для твоего фреймворка на рэкете), стабильность работы (о которой тоже ничего не известно, ведь, как говорил misha, стабильность не померить)

---

Безопасность - это слабое место любого фреймворка. А стабильностью и апач не может похвастать (у меня он падал и не раз). У него другое преимущество - комьюнити.

Цитата

---

А можно подробнее? Что не так с циклами?

---

Проблема не в циклах, а в реализации vm. Т.е. требуется довольно сложная vm, но это проблема разработчиков. Кстати, в Racket циклы реализованы довольно хорошо, я бы даже сказал не хуже, чем у LispWorks и Allegro CL.

Цитата

---

А аналог веб-сервера racket на stateless-continuations вообще существует?

---

Что такое stateless-continuations?

Цитата

---

Так какая именно сложность с циклами? Точнее - с хвостовой рекурсией?

---

А зачем использовать хвостовой вызов (для локальной функции), когда можно использовать локальные переходы? Т.е. можно преобразовать локальные функции, которые не используются извне, в циклы.

Цитата

---

stateless-servlets точнее. #lang web-server в racket.

---

Они это называют serialized continuations.

Цитата

---

продолжение можно сохранять у пользователя и передавать - например, в http-запросе

---

Лучше не дарить хакеру такие подарки.

Цитата

---

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

---

Для этого обычно используют сервер БД.

Цитата

---

Но зачем это делать-то? Хвостовой вызов в идеале - тот же самый переход. То есть сделав оптимизацию хвостовых вызовов преобразование в циклы получается искаробки.

---

А как будет устроена эта vm? Большинство стековых машин вынуждены удалять предыдущий кадр стека. И тут главную роль играет механизм передачи аргументов и то, где размещается этот кадр стека. (Может подробнее?) Поэтому не стоит удивляться, что для .net хвостовой вызов в 8 раз медленнее обычного, т.е. единственная от него польза - экономия стековой памяти.

Цитата

---

Но при чем тут продолжения все еще неясно

---

Циклы должны быть реализованы максимально эффективно, но большинство разработчиков полагается на хвостовую рекурсию. А почему? Да, потому что простейшая реализация продолжений - cps. Поэтому в большинстве случаев кое-как реализовав оптимизацию хвостовых вызовов разработчики полагают, что этого вполне достаточно и далее не заморачиваются. Короче, разработчики стоят перед дилеммой - либо быстрые продолжения, либо быстрые циклы.

Цитата

---

А как будет устроена эта vm? Большинство стековых машин вынуждены удалять предыдущий кадр стека.

---

Так оптимизация хвостовой рекурсии в том и состоит, что кадр стека _не удаляется_. И новый, соответственно, тоже не создается.

Цитата

---

Поэтому не стоит удивляться

---

Конечо, не стоит, ведь задачи эффективной реализации хвостовых вызовов для разработчиков .net не стояло.

Цитата

---

Циклы должны быть реализованы максимально эффективно, но большинство разработчиков полагается на хвостовую рекурсию. А почему?

---

Очевидно, потому, что по производительности хвостовая рекурсия ничем не отличается от цикла (если оптимизация реализована правильно).

Цитата

---

Короче, разработчики стоят перед дилеммой - либо быстрые продолжения, либо быстрые циклы.

---

Непонятно. Выше мы выяснили, что циклы не нужны - ведь их можно заменить хвостовой рекурсией, которая не медленнее. но вопрос изначально стоял - какая связь между циклами и продолжениями? С какой стати эффективная реализация хвостовой рекурсии закрывает продолжения?

Цитата

---

Кстати, как быстра процедура десериализации?

---

Там же в #lang web-server продолжение как таковое не сериализуется. В месте захвата продолжения лифтится лямбда, имя лямбды с конкретными аргументами (которые представляют обычные числа, строки - любые типы ЯП) пакуется и куда-то уходит (в БД, пользователю, да хоть в памяти кешируется). При десереализации мы считываем эти данные, захватываем имя лямбды, десериализуем аргументы - продолжение готово. То есть никаких накладных расходов связанных с рантаймом тут нет - скорость десериализации ограничивается ровно тем, с какой скоростью мы можем получить данные и распарсить их.

Цитата

---

Анализ продолжения может дать полезную информацию о работе веб-приложения.

---

Еще раз - в любом веб-приложении вся та же информация все равно проходит в запросах. Продолжение должно содержать ту и только ту информацию, которая нужна для того, чтобы четко определить состояние. То есть ровно ту информацию, которая необходимо будет в строке http-запроса. Это не значит, конечно, что мы не можем напихать лишнего - но это уже другая проблема. Не надо пихать Да и с точки зрения оптимизации стоит ограничиваться необходимым. С точки зрения безопасности - можно и зашифровать как угодно.

Цитата

---

Допустим у всех серверов есть доступ к БД, хранящей информацию о активных сеансах.

---

Рано или поздно этот сервер таки не выдержит нагрузки, а второй уже не добавишь в силу особенностей архитектуры. Здесь, конечно, все зависит от того, где же будет этот момент "не выдерживания нагрузки" - но тут без тестов не скажешь, а их нет.

Цитата

---

Так оптимизация хвостовой рекурсии в том и состоит, что кадр стека _не удаляется_. И новый, соответственно, тоже не создается.

---

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

Цитата

---

Очевидно, потому, что по производительности хвостовая рекурсия ничем не отличается от цикла (если оптимизация реализована правильно).

---

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

Цитата

---

Непонятно. Выше мы выяснили, что циклы не нужны - ведь их можно заменить хвостовой рекурсией, которая не медленнее.

---

Это только твои утверждения, т.е. тебе это еще необходимо доказать.

Цитата

---

но вопрос изначально стоял - какая связь между циклами и продолжениями?

---

Повторяю: "Короче, разработчики стоят перед дилеммой - либо быстрые продолжения, либо быстрые циклы." Если тебе этого недостаточно, значит ты меня неправильно понял. Я не говорил о каком-то абсолюте, просто я еще не встречал реализации, где было бы все идеально реализовано.

Цитата

---

С какой стати эффективная реализация хвостовой рекурсии закрывает продолжения

---

Вот именно с какой? Не помню, чтобы я писал что-то подобное.

Цитата

---

что существует какой-то способ оптимизации хвостовых вызовов, который я не знаю.

---

Стандартный способ хвосторекурсивной оптимизации. В качестве нового фрейма используется текущий фрейм (то есть на работу с фреймами вообще время не тратится), а хвосто-рекурсивный вызов превращается в в безусловный переход.

Цитата

---

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

---

Да не надо ничего преобразовывать, если оптимизация хвостовой рекурсии есть - оно _уже_ преобразовано. Ф-я после оптимизации хвостовой рекурсии выглядит в точности как цикл.

Цитата

---

Это только твои утверждения, т.е. тебе это еще необходимо доказать.

---

Да это уже изучено и доказано стопицот раз. hint: циклов в scheme нету именно из-за того, что после оптимизации хвосторекурсивные вызовы как раз в них и превращаются. То есть никаких потерь скорости.

Цитата

---

Вот именно с какой? Не помню, чтобы я писал что-то подобное.

---

Как не писал? Вот же:
"Короче, разработчики стоят перед дилеммой - либо быстрые продолжения, либо быстрые циклы."

ну я и повторяю вопрос - почему эффективная реализация хвостовой рекурсии исключает эффективную реализацию продолжений?

Цитата

---

Так какова скорость десериализации?

---

Я, по-моему, вполне четко на этот вопрос ответил.

Цитата

---

А то судя по тому что ты написал, она довольно велика.

---

Ну да. Ведь никаких накладных расходов нет (которые бывают в случае обычных продолжений).

Цитата

---

Т.е. даже по скорости они не выигрывают.

---

А они и не должны. Зачем? не будет хватать скорости - ставим еще сервер. В этом суть.

Цитата

---

А чем это лучше классики

---

Ну тем, чем лучше классики любой continuation-based сервер
Прямой, интуитивно-понятный control-flow вместо реализации конечного автомата руками.

Цитата

---

Это и без продолжений возможно.

---

Конечно. Речь шла о том, что продолжения тоже можно сделать безопасными. Как я уже вышел сказал - у продолжений лишь одно преимущество: "прямой, интуитивно-понятный control-flow вместо реализации конечного автомата руками.", остальное - недостатки. И их много.

Цитата

---

А кто сказал, что он один? Идентификатор сеанса может содержать идентификатор сервера на котором хранится состояние сеанса.

---

Так нагрузку балансировать ты не сможешь. В этом случае впонле реальна ситуация, при которой первый сервер падает от нагрузки, а второй загружен едва ли на 10%...

Цитата

---

ну я и повторяю вопрос - почему эффективная реализация хвостовой рекурсии исключает эффективную реализацию продолжений?

---

Не хвостовой рекурсии, а вызовов функций вообще Эффективная реализация хвостовой рекурсии, а это для Лиспа вообще возможно? А у меня, кстати, почему-то показатели для оптимизированных функций (хвостовая рекурсия) Racket-ом сродни их не хвостовым аналогам из .net, т.е. циклы Racket-а довольно "прожорливые".

Цитата

---

Я, по-моему, вполне четко на этот вопрос ответил.

---

Я хотел увидеть цифры. Хотя, сейчас мне это уже не важно.

Цитата

---

Ведь никаких накладных расходов нет (которые бывают в случае обычных продолжений).

---

Просто я считал, что они имеют специальную структуру для облегчения распаковки.

Цитата

---

А они и не должны. Зачем? не будет хватать скорости - ставим еще сервер. В этом суть.

---

Я думал, что это передовая технология

Цитата

---

Прямой, интуитивно-понятный control-flow вместо реализации конечного автомата руками.

---

А причем здесь конечный автомат? Просто разработчики захотели добавить скобок

Цитата

---

Так нагрузку балансировать ты не сможешь. В этом случае впонле реальна ситуация, при которой первый сервер падает от нагрузки, а второй загружен едва ли на 10%...

---

Сервер БД может обработать только определенное количество клиентов (рассчитать это число заранее). Перед выдачей идентификатора необходимо определить менее загруженный сервер. Желательно, чтобы было разделение на сервера работающие с авторизованными клиентами и анонимными. Необходимо ограничить количество идентификаторов выдаваемых для одного IP. Каждому клиенту свой идентификатор (привязан к IP), необработанные запросы ложатся в стек, принадлежащий этому идентификатору. Если стек переполнен, то вероятна DoS-атака, поэтому необходимо принять соответствующие меры. В принципе, все можно рассчитать заранее.
Кстати, не забывай, что я говорил об информации о сеансе (состояние сеанса), которая обычно содержит только важные сведения, такие как IP, id пользователя (если авторизован) и текущие привилегии пользователя, и возможно др. А остальное, например, содержание его корзины с покупками, можно хранить на стороне клиента.

Цитата

---

Т.е. после её вызова будет создан новый фрейм

---

Новый фрейм создается только при первом вызове (на первой итерации цикла). Дальше никаких фреймов не создается.

Цитата

---

Попробуй объяснить результаты.

---

А что странного в этих результатах?

Цитата

---

Функция после оптимизации хвостовой рекурсии выглядит как функция, содержащая цикл.

---

Ну да. Так какие проблемы с этим?

Цитата

---

т.к. частичная не предполагает преобразование кода функции в цикл

---

да нету никакого преобразования функции цикл. просто _так выходит_ (чисто случайно), что после хвосторекурсивной оптимизации результат выглядит как цикл.

Цитата

---

Кстати, подобная оптимизации хвостовой рекурсии для Лиспа требует предпросмотра (анализа) всего кода программы.

---

С чего вдруг?

Цитата

---

Оптимизация хвостовых вызовов обычно подразумевает просто замена call на его эквивалент, назовем его tail-call. Поэтому любой хвостовой вызов можно оптимизировать, а не только рекурсивный.

---

Да. Просто кроме tail-call обычно рассматривается еще и рекурсивный tail-call, в случае которого можно оптимизировать вызов еще лучше.

Цитата

---

Например, добавление сета запрещает оптимизацию

---

Верно, если мы добавим сет, то уже не можем гарантировать, что вызов, собственно, рекурсивный.

Цитата

---

Эффективная реализация хвостовой рекурсии, а это для Лиспа вообще возможно?

---

а какие здесь подводные камни?

Цитата

---

Racket-ом сродни их не хвостовым аналогам из .net, т.е. циклы Racket-а довольно "прожорливые".

---

Весьма поспешно заявлять, что дело тут в прожорливых циклах - .net намного шустрее racket, т.к. и типизация статическая, и ВМ менее фичастая, и jit гораздо бодрее (в racket вообще gnu lightning, который не особенно эффективный по сравнению с, например, тем же llvm код генерирует).

Цитата

---

Просто я считал, что они имеют специальную структуру для облегчения распаковки.

---

Ну конечно она специальная. Вот на счет того как она облегчает распаковка (и как вообще даже теоретически структура может облегчить распаковку) - я не в курсе

Цитата

---

Я думал, что это передовая технология

---

Передовая в том, что масштабируема. В отличии от

Цитата

---

А причем здесь конечный автомат?

---

При том, что любое веб-приложение, в силу особенностей http-протокола, является реализацией конечного автомата

Цитата

---

Перед выдачей идентификатора необходимо определить менее загруженный сервер.

---

Так в дальнейшем нагрузка вполне может измениться, а идентификатор _уже_ выдан. Мы заранее не сможем сказать какова нагрузка будет по данному идентификатору.

Цитата

---

а какие здесь подводные камни?

---

Требуется более продвинутый declaim.

Цитата

---

.net намного шустрее racket, т.к. и типизация статическая

---

Я использовал короткие целые, поэтому не было никакой распаковки (unboxing).

Цитата

---

в racket вообще gnu lightning, который не особенно эффективный по сравнению с, например, тем же llvm код генерирует

---

Т.к. llvm на оптимизацию кода тратит много времени, поэтому обычно отключают большинство оптимизаций кода.

Цитата

---

Вот на счет того как она облегчает распаковка (и как вообще даже теоретически структура может облегчить распаковку) - я не в курсе

---

Сжатые данные всегда структурированы, а иначе как будем производить распаковку?

Цитата

---

Передовая в том, что масштабируема. В отличии от

---

Разве "старые" технологии запрещают хранить данные на стороне клиента? Вот только все это требует шифрования, поэтому возрастает нагрузка на сервер. Т.к. обычно чем лучше алгоритм, тем дольше расшифровка данных.

Цитата

---

При том, что любое веб-приложение, в силу особенностей http-протокола, является реализацией конечного автомата

---

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

Цитата

---

Так в дальнейшем нагрузка вполне может измениться, а идентификатор _уже_ выдан. Мы заранее не сможем сказать какова нагрузка будет по данному идентификатору.

---

Речь идет о состоянии сеанса, поэтому мы всегда можем спрогнозировать максимально возможную нагрузку созданную одним пользователем. И если это значение превышено, то мы возможно имеем дело с DoS-атакой, поэтому необходимо принять соответствующие меры(например, временный бан ip), и тем самым избежать отказа в обслуживании. Если бы этот подход был бы таким уж плохим, то большинство веб-серверов не раздавало бы идентификаторы сеанса.
А как ты предлагаешь бороться с DDoS-атаками?