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

V>·>LL-тред не блокируется, тем более на IO, он крутит busy spin пока отсутствуют данные во входящем сетевом буфере. Да, процессор жжот.

V>На серверной стороне это невозможно в принципе. Вот у тебя тысяча клиентов висит, а ядер всего 32. Твои действия?
А сетевых карт сколько? Одна, правильно? Сколько значит сетевых буферов?
Да и тысячу клиентов можно по дюжине шлюзов разбалансить.

Заказы всё равно надо последовательно обрабатывать, правила биржи такие.

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

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

S>>·>А из-за чего?
S>>·>Кстати, это тоже камень в огород c#. Диагностика таких вот тонких проблем очень проблематична. Сложно (если вообще возможно) докопаться до причины тормозов.
S>> Это свойство Windows. Есть еще куча сервисов и приложений.
·>Угу, с этим тоже борются, ещё один камень в огород c# — он win-only, а в винде тоже всё плохо с LL. Я приводил ссылочку на ютуб с подробным рассказом — как борются в линухе. Вот исходники https://github.com/epickrram/perf-workshop Покажи как бы ты боролся с этим же в виндах и каких бы показателей смог достичь.
Есть кроссплатформенный .Net Core и .Net Native
·>В общем, если у тебя есть другие тесты, дающие другие результаты — давай показывай. А пока ты просто пустословно споришь против статьи, и даже не с её автором.

Ну во первых ты привел тест без сравнения с Java.
Во вторых

 // Use 80K, If we are > 85,000 bytes = LOH and we don't want these there
    var bytes = new byte[80 * 1024]; 
    random.NextBytes(bytes);
    bytesCache.Set(bytes.GetHashCode(), bytes);

Then to ensure that the objects are kept around long enough, they are both put into a Least Recently Used (LRU) cache, that holds the 2000 most recent items.

Размер кэша 2000*80*1024 = 163 мб.
Я уж не знаю какая там скорость памяти, но для дефрагментации памяти явно это больше 4 мс потребуется.
При этом кэш постоянном обновляется ибо очень мала вероятность получить одинаковые массивы.
При таком подходе проще сериализовать данные и записывать в Redis или другие NoSQL базы.

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

V>Мы на разных языках разговариваем. У нас представление FIX-сообщения в памяти и сетке идентично, т.е. мы тупо пихаем тело сообщения в сетку и точно так же принятый блоб без изменений хранится в памяти, просто будет размечен индексами при парсинге. Для джавы такой подход — недостижимый хайтек,

Хм, этот "недостижимый хайтек" как раз напрямую используется нашим Java софтом
Видимо, авторы не знали, что vdimas запретил им это использовать

V>Поверь, качественная перекачка данных из потока в поток — это ноу-хау каждой конторы, которая делает подобного рода решения — обработку сумасшедших потоков данных в реалтайме. Хорошо оттюненный конвейер data-flow перемалывает в секунду до миллиона ордеров на каждой паре системных потоков. Для джавы это всё недостижимо, ес-но.

Соседний отдел уже смеётся, "недостижимо", ага

V>>>С байт-буфером будет сериализация-десериализация на каждый чих.
V>·>Данные обычно плоские и фиксированной ширины. Просто обращаешься по фиксированным смещениям, сериализация тривиальна и быстра.
V>Ну вот, ты опять показал невладение темой. Что происходит в железе, если мы читаем, например, невыровненное 32-хразрядное слово в 32-хразрядной архитектуре? (или 64 в 64 аналогично?) Так вот, происходит прерывание "ошибка адресации", где обработчик прерывания сначала разбирается,

На x86? В режиме по умолчанию? На словах родного размера?

V>Понимаешь, область HFT — это область малого кол-ва сложных задач, по-сути. А управляемые среды, наоборот, хорошо себя показывают в реализации систем, где решается огромное кол-во простых, т.е. в системах с большой суммарной информационной сложностью. HFT явно находится не в этой области.

