Сообщение Re[15]: Эльбрус мёртв, да здравствует Эльбрус-Б! от 25.05.2025 8:19
Изменено 25.05.2025 8:40 vdimas
Re[15]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, ·, Вы писали:
S>>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java.
V>>Не систему трейдинга,
·>Disruptor в первую очередь разрабатывался для системы трейдинга.
Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
V>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
·>Гвоздём там является секвенсер:
·>
Опять эта брехня...
Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
V>>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
·>Что за ваша реализация?
·>Да, кстати, disruptor — это всё-таки не совсем очередь.
Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Эзотерика она такая, в отсутствии понимания даёт веру в некие плохообъяснимые свои ощущения. ))
·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Не говори о том, о чём не знаешь.
Некоторые биржи генерят десятки миллионов сообщений в секунду суммарно по различным инструментам в пике на одном узле.
Наша система способна работать в качестве как клиентской, так и серверной.
И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
В нашей реализации при максимуме нагрузки приходится по одному CAS на десятки-сотни элементов.
Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. ))
В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди, а любой multicast-канал имеет обязательно два потока, которые надо сливать в один, упорядочивать и отбрасывать дубликаты — это стандарт для бирж.
И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Да и вообще, событийная модель на виртуальных вызовах...
Всё это какое-то одно сплошное нубство.
Кароч, нормально Disruptor работает только в режиме spin-wait со стороны consumer.
Там явно самоучки от IT пилили. ))
V>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
·>Без фиксированной ёмкости у тебя будет проблема с latency.
Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО.
И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor.
Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками.
А еще эта очередь засирает и инвалидирует кеш!
У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
И эта очередь работает через стековую организацию в оба конца, т.е. при малом кол-ве сообщений в очереди "вагончиками" будут одни и те же как прикладные, так и инфраструктурные объекты, т.к. будут трогаться только верхние элементы всех стековых буферов. И такой подход на C# тоже дал офигенный профит, что реализация пофит не уступает нейтивной по эффективности.
Просто надо ж понимать хотя бы самые базовые вещи обеспечения эффективности на современных архитектурах.
V>>Плюс у нас есть возможность ожидать на примитиве синхронизации уровня ОС, т.е. отправлять поток в спячку, освобождая аппаратный поток для других задач в отсутствии данных, а у тех безальтернативно спин-ожидание.
·>Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies
И доку читал и исходники внимательно изучал.
Детсад детсадом погоняет.
Это писали непрофессиональные разрабы ни в одном из своих мест.
Они тупо взяли одну из валяющихся в Сети реализаций lock-free кругового буфера и аккуратно перенесли на Джаву. ))
Но во всём остальном оставили такой же точно мрак — тупая событийная модель как в турбо-паскале 80-х, куча виртуальных вызовов где этого совершенно не требуется на данном уровне сущностей. В общем, вот это хорошо знакомое бессмысленное и беспощадное джавовское мельтешение в мелочах, на радость продавцам электричества.
Пороть вас некому... Натравить бы на вас Гринпис, а то они не с теми воюют. ))
V>>Ты код-то поизучай внимательно, он у них открыт. ))
·>Вот с этого и начни, прежде чем чушь нести.
Я-то поизучал внимательно еще в прошлый раз, в отличие от пустопорожнего тебя.
И я хорошо понимаю, что там происходит и почему. Но еще в прошлом нашем обсуждении этого Disruptor стало быстро понятно, что для тебя там всё тёмный лес — ты не понимаешь тонкостей. Значит, никогда всерьёз не вылизывал код на быстродействие, не видишь тонких мест современной аппаратуры, эрудиция в этой области у тебя примерно нулевая.
Понимаешь, даже похер, что у тебя непрофильное образование, но самому покрыть пробелы, набить руку можно было уже давно. Просто ты выбрал себе ту самую раздражающую других разрабов роль похериста от IT, которые преднамеренно сосредотачиваются исключительно и только на высоком уровне и собственном балабольстве с важным видом, вызывающим у окружающих только раздражение и насмешки. Не доходит до тебя, смотрю, что звиздеть — не мешки ворочать. ))
S>>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java.
V>>Не систему трейдинга,
·>Disruptor в первую очередь разрабатывался для системы трейдинга.
Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
V>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
·>Гвоздём там является секвенсер:
·>
·>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.
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.
Опять эта брехня...
Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
V>>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
·>Что за ваша реализация?
·>Да, кстати, disruptor — это всё-таки не совсем очередь.
Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Эзотерика она такая, в отсутствии понимания даёт веру в некие плохообъяснимые свои ощущения. ))
·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Не говори о том, о чём не знаешь.
Некоторые биржи генерят десятки миллионов сообщений в секунду суммарно по различным инструментам в пике на одном узле.
Наша система способна работать в качестве как клиентской, так и серверной.
И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
В нашей реализации при максимуме нагрузки приходится по одному CAS на десятки-сотни элементов.
Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. ))
В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди, а любой multicast-канал имеет обязательно два потока, которые надо сливать в один, упорядочивать и отбрасывать дубликаты — это стандарт для бирж.
И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Да и вообще, событийная модель на виртуальных вызовах...
Всё это какое-то одно сплошное нубство.
Кароч, нормально Disruptor работает только в режиме spin-wait со стороны consumer.
Там явно самоучки от IT пилили. ))
V>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
·>Без фиксированной ёмкости у тебя будет проблема с latency.
Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО.
И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor.
Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками.
А еще эта очередь засирает и инвалидирует кеш!
У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
И эта очередь работает через стековую организацию в оба конца, т.е. при малом кол-ве сообщений в очереди "вагончиками" будут одни и те же как прикладные, так и инфраструктурные объекты, т.к. будут трогаться только верхние элементы всех стековых буферов. И такой подход на C# тоже дал офигенный профит, что реализация пофит не уступает нейтивной по эффективности.
Просто надо ж понимать хотя бы самые базовые вещи обеспечения эффективности на современных архитектурах.
V>>Плюс у нас есть возможность ожидать на примитиве синхронизации уровня ОС, т.е. отправлять поток в спячку, освобождая аппаратный поток для других задач в отсутствии данных, а у тех безальтернативно спин-ожидание.
·>Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies
И доку читал и исходники внимательно изучал.
Детсад детсадом погоняет.
Это писали непрофессиональные разрабы ни в одном из своих мест.
Они тупо взяли одну из валяющихся в Сети реализаций lock-free кругового буфера и аккуратно перенесли на Джаву. ))
Но во всём остальном оставили такой же точно мрак — тупая событийная модель как в турбо-паскале 80-х, куча виртуальных вызовов где этого совершенно не требуется на данном уровне сущностей. В общем, вот это хорошо знакомое бессмысленное и беспощадное джавовское мельтешение в мелочах, на радость продавцам электричества.
Пороть вас некому... Натравить бы на вас Гринпис, а то они не с теми воюют. ))
V>>Ты код-то поизучай внимательно, он у них открыт. ))
·>Вот с этого и начни, прежде чем чушь нести.
Я-то поизучал внимательно еще в прошлый раз, в отличие от пустопорожнего тебя.
И я хорошо понимаю, что там происходит и почему. Но еще в прошлом нашем обсуждении этого Disruptor стало быстро понятно, что для тебя там всё тёмный лес — ты не понимаешь тонкостей. Значит, никогда всерьёз не вылизывал код на быстродействие, не видишь тонких мест современной аппаратуры, эрудиция в этой области у тебя примерно нулевая.
Понимаешь, даже похер, что у тебя непрофильное образование, но самому покрыть пробелы, набить руку можно было уже давно. Просто ты выбрал себе ту самую раздражающую других разрабов роль похериста от IT, которые преднамеренно сосредотачиваются исключительно и только на высоком уровне и собственном балабольстве с важным видом, вызывающим у окружающих только раздражение и насмешки. Не доходит до тебя, смотрю, что звиздеть — не мешки ворочать. ))
Re[15]: Эльбрус мёртв, да здравствует Эльбрус-Б!
Здравствуйте, ·, Вы писали:
S>>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java.
V>>Не систему трейдинга,
·>Disruptor в первую очередь разрабатывался для системы трейдинга.
Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
V>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
·>Гвоздём там является секвенсер:
·>
Опять эта брехня...
Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
V>>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
·>Что за ваша реализация?
·>Да, кстати, disruptor — это всё-таки не совсем очередь.
Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Эзотерика она такая, в отсутствии понимания даёт веру в некие плохообъяснимые свои ощущения. ))
·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Не говори о том, о чём не знаешь.
Некоторые биржи генерят десятки миллионов сообщений в секунду суммарно по различным инструментам в пике на одном узле.
Наша система способна работать в качестве как клиентской, так и серверной.
И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
В нашей реализации при максимуме нагрузки приходится по одному CAS на десятки-сотни элементов.
Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. ))
В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди, а любой multicast-канал имеет обязательно два потока, которые надо сливать в один, упорядочивать и отбрасывать дубликаты — это стандарт для бирж.
И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Да и вообще, событийная модель на виртуальных вызовах...
Всё это какое-то одно сплошное нубство.
Кароч, нормально Disruptor работает только в режиме spin-wait со стороны consumer.
Там явно самоучки от IT пилили. ))
V>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
·>Без фиксированной ёмкости у тебя будет проблема с latency.
Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО.
И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor.
Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками.
А еще эта очередь засирает и инвалидирует кеш!
У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
И эта очередь работает через стековую организацию в оба конца, т.е. при малом кол-ве сообщений в очереди "вагончиками" будут одни и те же как прикладные, так и инфраструктурные объекты, т.к. будут трогаться только верхние элементы всех стековых буферов. И такой подход на C# тоже дал офигенный профит, что реализация не уступает нейтивной по эффективности.
Просто надо ж понимать хотя бы самые базовые вещи обеспечения эффективности на современных архитектурах.
V>>Плюс у нас есть возможность ожидать на примитиве синхронизации уровня ОС, т.е. отправлять поток в спячку, освобождая аппаратный поток для других задач в отсутствии данных, а у тех безальтернативно спин-ожидание.
·>Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies
И доку читал и исходники внимательно изучал.
Детсад детсадом погоняет.
Это писали непрофессиональные разрабы ни в одном из своих мест.
Они тупо взяли одну из валяющихся в Сети реализаций lock-free кругового буфера и аккуратно перенесли на Джаву. ))
Но во всём остальном оставили такой же точно мрак — тупая событийная модель как в турбо-паскале 80-х, куча виртуальных вызовов где этого совершенно не требуется на данном уровне сущностей. В общем, вот это хорошо знакомое бессмысленное и беспощадное джавовское мельтешение в мелочах, на радость продавцам электричества.
Пороть вас некому... Натравить бы на вас Гринпис, а то они не с теми воюют. ))
V>>Ты код-то поизучай внимательно, он у них открыт. ))
·>Вот с этого и начни, прежде чем чушь нести.
Я-то поизучал внимательно еще в прошлый раз, в отличие от пустопорожнего тебя.
И я хорошо понимаю, что там происходит и почему. Но еще в прошлом нашем обсуждении этого Disruptor стало быстро понятно, что для тебя там всё тёмный лес — ты не понимаешь тонкостей. Значит, никогда всерьёз не вылизывал код на быстродействие, не видишь тонких мест современной аппаратуры, эрудиция в этой области у тебя примерно нулевая.
Понимаешь, даже похер, что у тебя непрофильное образование, но самому покрыть пробелы, набить руку можно было уже давно. Просто ты выбрал себе ту самую раздражающую других разрабов роль похериста от IT, которые преднамеренно сосредотачиваются исключительно и только на высоком уровне и собственном балабольстве с важным видом, вызывающим у окружающих только раздражение и насмешки. Не доходит до тебя, смотрю, что звиздеть — не мешки ворочать. ))
S>>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java.
V>>Не систему трейдинга,
·>Disruptor в первую очередь разрабатывался для системы трейдинга.
Так ты не меня поправляй, а Синклера, который спорил с тезисом о необходимости эффективного обмена данными м/у потоками, при этом сами же привёл пример подсистемы, спроектированной именно для такого обмена. Это вышло вдвойне забавно, бо и без этого его позиция улыбала донельзя. ))
А для трейдинга или нет — в контексте обмена аргументами не принципиально, пустое твоё замечание, лишь бы вставить бесполезные 5 копеек.
V>>а межпоточную lock-free круговую очередь, гвоздь программы был в ней, не везёт тебе...
·>Гвоздём там является секвенсер:
·>
·>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.
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.
Опять эта брехня...
Подставь некую свою тормозную очередь в Disruptor, и система будет тормозить как обычное Джава-приложение.
V>>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
·>Что за ваша реализация?
·>Да, кстати, disruptor — это всё-таки не совсем очередь.
Ага, я помню твои попытки обвинить окружающих в том, что они не понимают отличие константности от иммутабельности.
Эзотерика она такая, в отсутствии понимания даёт веру в некие плохообъяснимые свои ощущения. ))
·>В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Не говори о том, о чём не знаешь.
Некоторые биржи генерят десятки миллионов сообщений в секунду суммарно по различным инструментам в пике на одном узле.
Наша система способна работать в качестве как клиентской, так и серверной.
И на клиента тоже миллионы в секунду могут неожиданно упасть в пике, т.е. умение шустро перелопатить трафик тоже важно.
Так вот, именно в пиковой нагрузке этот Disruptor сливает, потому что требует обязательно 1-2 CAS-операций на чтение каждого элемента очереди в общем случае.
В нашей реализации при максимуме нагрузки приходится по одному CAS на десятки-сотни элементов.
Другое дело, что для Джавы это похер, бо на парсинге сообщений и прикладной обработке сжирается столько, что лишние пару CAS на каждое сообщение не видны и под микроскопом. ))
В нейтиве зато эти лишние CAS ой как видны, бо там другие порядки расходов на прикладные вещи.
И да, наша реализация изначально умеет работать в режиме multiple producer, что дорого для круговой interlocked-очереди, а любой multicast-канал имеет обязательно два потока, которые надо сливать в один, упорядочивать и отбрасывать дубликаты — это стандарт для бирж.
И да, спин-ожидание у нас тоже присутствует в кач-ве опции (полезно на клиентской стороне) и средняя реакция consumer в сотню-другую наносекунд на появление данных в очереди — тут уже предел современных систем обеспечения когерентности в разных потоках. Кстате, тоже можно producer+consumer посадить на одно ядро, разнеся по гипертредингу, тоже будет максимально быстро.
А в Джаве можно указать, на каких аппаратных ядрах исполнять тот или иной поток?
·>Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.
Я уже делал замечание — в случае задействования механизма ожидания на примитиве синхронизации, вся эта система начинает дико тормозить, потому что тормозится Producer, который в этом случае дёргает примитив синхронизации в своём колбэке, вызываемом после помещения элемента в очередь. И там сразу полная ж-па наступает.
Да и вообще, событийная модель на виртуальных вызовах...
Всё это какое-то одно сплошное нубство.
Кароч, нормально Disruptor работает только в режиме spin-wait со стороны consumer.
Там явно самоучки от IT пилили. ))
V>>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
·>Без фиксированной ёмкости у тебя будет проблема с latency.
Одно косвенное чтение, т.е. примерно плюс 0-8 наносекунд, бо косвенное безусловное чтение зачастую делается процами еще на этапе предвыборки механизмом ОоО.
И минус многие сотни наносекунд и даже микросекунд на всём остальном, в сравнении с реализацией Disruptor.
Потому что круговая очередь — это изначально не самая дешевая lock-free структура для передачи данных м/у потоками.
А еще эта очередь засирает и инвалидирует кеш!
У нас тоже получается де-факто круговая очередь, но она динамическая — растёт в максимуме нагрузки и отдаёт постепенно элементы обратно в память, если не требуются.
И эта очередь работает через стековую организацию в оба конца, т.е. при малом кол-ве сообщений в очереди "вагончиками" будут одни и те же как прикладные, так и инфраструктурные объекты, т.к. будут трогаться только верхние элементы всех стековых буферов. И такой подход на C# тоже дал офигенный профит, что реализация не уступает нейтивной по эффективности.
Просто надо ж понимать хотя бы самые базовые вещи обеспечения эффективности на современных архитектурах.
V>>Плюс у нас есть возможность ожидать на примитиве синхронизации уровня ОС, т.е. отправлять поток в спячку, освобождая аппаратный поток для других задач в отсутствии данных, а у тех безальтернативно спин-ожидание.
·>Доки-то хоть читал? https://lmax-exchange.github.io/disruptor/user-guide/index.html#_alternative_wait_strategies
И доку читал и исходники внимательно изучал.
Детсад детсадом погоняет.
Это писали непрофессиональные разрабы ни в одном из своих мест.
Они тупо взяли одну из валяющихся в Сети реализаций lock-free кругового буфера и аккуратно перенесли на Джаву. ))
Но во всём остальном оставили такой же точно мрак — тупая событийная модель как в турбо-паскале 80-х, куча виртуальных вызовов где этого совершенно не требуется на данном уровне сущностей. В общем, вот это хорошо знакомое бессмысленное и беспощадное джавовское мельтешение в мелочах, на радость продавцам электричества.
Пороть вас некому... Натравить бы на вас Гринпис, а то они не с теми воюют. ))
V>>Ты код-то поизучай внимательно, он у них открыт. ))
·>Вот с этого и начни, прежде чем чушь нести.
Я-то поизучал внимательно еще в прошлый раз, в отличие от пустопорожнего тебя.
И я хорошо понимаю, что там происходит и почему. Но еще в прошлом нашем обсуждении этого Disruptor стало быстро понятно, что для тебя там всё тёмный лес — ты не понимаешь тонкостей. Значит, никогда всерьёз не вылизывал код на быстродействие, не видишь тонких мест современной аппаратуры, эрудиция в этой области у тебя примерно нулевая.
Понимаешь, даже похер, что у тебя непрофильное образование, но самому покрыть пробелы, набить руку можно было уже давно. Просто ты выбрал себе ту самую раздражающую других разрабов роль похериста от IT, которые преднамеренно сосредотачиваются исключительно и только на высоком уровне и собственном балабольстве с важным видом, вызывающим у окружающих только раздражение и насмешки. Не доходит до тебя, смотрю, что звиздеть — не мешки ворочать. ))