[C++?] Серьезный вопрос.

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

А при чем тут клиент? Клиент пишут совершенно другие люди и к серверной части он не имеет никакого отношения. Кстати говоря, нетрудно получить скриншот с топом, где гойджим (петунский jabber-клиент) имеет RSS в районе 380 MB. Здорово, правда?

Не удержусь...

> Одна из первых версий программы запускала независимый процесс сохранения для каждого адреса.

Чёрт возьми! Ну так ни один сервер не беспредельничает... Из мне известных. Чё, бл?, Стивенса было лень прочесть? Раза два? Или С настолько сложен и непознаваем?

> К сожалению, это не заработало.

А должно? Трассироваться теперь не модно стало? А профайлинг проводить? Вот тут и ответ на вопросы сразу бы и отпали... Мне, помнится, приводили пример сервера на питоне. Сцуко. Тёк на 1Mb в час. То же трассироваться не судьба...

> В этом весь ваш "промышленный" ерланг.

Нет. Это руки ожидающих очередного "Меча-Кладенца". Когда написал пару строк, сказал "саиппсь" и оно чудесным образом "саипплось".

>> Ты тут про компиляторы такую чушь несёшь, что совершенно понятно, что создания даже простенького в жизни не осилишь.

> Yacc/Bison для создания лексического анализатора не считается? Ну и хрен бы с ним.

Ты очередной новый смысл слова "компилятор" изобрёл? Это генераторы парсеров вообще-то. Компилятор ещё и генерацию кода подразумевает.

> 2. Так. Мессейнджер. Не. Новое gadu-gadu с 6 млн. пользователями где-то в Польше? Бррр... Извини. Стебаюсь. Но ЗАЧЕМ переписывать то, что уже нормально работает?

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

> Ну говно вопрос -- для начала пущщай ужо в gcc его включат. GCC -- компилятор "соборный", там даже Chill был включён... И не такое выносил... ну в чём проблема-то?

Теперь у нас компилятор - это то, что входит в состав gcc?

> Эээ... А что, ряд решений, на которых основан тот же Беовульф (OpenMP, PVFS2 просто как примеры) не обеспечат Беовульфу хорошую масштабируемость?

Изоляция процессов, зелёные треды.

> Ты действительно думаешь, что это типа аськи? :-D

Он и диод =)

> Нет. Не "типа аськи" это. Это довольно интересно. Соглашусь. И с радостью заинтересовался бы, если бы не использовал (и для администрирования в том числе) XMPP в данный момент. В варианте Jabber2. Уж больно удобно...

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

>Про любые задачи речь не идёт. Ниша эрланга типично серверная -- обработка множества параллельных запросов. И там обеспечить хорошую масштабируемость не так уж сложно.

...раздается возглас с последней парты. Обеспечить масштабируемость не так тривиально, как кажется на первый взгляд. Кстати, такой вопрос: если эрланг так хорош, где же HTTP серверы на нем? Почему кругом apache + nginx/lighttpd?

> Ты очередной новый смысл слова "компилятор" изобрёл?

Дык! Извини! Это не я...
http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82...

"Лексический анализ" это частный случай "компиляции". Вдобавок есть ещё одна тонкость. "Генерация кода" о которой ты говоришь, вообще-то понятие слишком растяжимое -- например лексический анализ какого-нибудь треша с переводом в более удобный для обработки вид это то же... "компиляция".

Я бы сказал об "объектном коде" и об этапе "трансляции" (переводе из ЯВУ в объектный или машинный код). Впрочем да... Я докапываюсь. Извини.

Рекомендую прочесть книгу "GCC: The Complete reference" by Arthur Griffit. Там много интересного. Мне понравилось... Извини малограмотного...

Хорошо.

>Показывай в предоставленном выводе ldd "библиотеки поддержки", про которые ты так красиво бредил.

Какой смищной агрессивный красноглазик :) А что, статически понапиханная гадость уже не в счет? Я ведь сейчас скачаю быдлохацкиль, скопипащу "hello world" и посмотрю на размер бинарника.

Правда? Отлично.
Ты то же считаешь что XMPP это просто протокол messanger'а?

> Я ведь сейчас скачаю быдлохацкиль, скопипащу "hello world" и посмотрю на размер бинарника.

Лучше не делай этого...

>Есть read/write локи в java.util.concurrent.

...которыми надо управлять вручную.

> гойджим (петунский jabber-клиент) имеет RSS в районе 380 MB