Чорд, и как это оно работает

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

V>>·>LL-тред не блокируется, тем более на IO, он крутит busy spin пока отсутствуют данные во входящем сетевом буфере. Да, процессор жжот.
V>>На серверной стороне это невозможно в принципе. Вот у тебя тысяча клиентов висит, а ядер всего 32. Твои действия?
·>А сетевых карт сколько? Одна, правильно? Сколько значит сетевых буферов?

Сетевых буферов сколько угодно.
Тут такая херня, что IP-протоколы как раз ругают за канальный уровень внутри канального уровня (того же Ethernet).
Но это к делу не относится, инфа по принципам работы ethernet-карточек открыта, можно на досуге взглянуть.


·>Да и тысячу клиентов можно по дюжине шлюзов разбалансить.

Т.е., передать инфу на другое ядро внутри одной системы нельзя, а на другой шлюз можно?


·>Заказы всё равно надо последовательно обрабатывать, правила биржи такие.

Это ты уже вилять изволишь.
Ну ОК, твоё мнение понятно, но оно курьёзное и я бы тебе посоветовал ВНИМАТЕЛЬНО пройтись по этой теме, чтобы не рожать курьёзы в будущем.

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

S>>> Это свойство Windows. Есть еще куча сервисов и приложений.
S>·>Угу, с этим тоже борются, ещё один камень в огород c# — он win-only, а в винде тоже всё плохо с LL. Я приводил ссылочку на ютуб с подробным рассказом — как борются в линухе. Вот исходники https://github.com/epickrram/perf-workshop Покажи как бы ты боролся с этим же в виндах и каких бы показателей смог достичь.
S> Есть кроссплатформенный .Net Core и .Net Native
Они разве уже "есть"? Пока вроде просто публичные preview билды. Когда зарелизить обещают?

S>·>В общем, если у тебя есть другие тесты, дающие другие результаты — давай показывай. А пока ты просто пустословно споришь против статьи, и даже не с её автором.
S> Ну во первых ты привел тест без сравнения с Java.
Что уж есть. Как работает zing я видел. Пауз — нет. Он специально задизайнен как pauseless.
Если есть другие тесты — в студию. Но лучшей производительности и сам ms не обещает.

В общем, как что-то появится, тогда приходите. А пока это только фантазии.

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

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

Ф>>>>Почти не зависит: чтобы это было возможно, нужно чтобы СУБД все свои действия сразу писала на диск. А на практике оно чаще всего откладывает запись (доступ к диску так оптимизируют)
C>>>ЩИТО?
I>>Где, по твоему, БД хранит буфер транзакций и в какой момент она его сбрасывает на диск ?

EP>Знаешь что означает D в ACID?

Во первых, вопрос задвался не тебе
Во вторых, раз уж влазишь, научись на прямой вопрос отвечать прямо

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

Ф>>>>А во-вторых часть данных может писаться не в БД, а в файлы, которые лежат рядом...
C>>>А это не проблема БД.
I>>Спасибо, капитан. Это проблема юзера — старые файлы повреждены, новых нет. Что делать ?
C>Использовать CoW-системы, которые не меняют данные в старой версии. Например, BTRFS.

Правильно. И давно на макоси CoW поддерживается ?

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

I>>Несколько лет назад ты на каждом углу регулярно рассказывал сказки ".Net GC ложится навзничь."
V>Я и сейчас так утверждаю, что для многих задач ложится, и?

Я привел твою цитату про задачу "Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток"
Ты определись, а то скучно читать — задача то одна, а результаты зависят от того, с кем ты спорить взялся

I>>На счет вечно без пауз — это заблуждение. Есть у него предел частоты инстанцирований, выше которого Gen0 начинает пухнуть до безобразия, в пересчете на _гигабайты_

V>Не создавай много потоков.

Один поток это много ? А ты, в ударе.

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

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

