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

KP>Как и ожидалось быстрей всего реализации на Си и Rust, фактически одна и та же скорость. Чуть медленнее, но всё равно достойный результат у Go и C# (правда C# слился из за больших задержек в тесте на 20 Mpps оставив в победителях C, Rust и Go).

Поглядел исходники — шарп используется какой то совсем уж древней версии, ни одной из фишек свежих версий и рантаймов, нацеленных как раз на такие задачи там нет.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А там где в HFT конкуренция на скорость её и не используют

ну почему, используют: LMAX is a new retail financial trading platform. As a result it has to process many trades with low latency. The system is built on the JVM platform and centers on a Business Logic Processor that can handle 6 million orders per second on a single thread.

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

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

H>> У меня есть тестовые прогоны на обработку почти 2 трлн. ордеров в течении полутора недель без единого запуска GC. Я бы дальше гонял, но место на NASе под данные закончились.
·>А где об этом почитать подробно? Тут

Автор: Hardballer
Дата: 15.10.18

ты давно обещал что-то публичное...

В публику пока не вылезли, поэтому никак. Да и когда вылезем, деталей я тоже писать не буду как я это все сделал, по очевидным же причинам.

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

S>Дурацкий вопрос, но чем user space драйвер отличается от обычной программы? Доступ к DMA? А если речь о kernel space, там какие будут варианты?
Да в общем то ничем.
Более того, часто такие ещё и работают медленнее потому что приходится нырять в ядро и обратно за вещами, которые из юзера не сделать.

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

Pzz>Оптимизатор Go, кстати, умеет делать довольно необычные вещи, которые не умеет делать оптимизатор C. Например, он умеет выделять идеоматические конструкции (например, цикл для побайтного копирования данных с места на место) и генерировать для них соответствующий код.

С/С++ компиляторы это умеют очень давно.

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

BB>По-моемуб Dokan написан на C# — это sshfs для винды.
Он написан на С.
Dokan это в общем то только сам kernel драйвер, а примеры как его использовать есть на разных языках — в общем то пофигу из какого языка IOCTL дёргать.

BB> Он какое-то время работает, потом помирает — нужно кикать и перезапускать (а может не от времени зависит, а от объема трафика... )
У меня поверх Dokan драйвера своя UserFS написана, для личных нужд.
Usermode часть на С++, кернел — родной Dokan driver который на С. Ничего не течёт, ничего не помирает.

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

_>Если написать код естественно, с RAII, и прочими плюшками авто-освобождения — то матрицы начнут удаляться прямо по завершению расчёта.
Это если не понимать что такое аллокатор.
В С/С++ они заменяемы, более того, в С++ довольно легко сделать отдельные стратегии аллокации для разных типов объектов.
Всё что тебе там надо это прокси аллокатор, который понимает что сейчас надо как можно быстрее и просто складывает освобождённые объекты в SLL "на потом".

_> Тем более если библиотеки для расчёта вообще сторонние — они сами начнут чистить за собой прежде чем отдадут циферки, и сожрут ценное время, причём в том же потоке.
Можно перекрыть аллокатор глобально Разишо библиотеки будут не new/delete пользоваться а совсем врукопашку с аллокацией работать.

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

_>>И программисту чтобы это всё обойти придётся много думать, менять код библиотек, и т.п.
S>Кастомные аллокаторы изначальная фича всех нормальных структур данных

Особенно тех, которые заточены на производительность.

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

S>было странно видеть что программа на C++ при первом вызове метода с большим количеством аллокаций работает быстро, а при втором в несколько раз медленнее — фрагментация кучи).
Проблема тут не в С++ а в плохом аллокаторе, который либо в рантайме либо вообще системный.

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

CC>С/С++ компиляторы это умеют очень давно.

Go — язык очень простой и неизбыточный, одну и ту же вещь там разными путями не сделаешь, поэтому ассортимент идеоматических конструкций, которые должен понимать компилятор, невелик.

C++, с другой стороны, язык дьявольски сложный, и одни и те же вещи каждая группа разработчиков считает правильным делать на свой, непохожий на других, манер. Поэтому я не думаю, что выделение компилятором идеоматических конструкций в C++ с целью их оптимальной кодогенерации, такое уж перспективное развитие компиляторной науки.

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

CC>Всё что тебе там надо это прокси аллокатор, который понимает что сейчас надо как можно быстрее и просто складывает освобождённые объекты в SLL "на потом".

А разве использование определенного пользователем аллокатора в C++ позволяет отложить исполнение деструктора "на потом"?

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

Pzz>А разве использование определенного пользователем аллокатора в C++ позволяет отложить исполнение деструктора "на потом"?

Деструктора — нет, но вот реального освобождения памяти можно и избежать, есть есть такая цель.

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

EP>>А там где в HFT конкуренция на скорость её и не используют
rfq>ну почему, используют: LMAX