Чего ты всё время на питон съезжаешь? В этом треде кроме тебя никто про него не упоминает.

И чё, хочешь сказать, что программы на С++ памятью не текут в принципе что ли?

Нет. Вовсе нет. Просто надоело с очередным трешем разбираться. Пусть уже в куче будет.

> "Лексический анализ" это частный случай "компиляции".

С логикой или определениями туго? Лексический анализ является частью процесса сборки, а не его частным случаем.

> Вдобавок есть ещё одна тонкость. "Генерация кода" о которой ты говоришь, вообще-то понятие слишком растяжимое -- например лексический анализ какого-нибудь треша с переводом в более удобный для обработки вид это то же... "компиляция".

Генерация кода - это перевод представления программы из одного формата в другой. Например, генерация пи-кода (перевод текста во внутреннее представление) или генерация маш.кода (перевода внутреннего представления программы в целевой машинный код).

>Подумай на досуге, почему на ерланге можно наплодить около ляма ерланговых процессов.

Если ты откроешь для себя ulimit -s и срежешь стек нити до 2Mb (или меньше), то даже на 32 битах ты поимеешь где-то с 1.5-2.5k нативных потоков. И системный шедулер, как ни странно, не дохнет.

> Правда? Отлично. Ты то же считаешь что XMPP это просто протокол messanger'а?

XMPP не так давно появился, и все прекрасно помнят, откуда растут уши. Факт есть факт: xmpp проектировался, как instant messaging protocol.

> Если ты откроешь для себя ulimit -s и срежешь стек нити до 2Mb (или меньше), то даже на 32 битах ты поимеешь где-то с 1.5-2.5k нативных потоков. И системный шедулер, как ни странно, не дохнет.

Умник... Во-первых, миллионами тасков всё равно не пахнет. Во-вторых, шедуллер будет всё так же за O(1) работать, но 1 уж очень большим будет. В третьих, каждое переключение контекста жрёт время, плюс кеш холодным делает.

>>Подумай на досуге, почему на ерланге можно наплодить около ляма ерланговых процессов.

>Если ты откроешь для себя ulimit -s и срежешь стек нити до 2Mb (или меньше), то даже на 32 битах ты поимеешь где-то с 1.5-2.5k нативных потоков. И системный шедулер, как ни странно, не дохнет.

То есть разницу между 1.5-2.5k и 1M в 3 (три!!!) порядка ты не видешь?

>Изоляция процессов, зелёные треды.

Да хоть нежно-бирюзовые треды -- цена переключения контекста задачи далеко не нулевая. Зеленые треды -- это попытка составить костыль, который бы позволил поменьше думать: зачем нам возиться с мультиплексированием IO, разбивать обработку запроса на стадии, распараллеливать эти стадии на N потоков, если можно тупо следовать модели 1:1? Подумаешь, что это заткнется уже при 1000-2000 клиентов на 1 машину. Машинок же всегда докупить можно.

>Во-вторых, шедуллер будет всё так же за O(1) работать, но 1 уж очень большим будет.

Кстати, емнип, в новом шедулере сложность O(log n)

> Лексический анализ является частью процесса сборки, а не его частным случаем.

Да? Из этого следует что лексический анализ применим только в процессе сборки? Правда? Чё, фимоз головного мозга одолел? =)))

> Генерация кода - это перевод представления программы из одного формата в другой. Например, генерация пи-кода (перевод текста во внутреннее представление) или генерация маш.кода (перевода внутреннего представления программы в целевой машинный код).

МАЛАДЭССС! Скажи это... А.. Не важно кому... Кто-то там требовал опрелений... Ну, вот ему и скажи... =)))

Да. Так чё там с протоколом XMPP-то? Оно только для мессейнджера? Ты и впрямь настолько туп и идиотичен, что когда тебя носом в говно ткнуть даже не понимаешь где оно?

> А что, статически понапиханная гадость уже не в счет?

Первое сообщение, с которого данный конкретный косечек спора с бредогенератором пошёл, читать не пробовал? А зря, помогает...

> Дык! Извини! Это не я... http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%82.. .

Так ты -- автор yacc и bison? Ну тогда действительно снимаю шляпу перед автором компиляторов.

> Я бы сказал об "объектном коде" и об этапе "трансляции" (переводе из ЯВУ в объектный или машинный код). Впрочем да... Я докапываюсь. Извини.