V>>>·>LL-тред не блокируется, тем более на IO, он крутит busy spin пока отсутствуют данные во входящем сетевом буфере. Да, процессор жжот.
V>>>На серверной стороне это невозможно в принципе. Вот у тебя тысяча клиентов висит, а ядер всего 32. Твои действия?
V>·>А сетевых карт сколько? Одна, правильно? Сколько значит сетевых буферов?
V>Сетевых буферов сколько угодно.
V>Тут такая херня, что IP-протоколы как раз ругают за канальный уровень внутри канального уровня (того же Ethernet).
V>Но это к делу не относится, инфа по принципам работы ethernet-карточек открыта, можно на досуге взглянуть.
Пикапить можно трафик (pcap).

V>·>Да и тысячу клиентов можно по дюжине шлюзов разбалансить.
V>Т.е., передать инфу на другое ядро внутри одной системы нельзя, а на другой шлюз можно?
Я рассказываю о своём опыте. Бывают разные клиенты. Так называемые market makers — их немного, десятки (top investment banks) — для них LL — самое важное. У них персональные шлюзы и прочие железки.
Остальные брокеры — для них можно и IO подождать, но от них, как правило, и трафика меньше.
А ещё можно тонко настраивать операционку, чтобы она хорошо себя вела

V>·>Заказы всё равно надо последовательно обрабатывать, правила биржи такие.
V>Это ты уже вилять изволишь.
V>Ну ОК, твоё мнение понятно, но оно курьёзное и я бы тебе посоветовал ВНИМАТЕЛЬНО пройтись по этой теме, чтобы не рожать курьёзы в будущем.
Я рассказал о работе EV. Он _обязан_ обрабатывать все ордера в порядке очереди. Это, кстати, отличительная особенность биржи от веб-сервера. Веб-сервер получает 100500 запросов и может каждый обработать параллельно и практически независимо. На бирже 90% трафика ломится в один единственный EUR/USD биржевой стакан.
Соответственно эти FIX-шлюзы смотрят во внешний мир и перекладывают запросы от клиентов в один поток ордеров, который потом строго последовательно обрабатывается LL-ядром.

Кстати, я почитал твои ссылки с графиками. Не понял что именно ты хотел доказать. Это что-ли?
The Java based FIX engine closely matched the native C++ code
Вполне ожидаемый результат.
Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать? По-моему, результат отлично доказывающий мою позицию.

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

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

S>>>> Это свойство Windows. Есть еще куча сервисов и приложений.
S>>·>Угу, с этим тоже борются, ещё один камень в огород c# — он win-only, а в винде тоже всё плохо с LL. Я приводил ссылочку на ютуб с подробным рассказом — как борются в линухе. Вот исходники https://github.com/epickrram/perf-workshop Покажи как бы ты боролся с этим же в виндах и каких бы показателей смог достичь.
S>> Есть кроссплатформенный .Net Core и .Net Native
·>Они разве уже "есть"? Пока вроде просто публичные preview билды. Когда зарелизить обещают?
Давно уже.
https://habrahabr.ru/users/serginio1/topics/
S>>·>В общем, если у тебя есть другие тесты, дающие другие результаты — давай показывай. А пока ты просто пустословно споришь против статьи, и даже не с её автором.
Я не спорю показал тебе проблему с дефрагментацией 200 мб
S>> Ну во первых ты привел тест без сравнения с Java.
·>Что уж есть. Как работает zing я видел. Пауз — нет. Он специально задизайнен как pauseless.
·>Если есть другие тесты — в студию. Но лучшей производительности и сам ms не обещает.

·>В общем, как что-то появится, тогда приходите. А пока это только фантазии.
Вот когда покажешь сравнение с Zing тогда это не будет фантазиями. Пока только голословное утверждение.

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

S> При этом кэш постоянном обновляется ибо очень мала вероятность получить одинаковые массивы.
S> При таком подходе проще сериализовать данные и записывать в Redis или другие NoSQL базы.
Или ehcache, или JCS, или OSCache, или Terrastore, или Cassandra или любую другую систему написанную на java.
А потом закопать эту .net-недоплатформу обратно.

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

