Здравствуйте, ·, Вы писали:
·>Справедливости ради стоит заметить, что в шарпе пришлось унизительно расставлять unsafe да ещё какие-то прагмы для инлайнинга.
Там надо ещё посмотреть, "пришлось" или "удалось". Я не видел сравнительных бенчей .Net версии супротив Java.
·>А в src/Disruptor/Util/InternalUtil.cs вообще какие-то магические коды, почти ассемблерные вставки; правда лень разбираться для чего это.
Да, там кокие-то чудеса. На первый взгляд выглядит совершенно как обычный ансейф-код обращения к массиву, минуя проверки диапазона.
Зачем они это навертели, вместо простых и понятных манипуляций с указателями в unsafe — х.з. И вообще, там много непонятного кода.

·>Такое ощущение, что писать на шарпе high performance можно только из любви к искусству...
Я с вами согласен, но акценты расставил бы по-другому: писать high performance из любви к искусству лучше таки на шарпе.
Немножко пообщался с коллегами, которые пилят JVM, и они, в целом, не вполне довольны процессом оптимизации перформанса приложений.
Потому что JIT в джаве живёт весьма своей жизнью; поэтому приходится много шаманить в поисках способа заставить его сделать что-то предсказуемое.
И это всё ещё может сломаться на следующей сборке JVM. В дотнете тоже есть такие места (интересны комменты в исходниках типа decimal), но в целом он даёт больше контроля над перформансом.

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