> Рекомендую прочесть книгу "GCC: The Complete reference" by Arthur Griffit. Там много интересного. Мне понравилось... Извини малограмотного...

Картинки там что ли понравились?

Ну тогда объясни, почему GHC -- не компилятор, и я принесу публичные извинения.

А пока что ты демонстрируешь поговорку "смотрю в книгу -- вижу фигу".

>Я ведь сейчас скачаю быдлохацкиль, скопипащу "hello world" и посмотрю на размер бинарника.

>main = putStrLn "Hello world"

Результирующий бинарник весит 478kb (пострипанный -- 375kb). Приложение на Delphi, рисующее формочку с красивыми кнопками и производящее полезную работу (к примеру, текстовый редактор), весит меньше. Хацкиль однозначно идет лесом.

>То есть разницу между 1.5-2.5k и 1M в 3 (три!!!) порядка ты не видешь?

Честно говоря, я даже этих самых мифических миллионов потоков не вижу.

> Да хоть нежно-бирюзовые треды -- цена переключения контекста задачи далеко не нулевая.

Ненулевого по стоимости аппаратного переключения контекста в зелёных тредах нет. Переключение логического контекста - это сохранение регистров старого контекста и загрузка нового.

> Зеленые треды -- это попытка составить костыль, который бы позволил поменьше думать: зачем нам возиться с мультиплексированием IO, разбивать обработку запроса на стадии, распараллеливать эти стадии на N потоков, если можно тупо следовать модели 1:1?

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

> Подумаешь, что это заткнется уже при 1000-2000 клиентов на 1 машину. Машинок же всегда докупить можно.

"Машинок же всегда докупить можно" - это просто мечта владельца начинающего бизнеса. Начать с малого, и по мере раскрутки оборотов докупать новое железо, получая прирост производительности, близкий к линейному.

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

> Факт есть факт: xmpp проектировался, как instant messaging protocol.

Что из этого? Он не пригоден и не используется для message quening? Единственный минус XMPP -- по умолчанию всё плохо с one-to-many. А что, законодательно запретили PubSub protocol? Он, вообще-то, к 1999г. относится. Тебе сюда ->
http://xmpp.org/extensions/xep-0060.html

> Кстати, емнип, в новом шедулере сложность O(log n)

Энтерпрайз 5-й версии всё ещё на O(1) работает =)

Ну я же тебя предупреждаааааал... =)))) От сырости это. От сырости. И ветром надуло. Впридачу.

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

Shared libraries посчитать не забыл?

> Да? Из этого следует что лексический анализ применим только в процессе сборки? Правда?

Ты сказал, что лексический анализ - это частный случай компиляции. Это не так, это неправильно.

> Чё, фимоз головного мозга одолел? =)))

Да, меня сегодня что-то одолевает фимоз твоего головного мозга...

> Ну тогда объясни, почему GHC -- не компилятор, и я принесу публичные извинения.

Друг. Давай лучше я принесу публичные извинения. И епппитесь вы сами с этим монстром. Я, вон, linuxfan'а предупреждал... Не поверил... Удивлялся сильно.

Или это у компиляторов мода теперь такая -- по 500К на хеловорлде генерировать?

> Что из этого? Он не пригоден и не используется для message quening?

Молодец! Можешь теперь иди в JP Morgan Chase и сказать в лицо, что они со своим AMQP могут идти лесом.

>> Лексический анализ является частью процесса сборки, а не его частным случаем

>Да? Из этого следует что лексический анализ применим только в процессе сборки? Правда? Чё, фимоз головного мозга одолел? =)))

the_Shadow, эм... ты хоть вдумываешь в то, ЧТО ты пишешь и ЧТО ты читаешь? Больше похоже, что нет.

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

Можешь мне не рассказывать о гринтредах. И я тебе даже не буду говорить, что в glibc есть средства для удобного написания такого дела. Лучше ты мне расскажи о том, как такое переключение контекстов не сбивает пресловутый кеш. Или даже у тебя рука не поднимется такую ложь написать?

>"Машинок же всегда докупить можно" - это просто мечта владельца начинающего бизнеса.

Угу. Только "начинающие бизнесмены" почему-то не осознают, во сколько им обойдется парк машинок. Знакомый админ говорил, что место в датацентре может стоить по $2k зелени в месяц и выше. И таких мест надо все больше. И вдруг оказывается, что при парке в 50 машин железо очень часто сбоит. И такой п*ц наступает, что человек хватается за голову, но уже поздно. Домасштабировались.

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