Во во, со стороны биржи, ибо там скорость не критична, они практически все на Java. Покажи хоть один HFT shop использующий Java на критическом пути.

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

EP>> Биржи зачастую являются монополиями, и конкуренции на скорость там обычно нет. Собственно поэтому с той стороны и приемлема Java.
·>Ты наверное путаешь с equities биржами, когда какой-нибудь там AAPL торгуется только на одной бирже. FX биржи конкурируют по полной. Там latency прямо пропорционально доходам. Чем меньше latency, тем более узкий спред могут выставлять market makers.

На спред влияют куча факторов, и latency биржи далеко не является главным.

·>Чем уже спред, тем вероятнее будет trade,

Это не факт.

·>процент с которого — прибыль биржи.

Equity биржи тоже снимают stamp. Но объёмы торгов магическим образом не увеличатся при уменьшении latency.
Иначе все бы они давно бы были на порядке быстрее. Посмотри на доходы крупных бирж, увеличение их скажем на 5% покрыло бы расходы на использование любой из доступных сегодня технологий.

·>По SLA latency был 4ms для 99.99% . Медиана — ~300us. Может из того железа и можно выжать побольше, используя "любые" языки, но уже не принципиально.

Во-во, эти циферки как раз наглядный показатель отсутствия конкуренции по latency. Сравни эти циферки с latency топовых HFT-систем — задачи решаются примерно одинаковые, где-то даже сложнее со стороны торгующих систем, ибо там ещё нужно делать предсказание, обработав данные с кучи источников, и проверки риска, чего нет на стороне биржи, при этом latency отличается драматически — ибо там реальная конкуренция.

EP>> Со стороны же участников торгов, там где скорость напрямую конвертируются в деньги, никакой Java нет и в помине
·>Кто где и как. Зависит от.

Ну да, там где скорость не важна, а она действительно важна не везде — без проблем используют Java. Главный фактор — легкость найма Java-разработчиков.

EP>> ·>Кстати, вообще говоря, вылизывать быстродействие на любом языке всё равно придётся, GC тут не самое страшное.
EP>> Но на некоторых это проще и всё равно в итоге быстрее
·>Это хорошо для кода "написал, вылизал и забыл". Если тебе надо постоянно вносить изменения, выполняя хотелки бизнеса, то пока ты будешь писать кастомный аллокатор в "любом" языке, решение на java уже выкатят в прод.

Непонятно о чём речь.
Если нужен быстрый код — то да, на C++ применяются ряд техник, как и на любом другом языке. На C++ быстрый код получить легче и менее трудозатратно, нежели чем например на Java. На Java для получения быстрого кода придётся работать против языка, затратить намного больше усилий, и при этом всё равно получить более тормозной код.
То есть используя твой пример — выполнять хотелки бизнеса в условиях требований к скорости — на Java займёт больше времени и ресурсов, и решение выкатится в код позднее
Если же требований по скорости нет, то непонятно при чём здесь вообще кастомный аллокатор

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

DM>> ·>Там latency прямо пропорционально доходам.
DM>> Больше latency — больше доход? Тогда конечно.
·>Вообще говоря это каком-то смысле правильно — больше девяток в latency — больше доход.

То есть нужно полагать системы с тридцатью девятками на latency в одни сутки имеют огромный доход?

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

Pzz>Go — язык очень простой и неизбыточный, одну и ту же вещь там разными путями не сделаешь, поэтому ассортимент идеоматических конструкций, которые должен понимать компилятор, невелик.
Pzz>C++, с другой стороны, язык дьявольски сложный, и одни и те же вещи каждая группа разработчиков считает правильным делать на свой, непохожий на других, манер. Поэтому я не думаю, что выделение компилятором идеоматических конструкций в C++ с целью их оптимальной кодогенерации, такое уж перспективное развитие компиляторной науки.

Оптимизатор работает на разных уровнях. В том числе и на уровне IL — в которым остаётся например простейшая SSA форма, вместо зоопарка непохожих друг на друга "манер".
Другое дело что в C++, за счёт шаблонов, идиоматические вещи оптимизируются не только на уровне компилятора, но и на уровне библиотек. Тот же упомянутый выше цикл побайтного копирования руками и писать необязательно, а можно использовать высокоуровневый std::copy, который уже внутри, если позволяют типы, запустит memmove.

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

KP>Как и ожидалось быстрей всего реализации на Си и Rust, фактически одна и та же скорость. Чуть медленнее, но всё равно достойный результат у Go и C# (правда C# слился из за больших задержек в тесте на 20 Mpps оставив в победителях C, Rust и Go).

Что значит слился? Они выкидывали языки чтобы масштаб увеличить. Ну, и не факт, что реализация оптимальна. Плюс время идет и МС за это время несколько оптимизировал дотнет. В тесте используется netcoreapp2.1, а уже 5.0 на дворе. Говорят там подоптимизировали многое. Плюс код так себя. Можно по выжимать из него.

