В одном видео столкнулся с паттерном проектирования о котором раньше не слышал... LMAX Disruptor. Кто знаком? Применяли на практике? В суть не особо вник, пока... вроде что-то похожее на CQRS. Смущает, что статьи все 2011 года, ровно как и видео. Насколько это реальный паттерн проектирования или очередной пиар ход непойми кого?

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

G>В одном видео столкнулся с паттерном проектирования о котором раньше не слышал... LMAX Disruptor. Кто знаком? Применяли на практике? В суть не особо вник, пока... вроде что-то похожее на CQRS. Смущает, что статьи все 2011 года, ровно как и видео. Насколько это реальный паттерн проектирования или очередной пиар ход непойми кого?

Это не паттерн, а библиотека реализующая несколько крайне эффективных абстракций взаимодействия типа RingBuffer и CAS. Мы задолго до дисраптора сделали нечто подобное в своем продукте. Получилось довольно быстро и надежно, но крайне гемморойно в разработке.

G>В одном видео столкнулся с паттерном проектирования о котором раньше не слышал... LMAX Disruptor. Кто знаком? Применяли на практике? В суть не особо вник, пока... вроде что-то похожее на CQRS. Смущает, что статьи все 2011 года, ровно как и видео. Насколько это реальный паттерн проектирования или очередной пиар ход непойми кого?

Я использовал (сначала .NET порт, позже самописку на тех же идеях). Для приложений где нужно максимально быстро прокачивать много небольших сообщений, пакетов от сети и всего прочего — отличная штука. Если же есть тяжёлая обработка пакетов, много фоновых задач, или там типичное приложение когда нужно на одно входящее сообщение три раза в базу слазить — неудобств больше чем профита.

Вот блог по теме Disruptor, с которым рекомендую ознакомиться

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

G>>В одном видео столкнулся с паттерном проектирования о котором раньше не слышал... LMAX Disruptor. Кто знаком? Применяли на практике? В суть не особо вник, пока... вроде что-то похожее на CQRS. Смущает, что статьи все 2011 года, ровно как и видео. Насколько это реальный паттерн проектирования или очередной пиар ход непойми кого?

_>Я использовал (сначала .NET порт, позже самописку на тех же идеях). Для приложений где нужно максимально быстро прокачивать много небольших сообщений, пакетов от сети и всего прочего — отличная штука. Если же есть тяжёлая обработка пакетов, много фоновых задач, или там типичное приложение когда нужно на одно входящее сообщение три раза в базу слазить — неудобств больше чем профита.

_>Вот блог по теме Disruptor, с которым рекомендую ознакомиться

Интересно, посмотрел на гитхабе порт под .net, последний коммит был очень давно. С чем это связано, появилось что-то более удобное и популярное. Или просто библиотека достаточно развита и добавить больше нечего?
Опять же блог ссылку на который вы дали — последняя запись 2012 год...

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

_>Я использовал (сначала .NET порт, позже самописку на тех же идеях). Для приложений где нужно максимально быстро прокачивать много небольших сообщений, пакетов от сети и всего прочего — отличная штука. Если же есть тяжёлая обработка пакетов, много фоновых задач, или там типичное приложение когда нужно на одно входящее сообщение три раза в базу слазить — неудобств больше чем профита.

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

Второе во всех портах переносилось лоб-в-лоб и зачастую только вредило. С учётом наличия тасков / dataflow и наконец-то нормальной производительности KestrelHttpServer смысла в нём в дотнете маловато всё-таки.

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

G>Интересно, посмотрел на гитхабе порт под .net, последний коммит был очень давно. С чем это связано, появилось что-то более удобное и популярное. Или просто библиотека достаточно развита и добавить больше нечего?

Хайп, сэр. Чисто принципиально штука довольно стандартная, с различными вариациями используется с незапамятных времён. Поскольку 99% разработчиков к высоконагруженным системам имеют отношение "читал в гугле" а учебников по матчасти не читали вообще, то в первый раз массово рассказано про сабж было на какой-то из java-конференций. Поскольку в докладах звучала магическая цифра в 100k tps, народ отреагировал "надо брать".

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

P.S. Для любителей погоняться за циферками в моде нынче вот это.

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

G>Интересно, посмотрел на гитхабе порт под .net, последний коммит был очень давно. С чем это связано, появилось что-то более удобное и популярное. Или просто библиотека достаточно развита и добавить больше нечего?
G>Опять же блог ссылку на который вы дали — последняя запись 2012 год...

Авторы допилили до состояния, которое их устраивает, а других дураков развивать эту библиотеку нет.

G>Интересно, посмотрел на гитхабе порт под .net, последний коммит был очень давно. С чем это связано, появилось что-то более удобное и популярное. Или просто библиотека достаточно развита и добавить больше нечего?
Для использования "искаропки" — появился TPL Dataflow, который в сочетании с async/await закрывает все сценарии кроме "нам нужно реально заморочиться ради обработки сообщения в ту же миллисекунду когда оно пришо". А для тех сценариев где битва за каждый такт всё-таки окупается — скорее всего придётся писать свою реализацию учитывающую и специфику задачи и специфику оборудования на котором это будет запускаться. А тут уже недалеко и до ухода всех критических вещей на уровень C++ — ради получения профита от in-place парсинга сообщений, всяких битовых триксов и т.п. Короче идейки в основе disruptor получаются ценнее самой реализации.