А я писал самописный HTTP сервер, который отдавал определенную динамику со скоростью 2-3k запросов в секунду. На плюсах. Без асио.

>Shared libraries посчитать не забыл?

Если сказать "линкуйся с VLC динамически", размер бинарника падает где-то до 30-50kb. А ты что, дельфей никогда не видел чтоли? Это же классика.

>линкуйся с VLC динамически

s/VLC/VCL/

> Молодец! Можешь теперь иди в JP Morgan Chase и сказать в лицо, что они со своим AMQP могут идти лесом.

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

В остальном, то что устраивает меня я лично не навязываю. Ни кому. И, более того. Соглашусь с тем, что RabbitMQ в ряде случаев было бы проще и лучше (наверное) использовать. Ну а мне и так нормально.

> Можешь мне не рассказывать о гринтредах. И я тебе даже не буду говорить, что в glibc есть средства для удобного написания такого дела. Лучше ты мне расскажи о том, как такое переключение контекстов не сбивает пресловутый кеш. Или даже у тебя рука не поднимется такую ложь написать?

Я специально отделил слова "аппаратный" и "логический". Переключение логического контекста - это просто смена значений регистров во всё том же аппаратном контексте. Такой тип переключения очень дёшев как по процессору, так и по памяти.

> Угу. Только "начинающие бизнесмены" почему-то не осознают, во сколько им обойдется парк машинок. Знакомый админ говорил, что место в датацентре может стоить по $2k зелени в месяц и выше. И таких мест надо все больше. И вдруг оказывается, что при парке в 50 машин железо очень часто сбоит. И такой п*ц наступает, что человек хватается за голову, но уже поздно. Домасштабировались.

Ранняя оптимизация - корень всех зол. Накопит денег на шкаф с эмблемой IBM - смигрирует систему в шкаф. Старое барахло, уже отбившее свою стоимость, продаст.

> А я писал самописный HTTP сервер, который отдавал определенную динамику со скоростью 2-3k запросов в секунду. На плюсах. Без асио.

Отлично! Теперь представь, что того же самого можешь добиться совсем малой кровью. Плюс довесочком получаешь возможность расползаться на кластер.

> Это не так, это неправильно.

В данном случае я не корректно сформулировал мысль. Согласен.

> Да, меня сегодня что-то одолевает фимоз твоего головного мозга...

Избавь себя от мучений. Где ближайшая стена в курсе? Те туда...

> В остальном, то что устраивает меня я лично не навязываю. Ни кому. И, более того. Соглашусь с тем, что RabbitMQ в ряде случаев было бы проще и лучше (наверное) использовать. Ну а мне и так нормально.

Если бы ты ещё реализацию AMQP не называл аналогом gadu-gadu, было бы совсем замечательно.

>Я специально отделил слова "аппаратный" и "логический". Переключение логического контекста - это просто смена значений регистров во всё том же аппаратном контексте.

Есть только одна небольшая проблема: возможно следующий поток надо продолжить выполнять с другой точки прерывания. То есть переход вместе со сбросом кеша имеет место быть. Я уже не говорю о том, что такой частный случай зелени подходит только для задач, которые большую часть времени ждут ввода-вывода. Мультиплексирование IO на epoll/kqueue даст лучшие результаты, правда вынудит немного напрячь мозги, но это только в первый раз.

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

Естественно, это же и есть применение "зелени"!

> Мультиплексирование IO на epoll/kqueue даст лучшие результаты, правда вынудит немного напрячь мозги, но это только в первый раз.

Оно внутри так и мультиплексируется. Плюс само растаскивается на все ядра. Плюс умеет растаскиваться на другие хосты. Без напряжения мозгов :)

> Если бы ты ещё реализацию AMQP не называл аналогом gadu-gadu, было бы совсем замечательно.

Если бы ты перечитал тот постинг (а лучше sub-thread) с включёнными мозгами то всем было бы проще. Но я этого не требую. Если решишься, то обрати внимание на подпись там в саааамом низу...

>Отлично! Теперь представь, что того же самого можешь добиться совсем малой кровью.

Я сечас скажу страшную вещь: при современных библиотеках а-ля libevent писать такие сервера ненамного сложнее, чем хеллоуворлды лепить.

> Хотя по поводу Лиспа...

Как раз для написания текстового редактора --- лисп является идеальным выбором.