S>·>Они разве уже "есть"? Пока вроде просто публичные preview билды. Когда зарелизить обещают?
S> Давно уже.
S>https://habrahabr.ru/users/serginio1/topics/
И нибудь уже замерял производительность? Или даже не стоит?

S>·>В общем, как что-то появится, тогда приходите. А пока это только фантазии.
S> Вот когда покажешь сравнение с Zing тогда это не будет фантазиями. Пока только голословное утверждение.
Голословные утверждения у тебя. От тебя я только видел рассуждения о том, что "вы все всё неправильно делаете".
Я видел zing, я собственноручно отправлял им багрепорт, когда мы наблюдали задержки больше 10мс на одном из сервисов. Это был баг и они исправили (ух, крутой баг был, я впечатлился).
У меня сейчас нет доступа к zing и поэтому тесты я провести не могу.
Если ты мне не веришь, не веришь приведённой статье, а так же не хочешь обращать на отстутствие c# LL-систем в мире, то проведи тесты сам — единственный надёжный способ доказать тебе этот факт.

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

·>Кстати, я почитал твои ссылки с графиками. Не понял что именно ты хотел доказать. Это что-ли?
·>The Java based FIX engine closely matched the native C++ code
·>Вполне ожидаемый результат.
·>Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать? По-моему, результат отлично доказывающий мою позицию.

С дотнетом проблема не в производительности, а в том, что это закрытая технология и до недавних пор Windows-only.
Собственно, если надо выжать максимум производительности, то здесь .Net уделает джаву, как тузик грелку. Но мулька в том, что слишком много контор выбирают в первую очередь открытые технологии даже в ущерб производительности.
Это облегает майнтенанс и снижает целую кучу рисков.
Собственно, Микрософт работает над этой проблемой, но мягко говоря, запоздало — это надо было лет 10 назад сделать.

Разница между нейтивом и менеджед кодом, фактически, в эффективности использования кеша процессора, ядер и планирования IO. И если менеджед хорошо справляется с IO и потоками, то с кешем всё очень плохо — менеджед, любой, независимо от природы, перепахивает в основном память.
Для того, что бы лучше использовать кеш, нужна та самая локальность — стек, регистры, value type и тд. В дотнете кучка костылей в наличии. В джаве — практически ничего. Более того, благодаря type erasure джавовские контейнеры мягко говоря не блещут производительностью в менеджед мире. Там где в дотнете будет одна страница памяти благодаря генерикам, в джаве будет граф рандомно разбросаный по памяти.

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

·>Если ты мне не веришь, не веришь приведённой статье, а так же не хочешь обращать на отстутствие c# LL-систем в мире, то проведи тесты сам — единственный надёжный способ доказать тебе этот факт.

LL начинается с железа и операционной системы. .Net прибит гвоздями к Винде. А вот винда, внимание, имеет серьезные проблемы с LL.

Если хочется сравнений, то подожди, когда раскрутится .Net Core. Замеры показывают, что он кроет старый дотнет, как бык овцу, разница почти на порядок.

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

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

S>> При этом кэш постоянном обновляется ибо очень мала вероятность получить одинаковые массивы.
S>> При таком подходе проще сериализовать данные и записывать в Redis или другие NoSQL базы.
·>Или ehcache, или JCS, или OSCache, или Terrastore, или Cassandra или любую другую систему написанную на java.
·>А потом закопать эту .net-недоплатформу обратно.
Да можно такую же БД написать и на Net только какой в этом смысл,
Просто для данной задачи когда данные постоянно обновляются, проще держать данные в БД, что бы не дефрагментировать постоянно по 200 мб

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

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

