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

V>>>Не систему трейдинга,
V>·>Disruptor в первую очередь разрабатывался для системы трейдинга.
V>Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
Он не с этим спорил. Ты как всегда приписываешь свои фантазии оппонентам и их опровергаешь.

V>А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
В контексте было об "общей архитектуры и применяемых решений". В lmax придумали общую архитектуру и дизраптор в качестве решения.

V>>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
V>·>Гвоздём там является секвенсер:
V>·>

the Ring Buffer is only responsible for the storing and updating of the data (Events) that move through the Disruptor. For some advanced use cases, it can even be completely replaced by the user.

V>·>

Sequencer: The Sequencer is the real core of the Disruptor. The two implementations (single producer, multi producer) of this interface implement all the concurrent algorithms for fast, correct passing of data between producers and consumers.

V>Опять эта брехня...
Аргумент вида: "Вы всё врёти!!!"

V>Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
Софизм: "ложная дилемма". Почему ты решил, что вместо кольца непременно надо подставлять тормозную очередь?

V>Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Демагогия.

V>·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
V>Не говори о том, о чём не знаешь.
Демагогия.

V>Некоторые биржи генерят десятки миллионов сообщений в секунду
Некоторые это такие как lmax? Внезапно?

V>суммарно по различным инструментам в пике на одном узле.
Да беда в том, что в том же lmax инструменты вроде как различные, но 90% трафика идёт на какой-нибудь eurusd. И различность инструментов рояли не играет.

V>Наша система способна работать в качестве как клиентской, так и серверной.
V>И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Молодцы! Почти достигли то, что в lmax делали ~20 лет назад, на оборудовании того времени.

V>Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
Откуда этот бред? И ведь про батчинг я тебе уже упоминал, но ты ж не читатель.

V>Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. ))
V>В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
Я уже давно знаю, что в джаве ты полный ноль, зачем это в очередной раз демонстрируешь?

V>И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди,
lmax disruptor тоже. Ты с докой, очевидно, до сих пор не ознакомился.

V>И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А что так у вас плохо? У lmax было 50ns афаир, несколько лет назад.

V>А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
Нет, конечно. Это указывается в ОС, а не в ЯП. Или ты хотел узнать, можно ли из джавы позвать соответствующий сискол? Ясен пень, что можно.

V>·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
V>Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Дёргает в смысле notify шлёт? В общем не знаю что там у вас тормозит.

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

V>>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
V>·>Без фиксированной ёмкости у тебя будет проблема с latency.
V>Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО.
V>И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor.
V>Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками.
V>А еще эта очередь засирает и инвалидирует кеш!
Именно, поэтому и изобрели disruptor.

V>У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
Ну так работа с кучей тебе даст длиннющий хвост в латенси.

V>реализация не уступает нейтивной по эффективности.
Что за "у вас"-то такое? Где можно поглядеть на это чудо?

V>·>Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies
V>И доку читал и исходники внимательно изучал.
Врёшь. Откуда тогда твои пассажи про отсутствие альтернативных стратегий ожидания?

V>[демагогия и распальцовки поскипаны]