Особо приятно, что ко многим языкам целая работа с описанием есть.

KP>Удивительными оказались результаты для драйверов на OCaml и Haskell — они очень даже неплохо держат нагрузку, что для меня было большой неожиданностью. При этом кода на Haskell один из самых читаемых в этой коллекции реализаций, как мне показалось.

Что-то ты явно приукрашиваешь. Как языки (точнее рантаймы) распределились на три группы:


И Хаскель явно в конце второй группы с огромным отставанием от лидеров. Фактически он слился.

Меня больше удивило то, как слилась Ява. Я писал на ней под Андройд и она вела себя довольно не плохо. Так что тоже думаю, дело в рантайме и качестве кода.

KP>Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?

Да, питон показал просто константную скорость с твердой константой — 0.

Но это ожидаемо. Я всегда смеюсь над теми кто серьезно говорит о скорости интерпретируемых языков.

Скорее меня удивил Свифт. Эппл столько пиара о его скоростных характеристиках написал. Даже от ЖЦ отказались из-за скорости. А тут такое. Думаю, там тоже реализация повлияла.

С++-ная реализация, кстати, появилась. Но в пенесометрии ее почему-то не добавили. А жаль.

На эти тесты нужно натравить спецов, чтобы они подтюнили тесты и перевели их на лучшие рантаймы. За C# (а точнее дотнет) ручаюсь, что можно разогнать за счет тюнинга и замены рантайма.

С Явой и Свифтом вообще странно и надо разбираться. А вот Хаскель таки слился. Как и ОКамл (что тоже странно). Твоих восторгов по производительности Хаскеля не разделяю.

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

KP>Как и ожидалось быстрей всего реализации на Си и Rust, фактически одна и та же скорость. Чуть медленнее, но всё равно достойный результат у Go и C# (правда C# слился из за больших задержек в тесте на 20 Mpps оставив в победителях C, Rust и Go).

Чуть-чуть почитал 2018-ixy-c-sharp.pdf и поглядел на то как код выглядит сейчас. Код явно переписывални на фишках Core 2.1.

Например, автор просто отжог в исходной реализации TxBatchBusyWait() использовав Linq и ToArray:

1 public void TxBatchBusyWait(PacketBuffer[] buffers)
2 {
3     int numSent = 0;
4     while (numSent < buffers.Length)
5     {
6         numSent += TxBatch(buffers.Skip(numSent).Take(buffers.Length - numSent).ToArray());
8     }
9 }

Удивительно, что эта версия вообще не слилась к черту.
Вот соврмеменная:

      /// <summary>
      /// Calls TxBatch until all packets are queued with busy waiting
      /// </summary>
      public void TxBatchBusyWait(int queueId, Span<PacketBuffer> buffers)
      {
          while(buffers.Length > 0)
          {
              var numSent = TxBatch(queueId, buffers);
              buffers = buffers.Slice(numSent);
          }
      }

Но и в текущей версии есть много чего оптимизировать. Куча динамически занимаемой памяти. Ненужная виртуальность и т.п.

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


KP>Так же интересно то, что драйвер на Java показал довольно хреновые результаты, не Python (который как и положено Python-у слился самым первым, показав всю свою знаменитую скорость работы), но тем не менее. Как же тогда её в HFT используют? Тут я сильно озадачился... надо тюнить JVM как я понимаю?
Странно что нет кода на https://dlang.org/
Последний раз сравнивал, отличий в перформансе в сравнении с растом не заметил(мерял time в linux).
Очень хороший ЯП, не заслужено забыт. Хотя вижу потихоньку развивается. Глава в прошлом году сменился. У него есть политика развития. посмотрим.
Главное преимущество бинарная совместимость с си.
А эти ваши ВМ это прошлый век. Жаль что это вовремя не поняли создатели.

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

Pzz>У большинства бэкенд серверов загрузка очень маленькая, потому что большинство вебсайтов никто не посещает. Но вот если вдруг сайт выстреливает, то приходится это бэкенды пачками ставить. А они денег стоят.

Ты как всегда в точку попадашь. Как-то нарвался на вот такую инфу:

Обычно используют популярные Java (одноклассники), PHP (facebook, vk), C# (stackoverflow), Python (youtube), Ruby (twitter) — стандартные обычные языки, когда можно найти и хорошие инструменты, и много разработчиков.

Ну, может врут.

Казалось бы, если тебе верить, то все должно написано хотя бы на Rust-е.

Думаю, что высшим приоратом для серверов является надежность. На втором — масштабируемость. И уже на третьем — скорость исполнения кода.

Понятно, что при росте люди начинают оптимизировать. Но оптимизация может заключаться в переписывании нескольких узких мест на низкоуровневом языке. А как видно из этого примера. Rust, Go и C# вполне сходят за универсальные.