Сообщение Re[57]: dotnet vs java 2016-2020 от 24.10.2016 8:47
Изменено 24.10.2016 8:48 vdimas
Здравствуйте, ·, Вы писали:
V>>·>Ну зачем врать-то нак нагло? Твоя цитата? "Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. "
V>>Да, отправляет в другой поток.
·>Опять юлишь, изворачиваешься.
это ты тормозишь уже десятки постов
·>
Действительно!
·>Откуда в дисрапторе "сотни миллионов объектов на освобождение"?
А при чем тут та цитата и дисраптор, если в той ветке мы обсуждали GC?
V>>тут я неточно выразился, много-один покрывает так же один-один, ес-но.
·>Правда по производительности они отличаются.
Нет. Реализация идентична.
V>>про реализацию на простейшем lock-free контейнере уже писал.
·>Дай ссылку на нормальное описание. У тебя со священниками двух двунаправленных очередей что-то не очень получилось описать.
Описать у меня получилось. Это у тебя не получилось осмыслить. ))
Если в голове представить тяжело, то что помешало нарисовать на листике большую окружность (ring-buffer), на этой окружности нарисовать кружочки поменьше (элементы буфера), отметить произвольные два из них (желательно не соседние) стрелками с подписями W и R, нарисовать вдоль большой окружности стрелку в произвольном направлении вращения, обозначающую направления движения курсоров W и R и увидеть, что по направлению движения от W до R у нас будет очередь свободных ячеек, а от R до W — очередь ячеек с данными, итого две встречных очереди от W до R.
Опять рука-лицо, заметь.
Собственно, сама схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть, по следующим причинам:
— этот буфер обычно растёт только в сторону увеличения;
— наличие операции вынужденого роста буфера делает запись в такую очередь вдвое дороже;
— если операции увеличения буфера нет, то у получаем блокировку на стороне записи в пиковые моменты и можем просрать пакеты UDP, скажем;
— для целей переиспользования памяти выгодней брать те её линейки, что есть уже в кеше, т.е. наиболее выгодным устройством пула объектов является структура с характеристикой LIFO, но не в коем случае не LIFO.
— м/у чтением объекта из очереди и смещением курсора чтения еще "что-то дорогостоящее" происходит, как минимум interlocked exchange для замены объекта из ячейки "пустым" экземпляром, если мы не перекачиваем данные прямо в области памяти кольцевого буфера.
— если же по кольцевому буферу (по его области памяти) передавать непосредственно данные, то происходящее будет резко тормозиться схемой поддержки когерентности линеек кешей для разных ядер проца, ведь операция доступа к одной и той же линейке кеша из двух потоков будет самой популярной при этом сценарии.
V>>ордербук один на инструмент, т.е. на один инструмент не надо кучи потоков.
V>>самих инструментов сотни/тысячи
·>Это ты о equities, там да попроще, и таких жестких требований нет.
Пофиг на вид инструмента от слова совсем.
V>>данные так не идут, они идут по непересекающимся рынкам/разделам, там негде взяться общей очереди много-ко-многим
·>Это относительно простой сценарий. В случае же FX инструментов не так много
Это вы не на тех биржах обитаете.
·>притом прут масс-ордера по нескольким ордербукам одновременно, да и >90% трафика прёт в один-единственный EUR/USD ордербук.
По единичной позиции EUR/USD никогда не генерится более 30-40 тыс матчей в секунду. Для HFT это не нагрузка, а холостой ход.
Если у вас эти цифры составляют 90% трафика, то ты НЕ знаешь, что такое HFT.
V>>·>"много-много" это не единственная схема реализуемая на дизрапторе. "один-один" тоже реализуется.
V>>ну конечно, достаточно писать одним потоком и читать одним потоком, только для этого сценария не нужен двухстадийный CAS с той самой большой вероятностью отатов
·>Где ты нашел двустадийный CAS?
В схеме ring-buffer.
V>>да и вообще, в контексте было обсуждение процесса перекачки данных, а не обработки, поэтому речь шла о балансе ресурсов для такой перекачки
·>Так говори сразу словами, а не телепатируй.
·>Почему это работает лучше? Есть какие-нибудь тесты в паблике?
Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов.
V>>в случае многие-ко-многим балансировка выполняется, считай, на каждое сообщение, а нам все-равно один конкретный ордер-бук надо из одного потока обрабатывать, поэтому выгодней балансировать редко и целыми инструментами или рынками.
·>К чему ты это? Разные задачи — разные решения. Ты хочешь сказать, не бывает задач, требующих такой балансировки?
Бывает, конечно. Когда стоимость обработки сообщения (задачи) на многие порядки превышает стоимость обслуживания межпоточной очереди, то да, имеет смысл балансить буквально каждую задачу. Но! даже при таком подходе есть разные алгоритмы наиболее дешевого баланса. Самый популярный на сегодня — это алгоритм work stealing. Очевидно, что твой дисраптор никакого алгоритма шедуллинга не выполняет вообще для сценария многие-ко-многим, реализую заведомо наихудшую (дефолтную) стратегию из всех известных на сегодня.
·>Как я понимаю, хоть каких-либо подтверждений слов я так и не дождусь, товарищ фантазёр..
Подтверждения я тебе уже приводил.
А сейчас своим хамством ты банально выпрашиваешь исходник на блюдечке с голубой каёмочкой.
И зачем тогда ТЫ, как программист, нужен в области программирования HFT, если ты после всего разжёванного даже не состоянии проглотить и породить такой исходник сам? Вот какая от тебя там польза, если ты НАСТОЛЬКО далёк от темы управления ресурсами современного железа?
Причём, у тебя беда не в том, что ты прямо сейчас инфой не владеешь, это как раз излечимо при желании, упорстве и хорошо работающей голове. Беда у тебя в самом целеполагании — тебе это всё НЕ интересно. Но ведь невозможно быть профи в том, что неинтересно, верно?
V>>·>Ну зачем врать-то нак нагло? Твоя цитата? "Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. "
V>>Да, отправляет в другой поток.
·>Опять юлишь, изворачиваешься.
это ты тормозишь уже десятки постов
·>
·>Что же такое "генерация объектов"?Если памяти каюк и сотни миллионов объектов на освобождение, то деваться некуда.
·>Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток.
Действительно!
·>Откуда в дисрапторе "сотни миллионов объектов на освобождение"?
А при чем тут та цитата и дисраптор, если в той ветке мы обсуждали GC?
V>>тут я неточно выразился, много-один покрывает так же один-один, ес-но.
·>Правда по производительности они отличаются.
Нет. Реализация идентична.
V>>про реализацию на простейшем lock-free контейнере уже писал.
·>Дай ссылку на нормальное описание. У тебя со священниками двух двунаправленных очередей что-то не очень получилось описать.
Описать у меня получилось. Это у тебя не получилось осмыслить. ))
Если в голове представить тяжело, то что помешало нарисовать на листике большую окружность (ring-buffer), на этой окружности нарисовать кружочки поменьше (элементы буфера), отметить произвольные два из них (желательно не соседние) стрелками с подписями W и R, нарисовать вдоль большой окружности стрелку в произвольном направлении вращения, обозначающую направления движения курсоров W и R и увидеть, что по направлению движения от W до R у нас будет очередь свободных ячеек, а от R до W — очередь ячеек с данными, итого две встречных очереди от W до R.
Опять рука-лицо, заметь.
Собственно, сама схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть, по следующим причинам:
— этот буфер обычно растёт только в сторону увеличения;
— наличие операции вынужденого роста буфера делает запись в такую очередь вдвое дороже;
— если операции увеличения буфера нет, то у получаем блокировку на стороне записи в пиковые моменты и можем просрать пакеты UDP, скажем;
— для целей переиспользования памяти выгодней брать те её линейки, что есть уже в кеше, т.е. наиболее выгодным устройством пула объектов является структура с характеристикой LIFO, но не в коем случае не LIFO.
— м/у чтением объекта из очереди и смещением курсора чтения еще "что-то дорогостоящее" происходит, как минимум interlocked exchange для замены объекта из ячейки "пустым" экземпляром, если мы не перекачиваем данные прямо в области памяти кольцевого буфера.
— если же по кольцевому буферу (по его области памяти) передавать непосредственно данные, то происходящее будет резко тормозиться схемой поддержки когерентности линеек кешей для разных ядер проца, ведь операция доступа к одной и той же линейке кеша из двух потоков будет самой популярной при этом сценарии.
V>>ордербук один на инструмент, т.е. на один инструмент не надо кучи потоков.
V>>самих инструментов сотни/тысячи
·>Это ты о equities, там да попроще, и таких жестких требований нет.
Пофиг на вид инструмента от слова совсем.
V>>данные так не идут, они идут по непересекающимся рынкам/разделам, там негде взяться общей очереди много-ко-многим
·>Это относительно простой сценарий. В случае же FX инструментов не так много
Это вы не на тех биржах обитаете.
·>притом прут масс-ордера по нескольким ордербукам одновременно, да и >90% трафика прёт в один-единственный EUR/USD ордербук.
По единичной позиции EUR/USD никогда не генерится более 30-40 тыс матчей в секунду. Для HFT это не нагрузка, а холостой ход.
Если у вас эти цифры составляют 90% трафика, то ты НЕ знаешь, что такое HFT.
V>>·>"много-много" это не единственная схема реализуемая на дизрапторе. "один-один" тоже реализуется.
V>>ну конечно, достаточно писать одним потоком и читать одним потоком, только для этого сценария не нужен двухстадийный CAS с той самой большой вероятностью отатов
·>Где ты нашел двустадийный CAS?
В схеме ring-buffer.
V>>да и вообще, в контексте было обсуждение процесса перекачки данных, а не обработки, поэтому речь шла о балансе ресурсов для такой перекачки
·>Так говори сразу словами, а не телепатируй.
·>Почему это работает лучше? Есть какие-нибудь тесты в паблике?
Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов.
V>>в случае многие-ко-многим балансировка выполняется, считай, на каждое сообщение, а нам все-равно один конкретный ордер-бук надо из одного потока обрабатывать, поэтому выгодней балансировать редко и целыми инструментами или рынками.
·>К чему ты это? Разные задачи — разные решения. Ты хочешь сказать, не бывает задач, требующих такой балансировки?
Бывает, конечно. Когда стоимость обработки сообщения (задачи) на многие порядки превышает стоимость обслуживания межпоточной очереди, то да, имеет смысл балансить буквально каждую задачу. Но! даже при таком подходе есть разные алгоритмы наиболее дешевого баланса. Самый популярный на сегодня — это алгоритм work stealing. Очевидно, что твой дисраптор никакого алгоритма шедуллинга не выполняет вообще для сценария многие-ко-многим, реализую заведомо наихудшую (дефолтную) стратегию из всех известных на сегодня.
·>Как я понимаю, хоть каких-либо подтверждений слов я так и не дождусь, товарищ фантазёр..
Подтверждения я тебе уже приводил.
А сейчас своим хамством ты банально выпрашиваешь исходник на блюдечке с голубой каёмочкой.
И зачем тогда ТЫ, как программист, нужен в области программирования HFT, если ты после всего разжёванного даже не состоянии проглотить и породить такой исходник сам? Вот какая от тебя там польза, если ты НАСТОЛЬКО далёк от темы управления ресурсами современного железа?
Причём, у тебя беда не в том, что ты прямо сейчас инфой не владеешь, это как раз излечимо при желании, упорстве и хорошо работающей голове. Беда у тебя в самом целеполагании — тебе это всё НЕ интересно. Но ведь невозможно быть профи в том, что неинтересно, верно?
Здравствуйте, ·, Вы писали:
V>>·>Ну зачем врать-то нак нагло? Твоя цитата? "Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. "
V>>Да, отправляет в другой поток.
·>Опять юлишь, изворачиваешься.
это ты тормозишь уже десятки постов
·>
Действительно!
·>Откуда в дисрапторе "сотни миллионов объектов на освобождение"?
А при чем тут та цитата и дисраптор, если в той ветке мы обсуждали GC?
V>>тут я неточно выразился, много-один покрывает так же один-один, ес-но.
·>Правда по производительности они отличаются.
Нет. Реализация идентична.
V>>про реализацию на простейшем lock-free контейнере уже писал.
·>Дай ссылку на нормальное описание. У тебя со священниками двух двунаправленных очередей что-то не очень получилось описать.
Описать у меня получилось. Это у тебя не получилось осмыслить. ))
Если в голове представить тяжело, то что помешало нарисовать на листике большую окружность (ring-buffer), на этой окружности нарисовать кружочки поменьше (элементы буфера), отметить произвольные два из них (желательно не соседние) стрелками с подписями W и R, нарисовать вдоль большой окружности стрелку в произвольном направлении вращения, обозначающую направления движения курсоров W и R и увидеть, что по направлению движения от W до R у нас будет очередь свободных ячеек, а от R до W — очередь ячеек с данными, итого две встречных очереди: от W до R и обратно.
Опять рука-лицо, заметь.
Собственно, сама схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть, по следующим причинам:
— этот буфер обычно растёт только в сторону увеличения;
— наличие операции вынужденого роста буфера делает запись в такую очередь вдвое дороже;
— если операции увеличения буфера нет, то у получаем блокировку на стороне записи в пиковые моменты и можем просрать пакеты UDP, скажем;
— для целей переиспользования памяти выгодней брать те её линейки, что есть уже в кеше, т.е. наиболее выгодным устройством пула объектов является структура с характеристикой LIFO, но не в коем случае не LIFO.
— м/у чтением объекта из очереди и смещением курсора чтения еще "что-то дорогостоящее" происходит, как минимум interlocked exchange для замены объекта из ячейки "пустым" экземпляром, если мы не перекачиваем данные прямо в области памяти кольцевого буфера.
— если же по кольцевому буферу (по его области памяти) передавать непосредственно данные, то происходящее будет резко тормозиться схемой поддержки когерентности линеек кешей для разных ядер проца, ведь операция доступа к одной и той же линейке кеша из двух потоков будет самой популярной при этом сценарии.
V>>ордербук один на инструмент, т.е. на один инструмент не надо кучи потоков.
V>>самих инструментов сотни/тысячи
·>Это ты о equities, там да попроще, и таких жестких требований нет.
Пофиг на вид инструмента от слова совсем.
V>>данные так не идут, они идут по непересекающимся рынкам/разделам, там негде взяться общей очереди много-ко-многим
·>Это относительно простой сценарий. В случае же FX инструментов не так много
Это вы не на тех биржах обитаете.
·>притом прут масс-ордера по нескольким ордербукам одновременно, да и >90% трафика прёт в один-единственный EUR/USD ордербук.
По единичной позиции EUR/USD никогда не генерится более 30-40 тыс матчей в секунду. Для HFT это не нагрузка, а холостой ход.
Если у вас эти цифры составляют 90% трафика, то ты НЕ знаешь, что такое HFT.
V>>·>"много-много" это не единственная схема реализуемая на дизрапторе. "один-один" тоже реализуется.
V>>ну конечно, достаточно писать одним потоком и читать одним потоком, только для этого сценария не нужен двухстадийный CAS с той самой большой вероятностью отатов
·>Где ты нашел двустадийный CAS?
В схеме ring-buffer.
V>>да и вообще, в контексте было обсуждение процесса перекачки данных, а не обработки, поэтому речь шла о балансе ресурсов для такой перекачки
·>Так говори сразу словами, а не телепатируй.
·>Почему это работает лучше? Есть какие-нибудь тесты в паблике?
Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов.
V>>в случае многие-ко-многим балансировка выполняется, считай, на каждое сообщение, а нам все-равно один конкретный ордер-бук надо из одного потока обрабатывать, поэтому выгодней балансировать редко и целыми инструментами или рынками.
·>К чему ты это? Разные задачи — разные решения. Ты хочешь сказать, не бывает задач, требующих такой балансировки?
Бывает, конечно. Когда стоимость обработки сообщения (задачи) на многие порядки превышает стоимость обслуживания межпоточной очереди, то да, имеет смысл балансить буквально каждую задачу. Но! даже при таком подходе есть разные алгоритмы наиболее дешевого баланса. Самый популярный на сегодня — это алгоритм work stealing. Очевидно, что твой дисраптор никакого алгоритма шедуллинга не выполняет вообще для сценария многие-ко-многим, реализую заведомо наихудшую (дефолтную) стратегию из всех известных на сегодня.
·>Как я понимаю, хоть каких-либо подтверждений слов я так и не дождусь, товарищ фантазёр..
Подтверждения я тебе уже приводил.
А сейчас своим хамством ты банально выпрашиваешь исходник на блюдечке с голубой каёмочкой.
И зачем тогда ТЫ, как программист, нужен в области программирования HFT, если ты после всего разжёванного даже не состоянии проглотить и породить такой исходник сам? Вот какая от тебя там польза, если ты НАСТОЛЬКО далёк от темы управления ресурсами современного железа?
Причём, у тебя беда не в том, что ты прямо сейчас инфой не владеешь, это как раз излечимо при желании, упорстве и хорошо работающей голове. Беда у тебя в самом целеполагании — тебе это всё НЕ интересно. Но ведь невозможно быть профи в том, что неинтересно, верно?
V>>·>Ну зачем врать-то нак нагло? Твоя цитата? "Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. Дык, Disruptor именно это и делает. "
V>>Да, отправляет в другой поток.
·>Опять юлишь, изворачиваешься.
это ты тормозишь уже десятки постов
·>
·>Что же такое "генерация объектов"?Если памяти каюк и сотни миллионов объектов на освобождение, то деваться некуда.
·>Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток.
Действительно!
·>Откуда в дисрапторе "сотни миллионов объектов на освобождение"?
А при чем тут та цитата и дисраптор, если в той ветке мы обсуждали GC?
V>>тут я неточно выразился, много-один покрывает так же один-один, ес-но.
·>Правда по производительности они отличаются.
Нет. Реализация идентична.
V>>про реализацию на простейшем lock-free контейнере уже писал.
·>Дай ссылку на нормальное описание. У тебя со священниками двух двунаправленных очередей что-то не очень получилось описать.
Описать у меня получилось. Это у тебя не получилось осмыслить. ))
Если в голове представить тяжело, то что помешало нарисовать на листике большую окружность (ring-buffer), на этой окружности нарисовать кружочки поменьше (элементы буфера), отметить произвольные два из них (желательно не соседние) стрелками с подписями W и R, нарисовать вдоль большой окружности стрелку в произвольном направлении вращения, обозначающую направления движения курсоров W и R и увидеть, что по направлению движения от W до R у нас будет очередь свободных ячеек, а от R до W — очередь ячеек с данными, итого две встречных очереди: от W до R и обратно.
Опять рука-лицо, заметь.
Собственно, сама схема из двух очередей для такого сценария — это классика жанра. А вот реализация на кольцевом буфере — нубство как есть, по следующим причинам:
— этот буфер обычно растёт только в сторону увеличения;
— наличие операции вынужденого роста буфера делает запись в такую очередь вдвое дороже;
— если операции увеличения буфера нет, то у получаем блокировку на стороне записи в пиковые моменты и можем просрать пакеты UDP, скажем;
— для целей переиспользования памяти выгодней брать те её линейки, что есть уже в кеше, т.е. наиболее выгодным устройством пула объектов является структура с характеристикой LIFO, но не в коем случае не LIFO.
— м/у чтением объекта из очереди и смещением курсора чтения еще "что-то дорогостоящее" происходит, как минимум interlocked exchange для замены объекта из ячейки "пустым" экземпляром, если мы не перекачиваем данные прямо в области памяти кольцевого буфера.
— если же по кольцевому буферу (по его области памяти) передавать непосредственно данные, то происходящее будет резко тормозиться схемой поддержки когерентности линеек кешей для разных ядер проца, ведь операция доступа к одной и той же линейке кеша из двух потоков будет самой популярной при этом сценарии.
V>>ордербук один на инструмент, т.е. на один инструмент не надо кучи потоков.
V>>самих инструментов сотни/тысячи
·>Это ты о equities, там да попроще, и таких жестких требований нет.
Пофиг на вид инструмента от слова совсем.
V>>данные так не идут, они идут по непересекающимся рынкам/разделам, там негде взяться общей очереди много-ко-многим
·>Это относительно простой сценарий. В случае же FX инструментов не так много
Это вы не на тех биржах обитаете.
·>притом прут масс-ордера по нескольким ордербукам одновременно, да и >90% трафика прёт в один-единственный EUR/USD ордербук.
По единичной позиции EUR/USD никогда не генерится более 30-40 тыс матчей в секунду. Для HFT это не нагрузка, а холостой ход.
Если у вас эти цифры составляют 90% трафика, то ты НЕ знаешь, что такое HFT.
V>>·>"много-много" это не единственная схема реализуемая на дизрапторе. "один-один" тоже реализуется.
V>>ну конечно, достаточно писать одним потоком и читать одним потоком, только для этого сценария не нужен двухстадийный CAS с той самой большой вероятностью отатов
·>Где ты нашел двустадийный CAS?
В схеме ring-buffer.
V>>да и вообще, в контексте было обсуждение процесса перекачки данных, а не обработки, поэтому речь шла о балансе ресурсов для такой перекачки
·>Так говори сразу словами, а не телепатируй.
·>Почему это работает лучше? Есть какие-нибудь тесты в паблике?
Результаты тестов я тебе давал. Цифры в полтора-два раза лучше других топов.
V>>в случае многие-ко-многим балансировка выполняется, считай, на каждое сообщение, а нам все-равно один конкретный ордер-бук надо из одного потока обрабатывать, поэтому выгодней балансировать редко и целыми инструментами или рынками.
·>К чему ты это? Разные задачи — разные решения. Ты хочешь сказать, не бывает задач, требующих такой балансировки?
Бывает, конечно. Когда стоимость обработки сообщения (задачи) на многие порядки превышает стоимость обслуживания межпоточной очереди, то да, имеет смысл балансить буквально каждую задачу. Но! даже при таком подходе есть разные алгоритмы наиболее дешевого баланса. Самый популярный на сегодня — это алгоритм work stealing. Очевидно, что твой дисраптор никакого алгоритма шедуллинга не выполняет вообще для сценария многие-ко-многим, реализую заведомо наихудшую (дефолтную) стратегию из всех известных на сегодня.
·>Как я понимаю, хоть каких-либо подтверждений слов я так и не дождусь, товарищ фантазёр..
Подтверждения я тебе уже приводил.
А сейчас своим хамством ты банально выпрашиваешь исходник на блюдечке с голубой каёмочкой.
И зачем тогда ТЫ, как программист, нужен в области программирования HFT, если ты после всего разжёванного даже не состоянии проглотить и породить такой исходник сам? Вот какая от тебя там польза, если ты НАСТОЛЬКО далёк от темы управления ресурсами современного железа?
Причём, у тебя беда не в том, что ты прямо сейчас инфой не владеешь, это как раз излечимо при желании, упорстве и хорошо работающей голове. Беда у тебя в самом целеполагании — тебе это всё НЕ интересно. Но ведь невозможно быть профи в том, что неинтересно, верно?