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

V>·>Может просто ваше джава решение не лучшее? И за джавой идут к другим?
V>Наше лучшее. Просто самих таких клиентов резко меньше и они обычно не крупные.
V>А всякие JP-Morgan и прочие крупные клиенты нейтивные.
Ой, а почему они мне оффер на позицию java algo trading dev давали? У них там всё есть.

V>В общем, одна восемнадцатая от одной трети отличается нормально так.
V>Передёрнул так уж передёрнул. ))
Ок победил. Тут можно считать так и эдак, статистика вещь такая.

V>>>В самом языке нет потоков. А вот в системной библиотеке, являющейся частью стандарта, уже есть.
V>·>Прежде чем заявлять очередную глупось — погугли хоть 10 сек. Ключевое слово "jls-17".
V>Глупости заявляешь здесь только ты и вот это предложение погуглить — тоже, ес-но.
V>Я не хуже тебя представляю, что там с потоками в Джава и как оно устроено. И при чем тут язык или системные библиотеки.
А что причём? Твоё личное мнение?

V>А для борьбы с глупостью стоило посмотреть на язык go, где потоки встроены в сам язык.
Каким образом они там "встроены"? Судя по твоим рассужениям так же — часть библиотеки.

V>·>Ещё намёк — в каком пакете находится класс Thread?
V>Плевать с большой колокольни.
Плюй, не плюй, а факт остаётся фактом.

V>·>А вот всякие сетевые сокеты, файлы, коллекции, регекспы и прочее — да, это часть стандартной библиотеки, а не языка.
V>Я правильно понимаю, что от одного лишь имени собственного пакета "lang" у тебя малость зрение меняется?
А у тебя зрение меняется когда факты противоречат твоим убеждениям.

V>Треды — это отъемлимая часть аж бегом.
V>Ты демонстрируешь тут повадки новичков в Джаве, которые на голубом глазу путают язык и VM.
Ну погугли что такое monitorenter/monitorexit и описание поведения других инструкций в многопоточном окружении.

V>·>Причём тут вообще сокеты? Зачем ты упомянул их? Как они с протоколами HTTP или FIX связаны?
V>Напрямую связаны, ес-но.
Нет, конечно, не связаны. Или у тебя есть какие-то доказательства?

V>·>В смысле у вас только IOCP сокеты в нативе
V>В смысле виденные мною HTTP-серваки на дотнете используют такие сетевые ср-ва (асинхронный IO), которые были разработаны в нейтиве.
Не путай HTTP-сервер и HTTP-протокол.
на джаве обычно есть pure-java реализация стандартными средствами и нативные модули для работы со специфичными под конкретную систему нативными имплементациями, если есть что-то специфичное, конечно.

V>>>·>"Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. " — ты всё ещё уверен, что дизраптор так и делает? Повторяю, с дизраптором объекты не генерятся, а переиспользуются преаллоцированные.
V>Торопишься. Не думаешь.
V>

V>Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди

V>Тут стоило помедитировать. Это СТАНДАРТНЫЙ подход. Это, блин, сверх-мега-стандартный подход для таких вещей. Это база, уровень 0. ))
Где в дизрапторе происходит генерация объектов? Что ты вообще назвал генерацией объектов?

V>Две встречные очереди образуют "кольцо". Эдакие чётки, как у попа, только вместо пальцев правой и левой руки у нас производитель и потребитель. Один берет из пула объект, подготавливает его и пихает "туда". Другой обрабатывает и пихает "обратно".
Что-то какое-то странное представление. Обычная очередь, одна, как в ларёк за пивом. Очереди образуют кольцо?.. Брр. Как-то всё переусложнено.

V>Чем ring-buffer отличается от двух встречных очередей? Да ничем, кроме того, что реализован не на связанном одностороннем списке объектов, а через прибитый к реализации массив фиксированного размера, что считается самой худшей схемой из всех известных. )) Ну, кроме случая, где генерирование и потребление происходит заведомо с одинаковой скоростью,
Нет, когда потребление в среднем не медленнее продьюсинга. Т.е. буфер не переполняется (хотя в пики может расти в глубину).

V>как при воспроизведении аудио, например. Более того, запись и чтение из кольцевого буфера на один CAS дороже, чем в стандартной схеме межпотокового буфера. Ну и, самое главное, часто мы имеем обращение к одной и той же линейке кеша из разных потоков (ядер) в такой схеме, что до 6 раз (в среднем) тормозит любую межпоточность. Ладно аудио, там десятки-сотня пакетов в секунду от силы, но для HFT это смерть. ))
Там в одну линейку _пишут_ только продьюсеры, консьюмеры только читают. В приведённом тобой тесте было три продьюсера. Тут уже мало что можно сделать иначе. В случае одного продьюсера дизраптор действительно раскочегаривается по полной.
Собственно это как раз одно из преимуществ дизраптора, что он дружелюбен к железу, учитывает все эти кеши и прочие нумы.

V>>>Это и есть дисраптор. Это его базовый Lego-кубик (один из 3-х, вернее, с идентичным интерфейсом).
V>·>А доказать?
V>Я всё доказал, пояснив общее устройство такой схемы (две встречных очереди).
Я не понимаю почему ты это называешь двумя очередями. В тесте на который ты привёл — очередь одна. В один конец происходит добавление, с другого конца забирают. Никакого "возвращения" нет.

V>Какие еще нужны доказательства?
Что в приведённом тобой тесте используется дизраптор.

V>Я, конечно, могу ошибаться, но мне кажется, что тебя сбивает с толку именно ring buffer. Он в этой схеме вообще не причем, но кажется тебе главной деталью.
Конечно главная деталь. Потому что это не очередь. По ринг-буферу могут ползать сразу несколько потребителей. И их можно огораживать барьерами — потребители C и D могут отработать только после того, как отработали предыдущие A и B (притом не важно — в каком порядке — A/B или B/A). Вот тут с картиночками: http://martinfowler.com/articles/lmax.html
Т.е. этот один единственный паттерн позволяет реализовывать довольно сложное взаимодействие между множествами тредов просто складывая их как кубики.

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

V>По последнему. Без ring buffer можно организовать НЕСКОЛЬКО веток consumer-producer с ОДНИМ всего пулом у каждого producer и хорошим автоматическим load balancing, в то время как в случае кольцевого буфера у нас пул объектов привязан к конкретной ПАРЕ consumer-producer, а не к именно producer (ведь пул нужен именно ему).
Нет, RTFM.
Вот скажем 2 продьюсера делают балансинг на 2 консьюмера https://github.com/LMAX-Exchange/disruptor/blob/master/src/perftest/java/com/lmax/disruptor/workhandler/TwoToTwoWorkProcessorThroughputTest.java

V>>>Стандартный цикл обращения объектов через межпоточный буфер и обратно в "пул" реализованы как две встречных очереди, ссылку на тест которой (очереди) я тебе дал.
V>·>Бред. Ты дал ссылку на тест, который реализует three producers -> one consumer используя стандартный BlockingQueue.

V>Кинь мне плиз мою ссылку.
https://github.com/LMAX-Exchange/disruptor/blob/master/src/perftest/java/com/lmax/disruptor/queue/ThreeToOneQueueThroughputTest.java

V>Да, я теперь внимательно посмотрел исходник и охренел.
Хоть посмотрел, и на том спасибо.

V>Писали нубы, нихрена не соображающие в устройстве современных систем. ))
Голословно.