WolfHound wrote:
> AVC>Вопрос: в большинстве случаев или *всегда*?
> Приведи хоть один реальный протокол в котором есть рекурсия.
Передача древесных данных?

Здравствуйте, WolfHound, Вы писали:

WH>Нет Андрей Владимирович я считаю что для описания протоколов вобще EBNF нафиг не упал. А EBNF в общем случае это ахренительная задачка... Алгоритм Эрли жрет просто невообразимое колличество ресурсов.

Так я, собственно, это и написал. Никаких смысловых отличий.

WH>А что касается преобразованием некоторого декларативного язычка то я использую другую мегатулзу nemerle называется. Получается намного проще чем всякие коки и тем болие XSLT.

Это детали реализации. В аспекте данного разговора они не очень интересны.

Здравствуйте, Дарней, Вы писали:

Д> Одно из очень важных свойств машины Тьюринга — это возможность не только читать, но и записывать в клетки ленты. В отличие от этого, у конечного автомата может меняться только его текущее состояние.

У машины Тьюринга лента бесконечна. Если ленту ограничить то получим конечный автомат.

AndrewVK wrote:
> Но размер этого самого числа не лимитирован и может быть сколь угодно
> большим (хотя и не бесконечным).
Поэтому КА и неэквивалентен МТ, так как у МТ может быть бесконечно много
состояний.

Здравствуйте, eao197, Вы писали:

E>Оно совершенно спокойно делается одинаковым, поскольку для каждого сообщения в системе сохраняется информация о канале
хъ
E>E>Совершенно прозрачная схема работы.
Я вобще не вижу смысла в отсылке сообщения процессу. ИМХО сообщения нужно слать по логическим каналам которые являются совершенно отдельной сущьностью.

E>E>Ну ты же сам сначала сказал про мелкие процессы. Процессы -- это вполне конкретное понятие (если только речь идет не об Erlang-е). Тоже о чем ты говоришь ниже -- это потоки внутри одного процесса.
Процесс это понятие логическое. Я понимаю процесс как некое замкнутое объектное пространство. Те они могут бать даже в одном адресном пространстве это ничего не изменит.

E>Кстати, у тебя есть конкретые замеры накладных расходов на создание процессов в Linux-е?
Ну сам прикинь во что выльется fork сервера с 500 потоками работающим под нагрузкой до красна разогревающией 4-х процессорную машину...

E>В этом случае в SObjectizer вообще не нужно процессы плодить -- достаточно насоздавать столько агентов, сколько нужно. Хоть сотни тысяч.
Ты же в статье писал что SObjectizer плохо работает в среде с большим колличеством агентов?

E>Интересно, а какие готовые прикладные протоколы такое ввобще из коробки позволяют поддерживать?
На сколько мне известно никакие. Вот и пишу свой.

Здравствуйте, Cyberax, Вы писали:

>> Приведи хоть один реальный протокол в котором есть рекурсия.
C>Передача древесных данных?
И где можно почитать об этом "реальном" протоколе?

Здравствуйте, WolfHound, Вы писали:

E>>Оно совершенно спокойно делается одинаковым, поскольку для каждого сообщения в системе сохраняется информация о канале
WH>хъ
E>>E>Совершенно прозрачная схема работы.
WH>Я вобще не вижу смысла в отсылке сообщения процессу. ИМХО сообщения нужно слать по логическим каналам которые являются совершенно отдельной сущьностью.

Просто в SObjectizer своя модель взаимодействия. Что-то вроде модели publisher/subscriber, но при этом есть возможность организовывать в ее рамках peer-to-peer взаимодействие, если использовать идентификаторы коммуникационных каналов, через которые доступны subscriber-ы.

Это базовый механизм, на основе которых можно строить другие средства. Например, у нас используется надстройка над SObjectizer под названием mbapi (message box api), в которой есть понятие идентификатора почтового ящика (т.н. mbox). Все сообщения отсылаются на уникальные mbox-ы. Самы подсистема mbapi определяет, через какой коммуникационный канал процессу доступен конкретный mbox и при отсылке на него сообщения сама отправляет сообщение в этот канал.

E>>E>Ну ты же сам сначала сказал про мелкие процессы. Процессы -- это вполне конкретное понятие (если только речь идет не об Erlang-е). Тоже о чем ты говоришь ниже -- это потоки внутри одного процесса.
WH>Процесс это понятие логическое. Я понимаю процесс как некое замкнутое объектное пространство. Те они могут бать даже в одном адресном пространстве это ничего не изменит.

Ну здесь на лицо разная трактовка терминов.

E>>Кстати, у тебя есть конкретые замеры накладных расходов на создание процессов в Linux-е?
WH>Ну сам прикинь во что выльется fork сервера с 500 потоками работающим под нагрузкой до красна разогревающией 4-х процессорную машину...

