T>>Разделяемая память поддержана аппаратно (да-да! поддержана аппаратно), передача сообщений — нет. Посмотрим, что будет, если будет хотя бы поддержка обоих.
К>А есть примеры как поддержка сообщений может быть поддержана аппаратно?

На уровне инструкций: http://wavescalar.cs.washington.edu/

Это совсем низкий уровень, совсем маленькие сообщения.

Сравни общую простоту реализации и масштабируемость с простотой реализации и масштабируемостью "системы с разделяемой памятью", ранее известной под именем обычный процессор (RISC, допустим).

В обычных процессорах разделяемая память — регистровый файл.

И мало кто знает, что в лучшем представителе семейства RISC DEC Alpha 21264 оная память была разделена на две части по числу каналов исполнения инструкций и половинки синхронизировались через такт после окончания операции.

Это ужас просто.

T>>Надо отметить, что эти времена уходят, поскольку мы движемся в сторону using more than eight or sixteen cores.
E>Думаю, что не ошибусь, если скажу, что очень многие разработчики пока не занимались оптимизацией своих программ даже для 2-х ядерных процессоров.

Я тут рядом ссылку дал: http://wavescalar.cs.washington.edu/

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

А главное, насколько проста конструкция! (я сравнивал её с RISC, это просто чудо, до чего проста)

Вот микропример того, как разделяемая память — регистровый файл, — может стать тормозом.

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

S>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше.
А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?

S>>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше.
S>>Никаких проблем.
E>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.

Поддержи очередь аппаратно.

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

E>>>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений.
S>>Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы.
S>>Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица".

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

1. Никаких проблем обрабатывать большие пакеты данных со множеством сообщений внутри, в рамках модели "гармонично взаимодействующих процессов", нет. Просто посылаешь большой пакет. Который вовсе не обязан копироваться, и будет передан по ссылке — никто его модифицировать не будет.
2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.

Ты вообще живой раутер в глаза видел, или как? Давай, поучи эрлангистов делать раутеры.

Да здравствует всемирная пионерская организация! .

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

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

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

DK>Я здесь вижу только одну проблему: если у нас есть 2 потока, модифицирующих дерево, и оба они "одновременно" получат сообщение, приводящее к необходимости это дерево модифицировать. Тогда каждый из них построит своё новое дерево, и после этого разошлёт новый корень, но в результате данные, изменённые одним из потоков будут потеряны.

DK>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.

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

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

G>2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.

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

Достаточно? Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?

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

S>>>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше.
S>>>Никаких проблем.
E>>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.

T>Поддержи очередь аппаратно.

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

V>RSDN как обычно жжот. Спорят все команды. Одна команда воображает, будто вторая говорит, что разделяемая память всегда эффективнее сообщений, и, соответственно опровергает его. Вторая команда воображает, что первая утверждает, что сообщения всегда эффективнее разделяемой памяти и тоже опровергает его. Единственное в чем все спорщики сходятся — это в игнорировании аргументов друг друга

Зато можно с чистой совестью поесть попкорна

E>>>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.
T>>Поддержи очередь аппаратно.
E>Насколько мне известно, программистам сейчас приходится с большим трудом находить качественные реализации быстрых конкурентных очередей и т.п. в виде готовых широкораспространенных библиотек. Из-за чего эти очереди реализуются каждым разработчиком снова и снова -- NIH синдром процветает. Теперь ты предлагаешь разработчикам еще и аппаратную поддержку очередей делать самим?

Нет.

Разделяемая память у тебя уже есть, и она реализована аппаратно.

(на всякий случай — и реализована на аппаратных сообщениях, пусть и ограниченных)

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

Сейчас у тебя это не так, чем ты и пользуешься.

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

T>Сейчас у тебя это не так, чем ты и пользуешься.

Да ничем он не пользуется, он вообще слабо себе представляет, что говорит. Ты-то хоть на глупость не ведись. Очередь почти ничем не по затратам не отличается от обычного вызова synchronized метода. Более того, она на практике гораздо гуманнее, поскольку асинхронна, и не требует "рандеву" приемника и получателя.

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

G>>2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.

E>Есть такие услуги у ряда контент-провайдеров -- массовые рассылки sms по результатам какого-то события, как-то начисление зарплаты, результаты футбольных матчей, объявление курсов валют, прогнозы погоды и т.д. При их организации решаются задачи быстрой обработки большого числа sms (от нескольких сотен тысяч штук до нескольких миллионов).

