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

S>>Асинхронщина в дотнете, как и везде, в первую очередь зависит от общей архитектуры и применяемых решений. Ну, вот как LMAX Disruptor взял — и написал систему трейдинга на порядок быстрее, чем это считалось теоретически возможным на Java.
V>Не систему трейдинга,
Disruptor в первую очередь разрабатывался для системы трейдинга.

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.

V>В любом случае, наша реализация межпоточной очереди заметно эффективней, да еще без ограничений на её размер, в отличие от наивной реализации Disruptor.
Что за ваша реализация?
Да, кстати, disruptor — это всё-таки не совсем очередь.

S>>И для этого не пришлось ни ломать JIT, ни переписывать компилятор, ни раскладывать данные по линейкам кеша.
V>И да, разумеется, максимальный трафик перекачки достигается тогда, когда перекачиваемые данные разнесены по линейкам кеша и у них, и у нас, т.е. когда курсор чтения заметно отстаёт от курсора записи.
V>Ну вот как раз именно в этом режиме "постоянного насыщения очереди" наша реализация оказалась резко эффективней, т.е. в режиме наибольшей нагрузки.
V>В режиме передачи одиночных пакетов с паузой задержки оказались сравнимы.
В сердце трейдинговой системы (Execution Venue) нужна не наибольшая нагрузка, а наименьшая задержка и отсутствие джиттера.
Впрочем, дизраптор довольно гибкий и позволяет тьюнинг под конкретные требования. Скажем, для наибольшей нагрузки можно батчить и выбирать другую waiting strategy.

V>Но в нашей реализации, таки, пришлось доп. обслуживающие данные разносить по линейкам кеша — наша реализация чуть сложнее, чем простейший круговой буфер фиксированной ёмкости в реализации Disruptor.
Без фиксированной ёмкости у тебя будет проблема с latency.

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

V>В общем, самоучки от IT какие-то, простейшая дополнительная требуемая функциональность (рост очереди при необходимости, возможность ожидать на семафоре при необходимости) являются
V>у них невозможными, резко замедляющими вообще всё, что весь профит улетучивается.


V>Ты код-то поизучай внимательно, он у них открыт. ))
Вот с этого и начни, прежде чем чушь нести.