Дык зачем было делать сервер с 500-ми потоками, если можно было сделать 500 маленьких процессов?
Я просто к тому спрашиваю, что бытует мнение о большей дешевизне старта нового процесса под Unix-ом, чем под Windows. Вот мне и интересно, делал ли ты сам для своей предметной области свои собственные замеры?

E>>В этом случае в SObjectizer вообще не нужно процессы плодить -- достаточно насоздавать столько агентов, сколько нужно. Хоть сотни тысяч.
WH>Ты же в статье писал что SObjectizer плохо работает в среде с большим колличеством агентов?

Я писал не о накладных расходах самого SObjectizer. С этим как раз проблем особых нет. Вот, например, в текущей третьей бете версии 4.4, которую я сейчас готовлю к релизу, есть реализация вот этой задачки

Автор: Курилка
Дата: 15.07.06

(кольцо customer-ов, по которому бегают токены). Тест показывает следующие результаты:

bash-3.1$ ./test.bench.customer_ring.exe -N 50000 -M 100
ring size: 50000; token count: 100; dispatcher: one thread
registration=> total: 2.750000 sec, price: 0.000055 sec; troughput: 18181.818182
ringing=> total: 38.046000 sec, price: 0.000008 sec; troughput: 131419.860169

bash-3.1$ ./test.bench.customer_ring.exe -N 100000 -M 100
ring size: 100000; token count: 100; dispatcher: one thread
registration=> total: 5.907000 sec, price: 0.000059 sec; troughput: 16929.067208
ringing=> total: 78.077000 sec, price: 0.000008 sec; troughput: 128078.691548

bash-3.1$ ./test.bench.customer_ring.exe -N 150000 -M 100
ring size: 150000; token count: 100; dispatcher: one thread
registration=> total: 8.547000 sec, price: 0.000057 sec; troughput: 17550.017550
ringing=> total: 118.234000 sec, price: 0.000008 sec; troughput: 126867.060236

(N -- количество агентов (customer-ов), M -- количество токенов). Значения registration показывают результаты регистрации агентов в SObjectizer, значения ringing -- результаты пересылки сообщений по кольцу (общее время, стоимость одной операции и количество операций в секунду). Тест завершается когда каждый из агентов M раз перешлет через себя токен (т.е. общее количесво сообщений в тесте -- N*M). Машина -- Pentium M 1.5GHz, 512Mb, VC++7.1.
Как видишь, производительность при увеличении количества агентов снижается не слишком сильно.
Затыки могут произойти, если будет большое (порядка нескольких тысяч) таймерных заявок, которые срабатывают приблизительно в одно время и которые не успевают обрабатываться до того, как наступит следующее время их срабатывания. Но это вполне понятная ситуация.

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

E>>Интересно, а какие готовые прикладные протоколы такое ввобще из коробки позволяют поддерживать?
WH>На сколько мне известно никакие. Вот и пишу свой.

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

Здравствуйте, Cyberax, Вы писали:

C>Поэтому КА и неэквивалентен МТ

Да, с МТ я наврал, согласен.

C>, так как у МТ может быть бесконечно много
C>состояний.

Ага. Другое дело, что для любой существующей реализации МТ это не так.

Здравствуйте, WolfHound, Вы писали:

WH>А зачем тебе нужна рекурсия? Что-то я не знаю ни одного рекурсивного протокола общения.

SOAP, к примеру, вполне себе может быть рекурсивным. Но описывается он не EBNF, а XSD.

WolfHound wrote:
> E>E>Ну ты же сам сначала сказал про мелкие /процессы/. Процессы -- это
> вполне конкретное понятие (если только речь идет не об Erlang-е). Тоже о
> чем ты говоришь ниже -- это потоки внутри одного процесса.
> Процесс это понятие логическое. Я понимаю процесс как некое замкнутое
> объектное пространство. Те они могут бать даже в одном адресном
> пространстве это ничего не изменит.
Какие проблемы организовать это в C++ или C#? Глобальные и статические
переменные только нужно будет заменить на контестно-зависимые.

WolfHound wrote:
>> > Приведи хоть один реальный протокол в котором есть рекурсия.
> C>Передача древесных данных?
> И где можно почитать об этом "реальном" протоколе?
Сам догадайся. Вот пример:

struct tree_node
{
    int payload;
    tree_node *left,*right;
};

void write_tree_node(tree_node *root, stream *str)
{
   if (!root) return str->write(0);

   str->write(payload);
   write_tree_node(root->left,str);
   write_tree_node(root->right,str);
}

AndrewVK wrote:
> C>, так как у МТ может быть бесконечно много
> C>состояний.
> Ага. Другое дело, что для любой существующей реализации МТ это не так.
Ну так весь мир — это один большой КА

Здравствуйте, VladD2, Вы писали:

AVK>>Ну, в версии 3.0 таки появилась спецификация КОП, но большинство тех, кто говорит о компонентности CORBA, как правило имеют ввиду ее предыдущие версии.