E>Достаточно?

А, ты об этой маленькой фитюльке, которая в колл-центрах и контакт-центрах проходит под собирательным названием "outbound campaign". Ну какой же это раутер. Фигня это полная, а не раутер.

E>Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?

Что за кривляния. Хочешь — спрашивай, я тебе отвечу. Я не понял, ты меня напугать штоли хотел?

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

DK>>>>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.

E>>>Этот протокол нужен в любом случае.

DK>>Если модифицирующий поток один, то ему не с кем будет конкурировать.

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

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

E>Если же поток-модификатор один, то не важно, как потоки-читатели будут видеть изменения -- через разделяемую переменную или через уведомления. Но тогда и протокол не нужен, тут вы правы.

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

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

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

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

E>>>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений.
S>>Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы.
S>>Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица".

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

"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.

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

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

Как и 7% преимущества в скорости. Известная песня.

E>>Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?

G>Что за кривляния. Хочешь — спрашивай, я тебе отвечу.

Ответь. Освети свой опыт разработки телекоммуникационных систем на Erlang-е.

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

G>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.

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

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

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

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

E>Как и 7% преимущества в скорости. Известная песня.

7% преимущества в скорости — это и правда фигня полная (особенно по сравнению с проигрышем OpenMP на примерно 140% в одном тесте, что ты предпочел забыть), что верно так же, как и то, что outbound — рассылка ни разу не раутер, а маленькая частная задача контакт-центра.

E>>>Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?

G>>Что за кривляния. Хочешь — спрашивай, я тебе отвечу.

E>Ответь. Освети свой опыт разработки телекоммуникационных систем на Erlang-е.

Давай, освещу. Хоть это к делу и не относится.

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

Системе 8 лет, это колцентр и АТС, написанная на С++. На эрланге, понятное дело, никто переписывать миллион строк кода там не будет, это нельзя сделать за разумное время, однако в перспективную архитектуру мы заложили "легкие потоки" с асинхронными сообщениями как в Эрланге. Потому, что по общему мнению, это удобно, просто в применении, и на практике в данных задачах данная модель дает выигрышь в производительности. "Телефонные" сервера — это задача массового параллелизма, и по доброй воле предпочтет иметь дело с явной низкоуровневой синхронизацией в таких задачах только идиот. Ну, я хотел сказать, очень упорный и трудолюбивый человек.

Задача, которую ты описал — это малюсенькая часть функциональности контакт-центра. Которая может быть сделана на коленке вообще без контакт-центра, и превращается в интересный фрагмент требований к ядру телефонии, будучи рассмотрена в контексте всей задачи. Естественно, производительность в данной задаче упрется в телефонию или сеть, и закачка больших пакетов в память для минимизации задержек не даст тебе почти ничего. Хотя, как я тебе показал, решая данную задачу на сообщениях, можно выиграть по сравнению с традиционной реализацией на разделяемой мутабельной памяти.

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

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

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

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

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

G>>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.

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

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

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

G>Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.

В разговоре с Siclair я несколько раз упоминал использование atomic_read. И он понял о чем я говорю, поскольку идея очень простая.

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

E>>Как и 7% преимущества в скорости. Известная песня.

G>7% преимущества в скорости — это и правда фигня полная

Это полная фигня на словах в форуме. На практике, ты не сможешь этот выигрыш нивелировать.

G>(особенно по сравнению с проигрышем OpenMP на примерно 140% в одном тесте, что ты предпочел забыть)

Я не забыл. Проигрыш OpenMP всего лишь доказывает, что не всегда у разделяемой памяти есть преимущества. Но ты забыл, что этого здесь никто и не отрицал.

G>что верно так же, как и то, что outbound — рассылка ни разу не раутер, а маленькая частная задача контакт-центра.

Я ничего не говорил о контакт-центрах.

G>Задача, которую ты описал — это малюсенькая часть функциональности контакт-центра.

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

G>Причина? Если ты дозваниваешся по списку, то тебе просто не надо дозваниваться до большего количества людей, чем у тебя есть в наличии исходящих линий, которые стоят денег. Если ты делаешь рассылку, то тебя в подавляющем большинстве случаев не особо волнует, насколько быстро она пройдет — за час, или полчаса. Задачу целесообразно пустить с низким приоритетом.

Сейчас ты говоришь о каких-то своих собственных материях.

G>На Эрланге я телефонных раутеров не писал,

Почему я не удивлен?