G>Опять же блог ссылку на который вы дали — последняя запись 2012 год...
Думаю по тем же причинам — очень мало проектов где на высокоуровневых языках реально ведут битву за такты. Гораздо чаще "высоконагруженным приложением" называют то приложение которое ложится под средненькой нагрузкой

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

G>>В одном видео столкнулся с паттерном проектирования о котором раньше не слышал... LMAX Disruptor. Кто знаком? Применяли на практике? В суть не особо вник, пока... вроде что-то похожее на CQRS. Смущает, что статьи все 2011 года, ровно как и видео. Насколько это реальный паттерн проектирования или очередной пиар ход непойми кого?
_>Я использовал (сначала .NET порт, позже самописку на тех же идеях). Для приложений где нужно максимально быстро прокачивать много небольших сообщений, пакетов от сети и всего прочего — отличная штука. Если же есть тяжёлая обработка пакетов, много фоновых задач, или там типичное приложение когда нужно на одно входящее сообщение три раза в базу слазить — неудобств больше чем профита.
Так правильно. Этот паттерн (таки это lock-free паттерн межпоточного взаимодействия, а не только библиотека) предназначен для low latency, а ты его применял для high throughput, с тормозными субд, да ещё и в .net, который производительностью никогда не блистал.

Для типичного приложения с http, субд и прочего оно конечно не нужно. Этот паттерн нужен для real-time систем, где важно время отклика меньше одной миллисекунды.

Из первых рук знаю, что LMAX активно применяет до сих пор, сам disruptor они не меняли как-то значительно в последние несколько лет, и так всё работает, поэтому и "не видно, что библиотека развивается".

.>Так правильно. Этот паттерн (таки это lock-free паттерн межпоточного взаимодействия, а не только библиотека) предназначен для low latency, а ты его применял для high throughput, с тормозными субд,
Ты попутал. Применял я по назначению, просто не советовал для типовых задач. Сами авторы disruptor'a писали что на этом паттерне у них есть весьма медленные операции, такие как создание отчётов и складывание бакапов в архивы. Так что использовать его по такому назначению всё-таки можно. Смысла мало исключительно из-за неудобства.

.>да ещё и в .net, который производительностью никогда не блистал.
Там где начинается lowlatency от любой платформы остаются рожки да ножки. Если на .net использовать сообщения в структурах, к которым обращаться по ref... В общем люди качали лям сообщений на ядро в секунду, что вроде как было выше чем у disruptor. Т.е. как писать решает куда больше чем на чём писать.

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

.>>Так правильно. Этот паттерн (таки это lock-free паттерн межпоточного взаимодействия, а не только библиотека) предназначен для low latency, а ты его применял для high throughput, с тормозными субд,
_>Ты попутал. Применял я по назначению, просто не советовал для типовых задач. Сами авторы disruptor'a писали что на этом паттерне у них есть весьма медленные операции, такие как создание отчётов и складывание бакапов в архивы. Так что использовать его по такому назначению всё-таки можно. Смысла мало исключительно из-за неудобства.
Там у них внутренний messaging между сервисами построен на базе дизрапторов. Да и собственно всё межпоточное и межсервисное взаимодействие.
Дизраптор проявляет себя когда у тебя есть несколько писателей, несколько читателей с барьерами (т.е. группа читателей Б может начинать работу только когда читатели группы А закончили работу) и это нужно делать с минимальными задержками — lock-free, gc-free, no context switch. Это важно в low latency core service.
Можно использовать в обычном приложении, но не даёт преимуществ по сравнению с другими подходами. Забабахать какой-нибудь active mq и много что сразу удобно заработает. Но с latency будет беда.

.>>да ещё и в .net, который производительностью никогда не блистал.
_>Там где начинается lowlatency от любой платформы остаются рожки да ножки. Если на .net использовать сообщения в структурах, к которым обращаться по ref... В общем люди качали лям сообщений на ядро в секунду, что вроде как было выше чем у disruptor. Т.е. как писать решает куда больше чем на чём писать.
"лям сообщений" это опять о throughput. А latency-то какой? В hft — .net нет, а java есть.

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

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

чем у disruptor. Т.е. как писать решает куда больше чем на чём писать.
·>"лям сообщений" это опять о throughput. А latency-то какой? В hft — .net нет, а java есть.
Это почему это в hft нет .net? Все зависит от алгоритма, популярность java в этой области обусловлена возможностью более гибкой настройки GC. Как правило они его отключают совсем, ставят на машину террабайт оперативки и лишь перезагружают раз в неделю.

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