S>>·>Они разве уже "есть"? Пока вроде просто публичные preview билды. Когда зарелизить обещают?
S>> Давно уже.
S>>https://habrahabr.ru/users/serginio1/topics/
·>И нибудь уже замерял производительность? Или даже не стоит?
Для моих задач производительность не самое главное. Главное это замена COM под Линукс.
S>>·>В общем, как что-то появится, тогда приходите. А пока это только фантазии.
S>> Вот когда покажешь сравнение с Zing тогда это не будет фантазиями. Пока только голословное утверждение.

·>Голословные утверждения у тебя. От тебя я только видел рассуждения о том, что "вы все всё неправильно делаете".
·>Я видел zing, я собственноручно отправлял им багрепорт, когда мы наблюдали задержки больше 10мс на одном из сервисов. Это был баг и они исправили (ух, крутой баг был, я впечатлился).
·>У меня сейчас нет доступа к zing и поэтому тесты я провести не могу.
·>Если ты мне не веришь, не веришь приведённой статье, а так же не хочешь обращать на отстутствие c# LL-систем в мире, то проведи тесты сам — единственный надёжный способ доказать тебе этот факт.

Еще раз на заборе тоже написано. Ты должен и доказывать своё утверждение.

Я верю статье. Но суть то этом примере, что ГС нужно постоянно дефрагментировать по 200 мб. Это не типичная работа для GC. Для этого проще использовать NoSQL или свой аналог.
Например в твоем примере массив byte[] имеет тот же размер. Можно копировать данные в текущий массив. Но вот общая скорость выполнения при этом уменьшится.
Тут уж выбирай, что важно общая скорость или задержки.

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

Ф>>>>>Почти не зависит: чтобы это было возможно, нужно чтобы СУБД все свои действия сразу писала на диск. А на практике оно чаще всего откладывает запись (доступ к диску так оптимизируют)
C>>>>ЩИТО?
I>>>Где, по твоему, БД хранит буфер транзакций и в какой момент она его сбрасывает на диск ?
EP>>Знаешь что означает D в ACID?
I>Во первых, вопрос задвался не тебе

Какая разница? Здесь форум вообще-то

I>Во вторых, раз уж влазишь, научись на прямой вопрос отвечать прямо

Захочу прямо, а захочу сошлюсь на букварь из которого всё следует. Здесь опять-таки форум, а не Q&A

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

I>·>Кстати, я почитал твои ссылки с графиками. Не понял что именно ты хотел доказать. Это что-ли?
I>·>The Java based FIX engine closely matched the native C++ code
I>·>Вполне ожидаемый результат.
I>·>Или что ваша наивная имплементация pure java с развесистыми объектами всего на порядок отстаёт от вылизанного native? А на pure c# вообще никто не осилил fix engine написать? По-моему, результат отлично доказывающий мою позицию.
I>С дотнетом проблема не в производительности, а в том, что это закрытая технология и до недавних пор Windows-only.
А с недавних пор — непонятно зачем это нужно. И предсказываю, что в обозначенных в сабже временных рамках вряд ли что-то значительно поменяется. Ибо "быстрее на 10% в наших тестах" не является киллер-фичей, и вряд ли кто потащит .net в другие ниши, ради лишь "шоб былО".

I>Собственно, если надо выжать максимум производительности, то здесь .Net уделает джаву, как тузик грелку.
Ага, а если учесть это "The Java based FIX engine closely matched the native C++ code", то следует, что .net уделает native как тузик грелку. Хотел бы я на это посмотреть...

I>Но мулька в том, что слишком много контор выбирают в первую очередь открытые технологии даже в ущерб производительности.
Т.е. не существует контор, которым вдруг понадобилась эта хвалёная производительность?

I>Это облегает майнтенанс и снижает целую кучу рисков.
I>Собственно, Микрософт работает над этой проблемой, но мягко говоря, запоздало — это надо было лет 10 назад сделать.
Так поезд уже ушел. Майкрософту надо работать над киллер-фичей. Просто обещания уделывать java как тузик-грелку — киллер-фичей не являются.