VD>Не не появилась. Это надо видеть что они там под помонентностью понимают.

И что они там под компонентностью понимают?


VD>Это чистой воды терминалогическая эквилибристика.

Да нет. Такая же точно компонентность как и везде. Есть только одно маааленькое отличие: компоненты CORBA не создаются сами по себе "из воздуха". Объекты верхнего уровня — службы, ресолвятся, т.е. ищутся и находятся, а затем эти службы выступают как фабрики компонент и проводники метаинформации. Тут все логично, ведь речь идет о распределенных гетерогенных системах, т.е. каждая "железка" или ОС создает бинарные компоненты, которые могут исполнятся именно на ее платформе. Ну а после создания они прекрасно работают совместно по сети.

Здравствуйте, Cyberax, Вы писали:

C>Какие проблемы организовать это в C++ или C#?
А кто говорил про проблемы?

C>Глобальные и статические переменные только нужно будет заменить на контестно-зависимые.
Дык статические переменные это вобще зло и их нужно искоренять.

Здравствуйте, AndrewVK, Вы писали:

WH>>А зачем тебе нужна рекурсия? Что-то я не знаю ни одного рекурсивного протокола общения.
AVK>SOAP, к примеру, вполне себе может быть рекурсивным. Но описывается он не EBNF, а XSD.
Ну такими темпами и HTTP можно назвать рекурсивным протколом...

Здравствуйте, WolfHound, Вы писали:

WH>Ну такими темпами и HTTP можно назвать рекурсивным протколом...

HTTP нельзя. SOAP можно, там можно описать рекурсивную структуру данных.

Здравствуйте, AndrewVK, Вы писали:

AVK>Но размер этого самого числа не лимитирован и может быть сколь угодно большим (хотя и не бесконечным).

Если чисто теоретически, то МТ наверно можно эмулировать при помощи КА, если предположить что он может быть бесконечного размера. Но мы ведь о практике говорим, не так ли? А на практике попытка эмулировать LR-парсер при помощи КА будет дико неэффективной.

Здравствуйте, WolfHound, Вы писали:

AVC>>Что касается других тезисов WolfHound-а (а они сводятся к тому, что активные объекты — это плохо), то, ИМХО, они того же типа, что и мысль про EBNF.
AVC>>Возможность в Активном Обероне и Зонноне работать с активными объектами — это дополнительная (и очень хорошая) возможность, как и циклы в EBNF.
WH>Хоть бы попытался понять о чем я говорю...

Я пытаюсь.
Я только хотел сказать, что ведь можно использовать активные объекты и в рамках отдельных процессов (чем это хуже thread-ов), не сводя все к выбору "или-или, а третьего не дано".

WH>Еще раз активные объекты плохоя идея не по тому что они есть в Виртовских языках, а просто по тому что это плохая идея.
WH>Ну нельзя вешать протокол общения на объект. Ну не работет это если объекту нужно общатся с несколькими клиентами. Не работает просто по тому что работать не может ибо состояние одно на всех. Особенно весело это становится если разным клиентам нужны разные протоколы.

Мне кажется, в Зонноне протокол (диалог) вешается на систему (или рантайм), а не на объект.
Правда, эта информация получена мной из разговора и нуждается в проверке.

WH>Также это плохая идея по тому что все плавает в одном объектном пространстве. И эффективно оно может работать только на одном процессоре (хотя множество изолированных объектных пространств всеравно будут работать лучше ибо ГЦ можно запускать по очереди для каждого из них и сканировать ему нужно меньше). Если появляется второй то мы получаем огромные штрафы при вызове мусорщика ибо встают сразу ВСЕ потоки и ВСЕ процессоры в то время как можно тормознуть только один (а то и тормознуть частично вытясная ГЦ убирающий один процесс болие приоритетным процессом). А в случае кластера (про болие распределенную систему я вобще молчу) один ГЦ на всех просто не работает.

Есть какие-то данные измерений или это аксиома?
Мне трудно прямо сейчас аргументированно возразить; по поводу системы, основанной на активных объектах, читал в свое время только диссертацию Мюллера (насколько я понимаю, речь в ней идет о прообразе BlueBottle):
http://www.oberon2005.ru/paper/eth14755.pdf
Из нее, правда, совсем не следовали такие пессимистические выводы.
Запомнилось, что системный вызов в Aos примерно в 30 раз эффективнее системного вызова в Linux.

Дарней wrote:
> AVK>Но размер этого самого числа не лимитирован и может быть сколь
> угодно большим (хотя и не бесконечным).
> Если /чисто теоретически/, то МТ наверно можно эмулировать при помощи
> КА, если предположить что он может быть бесконечного размера.
КА — он по определению конечный

Здравствуйте, Cyberax, Вы писали:

C>Передача древесных данных?

Это уже не сам протокол, а данные, которые ты через него перегоняешь. Мухи — отдельно, котлеты — отдельно.