G>чем у disruptor. Т.е. как писать решает куда больше чем на чём писать.
G>·>"лям сообщений" это опять о throughput. А latency-то какой? В hft — .net нет, а java есть.
G>Это почему это в hft нет .net?
А где ты видел? В трейдинге я видел только GUI на .net, но GUI frontend это не LL по определению. А backend, всегда что я видел, — либо java, либо C/C++.

G>Все зависит от алгоритма, популярность java в этой области обусловлена возможностью более гибкой настройки GC. Как правило они его отключают совсем, ставят на машину террабайт оперативки и лишь перезагружают раз в неделю.
lmax не отключают gc, а используют Zing JVM для core services. И памяти не так много, порядка сотни гб. В памяти приходится хранить данные — выбора нет, винты не обеспечивают нужной производительнсти.
Перегружают штатно раз в две недели, во время выкатывания релизов, но в общем потенциально работать может и гораздо дольше, gc происходят не чаще нескольких раз в день.
А ещё java умеет нормально под linux работать, а без правильной настройки OS и железа обеспечить LL тоже нереально.

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

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

G>>чем у disruptor. Т.е. как писать решает куда больше чем на чём писать.
G>>·>"лям сообщений" это опять о throughput. А latency-то какой? В hft — .net нет, а java есть.
G>>Это почему это в hft нет .net?
·>А где ты видел? В трейдинге я видел только GUI на .net, но GUI frontend это не LL по определению. А backend, всегда что я видел, — либо java, либо C/C++.
Видел у себя на рабочей тачке в настоящий момент...
Слышал, что у Deutchebank такая схема с GUI на .net и backend java, все таки WPF хорош...
И почему прямо .net не подходит для hft? Там ведь ничего сверхестественного и прям непостежимого для .net нет, или random forest реализация на java прям в разы быстрее?

G>>Все зависит от алгоритма, популярность java в этой области обусловлена возможностью более гибкой настройки GC. Как правило они его отключают совсем, ставят на машину террабайт оперативки и лишь перезагружают раз в неделю.
·>lmax не отключают gc, а используют Zing JVM для core services. И памяти не так много, порядка сотни гб. В памяти приходится хранить данные — выбора нет, винты не обеспечивают нужной производительнсти.
·>Перегружают штатно раз в две недели, во время выкатывания релизов, но в общем потенциально работать может и гораздо дольше, gc происходят не чаще нескольких раз в день.
·>А ещё java умеет нормально под linux работать, а без правильной настройки OS и железа обеспечить LL тоже нереально.
И зачем вам linux для hft? Насколько мне известно основная притензия к винде по сравнению с линуксом — это менее производительная многозадачность. Но здесь опять же от вашего алгоритма все зависит, если вы арбитражите фьючерс сбера со спотом, то там робот будет на 30 строк кода максимум...

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

G>>>Это почему это в hft нет .net?
G>·>А где ты видел? В трейдинге я видел только GUI на .net, но GUI frontend это не LL по определению. А backend, всегда что я видел, — либо java, либо C/C++.
G>Видел у себя на рабочей тачке в настоящий момент...
backend? А что именно делает, если не секрет, и какие характеристики latency?

G>Слышал, что у Deutchebank такая схема с GUI на .net и backend java, все таки WPF хорош...
Да у многих инвест-банков так же, насколько мне довелось слышать.

G>И почему прямо .net не подходит для hft? Там ведь ничего сверхестественного и прям непостежимого для .net нет, или random forest реализация на java прям в разы быстрее?
Да там не в алгоритмах дело, а в инфраструктуре. Уже ведь упоминал кое-что, ещё можно добавить суперский JIT, и Azul C4 pauseless garbage collector. Плюс опен-сорсность, поэтому можно всегда доковыряться до любого источника проблемы.

G>·>lmax не отключают gc, а используют Zing JVM для core services. И памяти не так много, порядка сотни гб. В памяти приходится хранить данные — выбора нет, винты не обеспечивают нужной производительнсти.
G>·>Перегружают штатно раз в две недели, во время выкатывания релизов, но в общем потенциально работать может и гораздо дольше, gc происходят не чаще нескольких раз в день.
G>·>А ещё java умеет нормально под linux работать, а без правильной настройки OS и железа обеспечить LL тоже нереально.
G>И зачем вам linux для hft? Насколько мне известно основная притензия к винде по сравнению с линуксом — это менее производительная многозадачность.
В линухе есть тулзы для анализа и подкрутки производительности — можно вполть до исходников ядра докопаться, чтобы выяснить откуда чёрт возьми тут возникла 300us задержка. И всякие тонкие настройки планировщика, CPU affinity, numa памяти, irq, сетевых устройств и т.п. Плюс всякая экзотика типа hardware timestamping и супербыстрые сетевые карты Solarflare не доступна виндузам.

G>Но здесь опять же от вашего алгоритма все зависит, если вы арбитражите фьючерс сбера со спотом, то там робот будет на 30 строк кода максимум...
LMAX это FX exchange, matching engine, MTF. А так же в hft входят ECN и всякие Smart Order Routing и т.п.
"Арбитражить" это по сути конечные клиенты всего этого дела.