I>Разница между нейтивом и менеджед кодом, фактически, в эффективности использования кеша процессора, ядер и планирования IO. И если менеджед хорошо справляется с IO и потоками, то с кешем всё очень плохо — менеджед, любой, независимо от природы, перепахивает в основном память.
Неправда. Конечно, из-за строгости стандартов сделать код на Яве, который будет пахать одинаково эффективно на всех возможных имплементациях JVM на всех платформах от чайников до супер-компьютеров, но запилить под конкретное окружение на конкретном железе можно. Собственно та же ситуация, что и с нейтивом.

I>Для того, что бы лучше использовать кеш, нужна та самая локальность — стек, регистры, value type и тд. В дотнете кучка костылей в наличии. В джаве — практически ничего.
Немного есть. И этого, как показал опыт, хватает.

I> Более того, благодаря type erasure джавовские контейнеры мягко говоря не блещут производительностью в менеджед мире. Там где в дотнете будет одна страница памяти благодаря генерикам, в джаве будет граф рандомно разбросаный по памяти.
type erasure тут не причём. Причём тут только отличие primitive types vs objects. Но есть библиотеки эффективной реализации коллекций для примитивных типов.
А если тебе нужны стек/регистры/память то кроме как ассемблер ничего не поможет, даже в С регистрами жонглировать невозможно.

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

S>·>Или ehcache, или JCS, или OSCache, или Terrastore, или Cassandra или любую другую систему написанную на java.
S>·>А потом закопать эту .net-недоплатформу обратно.
S> Да можно такую же БД написать и на Net только какой в этом смысл,
Можно ли? Есть ли БД написанные на .net? Если нет, то почему?

S> Просто для данной задачи когда данные постоянно обновляются, проще держать данные в БД, что бы не дефрагментировать постоянно по 200 мб
А что значит "держать данные в БД"? БД это не волшебный сундук подаренный инопланетянами, а тоже программа, и тоже написанная на ЯП. Притом есть БД написанные и на C/C++ и на Java, в этих языках почему-то 200мб без проблем дефрагментируются. А вот в .net ВНЕЗАПНО появляются сложности и надо просить помощи у native или java... место проклятое, не иначе.

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

S>·>И нибудь уже замерял производительность? Или даже не стоит?
S> Для моих задач производительность не самое главное. Главное это замена COM под Линукс.
Допустим... ты не измерял. Но неужели никто больше не догадался померить?

S>·>Если ты мне не веришь, не веришь приведённой статье, а так же не хочешь обращать на отстутствие c# LL-систем в мире, то проведи тесты сам — единственный надёжный способ доказать тебе этот факт.
S> Еще раз на заборе тоже написано.
Что написано? "LL c# систем в мире нет", но на самом деле власти скрывают и за забором их даже куры не клюют. Так что-ли?

S>Ты должен и доказывать своё утверждение.
А чем ты доказал свои утверждения? "c# быстрый, т.к. это замена COM под Линукс". Мда. Оригинально.
Себе я доказывать уже не должен, себе я доказал на практике, видел собственными глазами.
Здесь в форуме я тоже не должен, не веришь статьям, не веришь заявлениям azul — твоё дело.

S>Я верю статье. Но суть то этом примере, что ГС нужно постоянно дефрагментировать по 200 мб. Это не типичная работа для GC. Для этого проще использовать NoSQL или свой аналог.
Суть статьи в том, что gc создаёт паузы. Что не допустимо в LL. Суть теста в том, чтобы напрячь gc и убедиться, что с обещанным режимом Sustained Low Latency он и правда работает как Low Latency. Однако это не так.

S> Например в твоем примере массив byte[] имеет тот же размер. Можно копировать данные в текущий массив. Но вот общая скорость выполнения при этом уменьшится.
S>Тут уж выбирай, что важно общая скорость или задержки.
В статье общая скорость и не измеряется, измеряются задерки.