Здравствуйте, Serginio1, Вы писали:
S>·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.
S> Ne кстати не заметил
S>Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения. S>И соответственно огромные тормоза при изменении огромного количества ссылок. S>Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
Ещё раз. Этот тест демонстрирует паузы, создаваемые gc, эти паузы происходят для всех тредов. Т.е. все треды будут остановленны в момент сборки мусора. Не важно как и почему этот мусор появился, важно то, что в LL приложении не позволительно некоторым важным тредам останавливаться на дольше чем пару миллисекунд. .net gc же создавал паузы на два-три порядка длинее.
В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>Я делал синтетические тесты и на джаве и на дотнете с генерацией объектов и отправки их в другой поток. V>Так вот, дотнетный движок легко справляется с 0-м поколением даже из "чужого" для объекта потока, а в джаве, похоже, такие объекты улетают в 1-е поколение, затем быстро упираемся в потолок и начинается сплошное GC. При том, что дотнетный тест может работать вечно без пауз — в фоне прекрасно всё чистится. Вот чтобы ты знал — для таких сценариев и нужен твой zing.
Несколько лет назад ты на каждом углу регулярно рассказывал сказки ".Net GC ложится навзничь."
На счет вечно без пауз — это заблуждение. Есть у него предел частоты инстанцирований, выше которого Gen0 начинает пухнуть до безобразия, в пересчете на _гигабайты_
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>>·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.
S>> Ne кстати не заметил
S>>Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения. S>>И соответственно огромные тормоза при изменении огромного количества ссылок. S>>Это нужно учитывать. Посмотри на дату. Сейчас может все по другому. ·>Ещё раз. Этот тест демонстрирует паузы, создаваемые gc, эти паузы происходят для всех тредов. Т.е. все треды будут остановленны в момент сборки мусора. Не важно как и почему этот мусор появился, важно то, что в LL приложении не позволительно некоторым важным тредам останавливаться на дольше чем пару миллисекунд. .net gc же создавал паузы на два-три порядка длинее.
А как измеряются паузы? Судя по такому количеству выделенных объектов и постоянном обновлении кэша, там будет постоянная сборка мусора.
И почему до 10 минут сборка быстрее?
·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM.
Важно знать почему такие задержки, чем они обусловлены, что бы с ними бороться.
Кроме того на дворе уже 4.6.2
А заодно и на Javа этот тест запустить
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
Ф>>>Почти не зависит: чтобы это было возможно, нужно чтобы СУБД все свои действия сразу писала на диск. А на практике оно чаще всего откладывает запись (доступ к диску так оптимизируют) C>>ЩИТО? I>Где, по твоему, БД хранит буфер транзакций и в какой момент она его сбрасывает на диск ?
Здравствуйте, ·, Вы писали:
·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM.
Фигню какую-то спорите, если честно. На шарпе нет (и в ближайшем будущем не будет) HFT, т.к. основной и единственный вендор в этом абсолютно не заинтересован.
Не, может и появится специализированна версия рантайма, но на общую ситуацию оно повлияет не больше, чем AzulGC на текущую яву.
Если надо поспорить чисто теоретически — то можно попритягивать за уши pauseless GC из MS research (их там штук 5 минимум пылится) и текущую работу по stackallock, fine-grained heaps и fast loh в .net core, или просто почитать Pro .NET Performance от Sacha Goldstein, в которой нюансам работы с GC посвящён целый раздел.
На практике ситуация особо не изменится — в реализации на яве / нативе под lin уже вбуханы огромные бюджеты и никто в здравом уме не будет переползать под другой стек просто чтоб было.
Здравствуйте, Ikemefula, Вы писали:
I>Несколько лет назад ты на каждом углу регулярно рассказывал сказки ".Net GC ложится навзничь."
Я и сейчас так утверждаю, что для многих задач ложится, и?
I>На счет вечно без пауз — это заблуждение. Есть у него предел частоты инстанцирований, выше которого Gen0 начинает пухнуть до безобразия, в пересчете на _гигабайты_
Не создавай много потоков.
Для заведомо циклических вещей еще хорошо работают пулы объектов.
Здравствуйте, Sinix, Вы писали:
S>·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM. S>Фигню какую-то спорите, если честно.
Это ты товарищу vdimas говори, это он утверждает что "В сфере упомянутого тобою HFT джава уступает дотнету сильно, примерно вдвое-трое по latency.".
S>На шарпе нет (и в ближайшем будущем не будет) HFT, т.к. основной и единственный вендор в этом абсолютно не заинтересован.
Я это и говорю: "у микрософта другие приоритеты, в своей нише ентерпрайз, UI, облаков и веба; ему это уже не надо.".
S>Не, может и появится специализированна версия рантайма, но на общую ситуацию оно повлияет не больше, чем AzulGC на текущую яву.
С текущей политикой майкрософта — очень сомневаюсь, что появится.
S>Если надо поспорить чисто теоретически — то можно попритягивать за уши pauseless GC из MS research (их там штук 5 минимум пылится) и текущую работу по stackallock, fine-grained heaps и fast loh в .net core, или просто почитать Pro .NET Performance от Sacha Goldstein, в которой нюансам работы с GC посвящён целый раздел. S>На практике ситуация особо не изменится — в реализации на яве / нативе под lin уже вбуханы огромные бюджеты и никто в здравом уме не будет переползать под другой стек просто чтоб было.
Ну бюджеты это совсем не причина. На Яву же переползли в своё время, а в С/С++ вбуханы были не меньшие бюджеты. Тут скорее дело в том, что .net уже нечего предложить как киллер-фичу, чтобы переползание было обоснованно, у джавы перед нейтивом она была — managed.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>Долгоиграющие треды не нужны при хорошей степени асинхронности кода. V>>>>Они даже резко вредны. V>>·>Они нужны для LL. V>>Ошибка. Не нужны. Потому что характер работы системы точно такой же — реакция на внешние события. ·>Не просто реакция, а мгновенная реакция, без всяких задержек. А поэтому нет роскоши подождать пока в пуле появится свободный поток, пока этот поток подрузит контекст, пока операционка подберёт для него свободное ядро процессора, пока процессор подгрузит данные из другой numa ноды и т.д. и т.п.
Вот тут ошибка рассуждений и кроется. По блокирующему ожиданию на IO такой поток будет точно так же давно вытеснен и его пробуждение будет отнюдь не более быстрым, чем обработка IO потоком из пула, а ровно наоборот.
Здравствуйте, Ikemefula, Вы писали:
V>>Ошибка. Не нужны. Потому что характер работы системы точно такой же — реакция на внешние события. I> И давно у тебя создание да пробуждение потока стало дешовой операцией ?
Здравствуйте, Serginio1, Вы писали:
S> А как измеряются паузы? Судя по такому количеству выделенных объектов и постоянном обновлении кэша, там будет постоянная сборка мусора. S>И почему до 10 минут сборка быстрее?
Так ты статью прочти, прям глава есть "Detecting GC Pauses".
S>·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM. S> Важно знать почему такие задержки, чем они обусловлены, что бы с ними бороться.
Они обусловленны тем, какие алгоритмы gc используются.
S> Кроме того на дворе уже 4.6.2
Ну-ну.
S> А заодно и на Javа этот тест запустить
zing — pauseless gc.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vdimas, Вы писали:
V>·>Не просто реакция, а мгновенная реакция, без всяких задержек. А поэтому нет роскоши подождать пока в пуле появится свободный поток, пока этот поток подрузит контекст, пока операционка подберёт для него свободное ядро процессора, пока процессор подгрузит данные из другой numa ноды и т.д. и т.п. V>Вот тут ошибка рассуждений и кроется. По блокирующему ожиданию на IO такой поток будет точно так же давно вытеснен и его пробуждение будет отнюдь не более быстрым, чем обработка IO потоком из пула, а ровно наоборот.
LL-тред не блокируется, тем более на IO, он крутит busy spin пока отсутствуют данные во входящем сетевом буфере. Да, процессор жжот.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>Фигню какую-то спорите, если честно. ·>Это ты товарищу vdimas говори, это он утверждает что "В сфере упомянутого тобою HFT джава уступает дотнету сильно, примерно вдвое-трое по latency.".
А смысл? не я ж спорю
·>Ну бюджеты это совсем не причина. На Яву же переползли в своё время, а в С/С++ вбуханы были не меньшие бюджеты. Тут скорее дело в том, что .net уже нечего предложить как киллер-фичу, чтобы переползание было обоснованно, у джавы перед нейтивом она была — managed.
Ну да, про это и речь. Даже если и появится очередная мега-киллер-фича, то всё равно переползание всей субкультуры на сабж — дело явно не одного и даже не двух лет.
Когда там хайп на яву в HFT пошёл, в 2010/11 годах емнип?
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>> А как измеряются паузы? Судя по такому количеству выделенных объектов и постоянном обновлении кэша, там будет постоянная сборка мусора. S>>И почему до 10 минут сборка быстрее? ·>Так ты статью прочти, прям глава есть "Detecting GC Pauses".
То есть вот это
var timer = new Stopwatch();
while (true)
{
timer.Restart();
Thread.Sleep(1);
timer.Stop();
// allow a little bit of leewayif (timer.ElapsedMilliseconds > 2)
{
// Record the pause
_histogram.recordValue(timer.ElapsedMilliseconds);
}
}
Паузы могут быть и не из-за GS S>>·>В сишарпе, как я понял, смогли извернуться только использованием нативного управления тредами, памятью и синхронизацией. В java можно просто запускать приложение под другой VM. S>> Важно знать почему такие задержки, чем они обусловлены, что бы с ними бороться. ·>Они обусловленны тем, какие алгоритмы gc используются.
Какими именно, Почему задержки появляются через 10 минут? S>> Кроме того на дворе уже 4.6.2 ·>Ну-ну.
S>> А заодно и на Javа этот тест запустить ·>zing — pauseless gc.
Запусти. И мы у себя запустим. Посчитаем общее время.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Паузы могут быть и не из-за GS
А из-за чего?
Кстати, это тоже камень в огород c#. Диагностика таких вот тонких проблем очень проблематична. Сложно (если вообще возможно) докопаться до причины тормозов.
S>·>Они обусловленны тем, какие алгоритмы gc используются. S> Какими именно, Почему задержки появляются через 10 минут?
В статье указанно, тестируются все четыре режима, в т.ч. SustainedLowLatency.
Не важно через сколько именно минут появляются задержки. Важно что они появляются.
S>>> А заодно и на Javа этот тест запустить S>·>zing — pauseless gc. S> Запусти. И мы у себя запустим. Посчитаем общее время.
У меня сейчас нет доступа к zing. Но я точно знаю, что задержки больше 10мс репортят в Azul как баги.
Считают не общее время (общее время чего??), а гистограмму задержек.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Serginio1, Вы писали:
S>> Паузы могут быть и не из-за GS ·>А из-за чего? ·>Кстати, это тоже камень в огород c#. Диагностика таких вот тонких проблем очень проблематична. Сложно (если вообще возможно) докопаться до причины тормозов.
Это свойство Windows. Есть еще куча сервисов и приложений.
S>>·>Они обусловленны тем, какие алгоритмы gc используются. S>> Какими именно, Почему задержки появляются через 10 минут? ·>В статье указанно, тестируются все четыре режима, в т.ч. SustainedLowLatency. ·>Не важно через сколько именно минут появляются задержки. Важно что они появляются.
Важно. Я тебе привел вариант с Write Barrier который подходит под постоянное обновление "кэша".
S>>>> А заодно и на Javа этот тест запустить S>>·>zing — pauseless gc. S>> Запусти. И мы у себя запустим. Посчитаем общее время. ·>У меня сейчас нет доступа к zing. Но я точно знаю, что задержки больше 10мс репортят в Azul как баги. ·>Считают не общее время (общее время чего??), а гистограмму задержек.
Общее время выполнения циклов. Можно уменьшить задержки, за счет уменьшения скорости выполнения.
А где исходники?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>·>А из-за чего? S>·>Кстати, это тоже камень в огород c#. Диагностика таких вот тонких проблем очень проблематична. Сложно (если вообще возможно) докопаться до причины тормозов. S> Это свойство Windows. Есть еще куча сервисов и приложений.
Угу, с этим тоже борются, ещё один камень в огород c# — он win-only, а в винде тоже всё плохо с LL. Я приводил ссылочку на ютуб с подробным рассказом — как борются в линухе. Вот исходники https://github.com/epickrram/perf-workshop Покажи как бы ты боролся с этим же в виндах и каких бы показателей смог достичь.
В общем, если у тебя есть другие тесты, дающие другие результаты — давай показывай. А пока ты просто пустословно споришь против статьи, и даже не с её автором.
S>·>В статье указанно, тестируются все четыре режима, в т.ч. SustainedLowLatency. S>·>Не важно через сколько именно минут появляются задержки. Важно что они появляются. S> Важно. Я тебе привел вариант с Write Barrier который подходит под постоянное обновление "кэша".
Цель теста вызвать gc и убедиться, что он не влияет на важный тред. А он таки влияет, смертельно для LL применений.
S>·>У меня сейчас нет доступа к zing. Но я точно знаю, что задержки больше 10мс репортят в Azul как баги. S>·>Считают не общее время (общее время чего??), а гистограмму задержек. S> Общее время выполнения циклов. Можно уменьшить задержки, за счет уменьшения скорости выполнения.
LL gc занимает больше ресурсов, больше тратит суммарное время, но зато даёт гарантии отсутствия задержек — это цель.
S> А где исходники?
Исходники чего?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>·>Зачем мне на сайт заходить, я и так знаю чем они занимаются... я к ним в офис заходил... регулярно. V>>Ну ОК, тут баланс вложений и отдачи, пусть так. HFT для бедных... почему бы и нет? ·>Обеспечивать качество и стабильность проще с управяемыми средами. В общем есть свои достоинства, причём тут бедность?..
Потому что всё имеет свою цену.
Почему медиакодеки до сих пор нейтивные?
Неужели задачи обработки ордеров сложнее обработки медиа? ))
V>>Потому что JNI принципиально идёт там, где требуется эффективность, иначе он НЕ нужен. ·>Он идёт в основном там, где есть что-то системнозависимое. Конечно, может быть есть какие-то числодробилки, типа видеокодеков, но тоже непонятно откуда там возьмётся сложный JNI — отдал массив байт, забрал массив байт.
Во многих АПИ-вызовах или нейтивных либах параметры бывают чуть сложнее, чем массив байт.
V>>·>Да и сам JNI тупой и простой как пробка. V>>Пока тебе не надо дергать методы-геттеры подаваемых как параметры объектов. ·>А что, из какого-нибудь pure C геттеры из c# дёргаются как-то проще? ·>Подавай что-то более удобное, массив байт, например. В общем бывают всякие ситуации, но далеко не всегда требуется весь ужас которым тут меня ты пытаешься запугать.
Да, целые структуры маршаллятся БЕЗ лишнего копирования через тормозной reflection, просто передаются по ссылке. Кароч, в плане интеропа с нейтивом джава дотнету не конкурент ни разу.
V>>·>Отлаживается тоже элементарно, тесты же есть, а накрайняк можно и отладчиком подцепиться. V>>Тут проблема в разрыве второго рода. В джаве так любят рефакторинг, что от малейшего чиха затем твой собственный JNI начинает затем тупо бегать по памяти. )) ·>В джаве любят хорошее покрытие тестами. Пусть бегает, дальше первого же прогона тестов не убежит.
Пробежка по памяти никакими тестами может быть и не отловлена, потому что в случае тестирования, скажем, мы могли бегать по какой-нить свободной, но закомиченной странице памяти, а в реальной приложухе затем можем убежать куда угодно.
V>>И с отладкой там ж-па, потому что из нейтивного отладчика не видно, правильно ли дергаются методы и поля джавовского объекта. Со студией в плане одновременной отладки нейтивного и дотнетного кода тут не сравнить. ·>Можно и оба отладчика подцепить одновременно — ява и нейтив.
Жесть. ))
Ты часто так делал?
Понравилось?
·>Не знаю, мне вообще не приходилось клепать навороченные JNI, обычно это тонкие обёртки над нативными либами или обращение к какой-то простенькой системной api.
Обертки-то тонкие, а кода немеряно на пустом месте. И сам код — сплошной птичий язык. ))
Да чего тут упорствовать-то, оно как есть так есть.
V>>·>А вообще редко что приходится дёргать, если писать серверный код, а не GUI или специфическое оборудование. V>>В процессе прототипирования — часто. ·>Может у тебя специфика такая, хз. Это не типично для явы.
Речь не о яве, а о решаемых задачах. Да, прототипы я писал не под Яву.
Да, на управляемых средах на коленке можно банально быстрее что-то сляпать и посмотреть результат эксперимента.
Хотя, после покупки последнего Решарпера для С++, похоже, этот период моей жизни уже окончательно в прошлом. ))
Дотнет, похоже, останется у меня только для GUI-утилит.
V>>·>Фиг знает, я не сравнивал. Может быть. Пусть так. В любом случае не одним fix engine биржа жива. V>>Ну так матчить ордера в нейтиве еще эффективнее. Это же просто "плоские" структуры в памяти, в случае нейтива. ·>Так говорю же. Жестких LL сервисов всего пара — EV и EMS. А обвязки вокруг этого ещё штук 40 сервисов, включая пост-трейд проверки, генераторы отчётов, архиваторы данных, субд, http client/server, и т.д. и т.п. Гораздо удобнее когда оно всё написано на одном языке и прозрачно взаимодействует друг с другом, чем мешанина кучи технологий. Или ты предлагаешь веб-приложения тоже на нейтиве лабать?
Я уже отвечал на это — внутренние утилитные задачи сейчас всё чаще делают на скриптах/вебе. Это банально универсальнее, один и тот же язык (скрипт) на клиенте и сервере. Сейчас под node.js чего уже только нет. И отчеты генерят зачастую через XSLT, сейчас развелось уже WYSIWYG-редакторов и для него, т.е. задача из элитной перешла в разряд для новичков.
V>>Поэтому вычисления в джава вдвое сливали после выхода дотнета, угу. ·>И именно для этого дотнет без нативного нутра не используется?
Опять троллинг. Я хочу знать, откуда ты взял, что Джава в целом быстрее дотнета?
Типичные результаты любых забегов:
Снова в большинстве микротестов быстрее .Net, Java в 4 микротестах на порядок медленнее
При том, что для тестов подготавливаются идентичные сниппеты, а ведь в дотнете ту же самую задачу можно решить зачастую более эффективно, чем в Джава, но сам тест уже станет не релевантным, хотя в реальной жизни именно такая нерелевантность и рулит — это наличие способов для построения ДРУГИХ, но более эффективных решений. Т.е. сравнивать же Джаву с современным .Net 4.5 глупо, как по мне. А ты тут такой пытаешься троллить взрослых дядек. ))
И это я еще молчу о том, что сейчас поголовно дотнетные приложухи прогоняют через .Net Native-оптимизатор, который еще вдвое/трое порой даёт ускорение.
В общем, многие годы тут были и обсуждения и ссылки на кучи тестов. Сугубо по памяти я помню, что в Джава был гораздо более шустрый regex изкаробки, чем в дотнете, но после появления в дотнете опции компиллируемого regex (он интерпретируемый по-умолчанию) дотнет порой даже впереди.
Да, порой приводились еще какие-то совсем редкие сценарии, где Джава была чуть-чуть быстрее, но они погоду не делали, скорее, наоборот — своей редкостью лишь подтверждали правило.
·>Понятно, что код прогревают. Суровая оптимизация в нейтив может быть полезна для мелких часто запускаемых утилит, а не для серверного кода. V>>Ну это уже троллинг как он есть. Без комментариев. )) ·>Пару минут прогретый код почти весь компилируется.
Ааа... Ты просто не понял. JIT-компиляторы рождают хреновый неоптимизированный код, что в Джаве, что в Дотнете. И это непреодолимо, потому что им некогда. Поэтому я и указывал на доступность изкаробки для дотнета быть скомпиллированным в хорошо оптимизированный нейтивный бинарник. Да, будет потрачено некоторое время на компиляцию и оптимизацию, но это же однократная задача, по-сути, только по время сборки релиза.
V>>Да какая разница? Каждое строковое значение — это отдельный объект в хипе. ·>Не используйте строковые значения. Есть даже интерфейс CharSequence. Ну или даже char[].
char[] ничем не лучше строки.
·>Хотя зачем строки в FIX? там вроде только ascii. byte[] сгодится.
byte[] аналогично.
·>А если так нужны строки — их можно и в пул сложить.
Иммутабельные объекты в пул.
Оригинально.
V>>Ты мне не ссылки давай, а просто ответь: может ли джава-машинка гарантировать, что каждый её логический поток будет в течении всей своей жизни выполняться на одном и том же потоке ОС? Потому что везде строго предупреждают об обратном. ·>Общий стандарт явы — нет, но данная реализация машинки для данной инфраструктуры — да, может гарантировать.
И какая из реализаций Джава-машинки это гарантирует?
V>>Пффф... ну тогда можно строить произвольные предположения об "эффективности Джава". Тут уже сколько фантазии хватит. ·>У меня есть примеры когда ява используется как основной язык LL-системы. А шарп в лучшем случае как нашлёпка над нейтивом. Этого достаточно, конкретные цифры не так важны.
Ну я-то прекрасно понял ход твоих мыслей, просто с моей колокольни это выглядит забавно, когда человек по конечному результату пытается восстановить ход работ. И вдвойне это забавно после того, как я указал на все причины, а именно — в дотнете нет смысла делать иначе, потому что это ОЧЕНЬ дешевый для дотнета способ, в отличие от джавы. Т.е., писать максимально-эффективные решения на pure .Net можно только из спортивного интереса и исключительно за свой счёт, бо это будет обман инвесторов. Например, наша дотная обертка написана на C++/CLR и мне сложно на словах передать всю бесконечную гамму удобств такого подхода в сравнении с JNI.
V>>·>Но в любом случае Fix gateway не самый быстрый и важный компонет биржи, да и дистрибьютится он на ура. V>>На стороне клиента и сервера важна связка ордера и соответствующего сетевого сообщения. Т.е., FIX-движки (а часто FAST-кодирование или аналогичное сверху) — они не вещи в себе, они должны обеспечивать именно такую связку. ·>От сетевого сообщения там нужен только sequence number для связки. Порванная из-за проблем в сети сессия может восстановиться на другом сервере с другим клиентом.
Мы на разных языках разговариваем. У нас представление FIX-сообщения в памяти и сетке идентично, т.е. мы тупо пихаем тело сообщения в сетку и точно так же принятый блоб без изменений хранится в памяти, просто будет размечен индексами при парсинге. Для джавы такой подход — недостижимый хайтек, потому и результаты более чем на порядок отличаются.
V>>Я дал ссылки на репорты от совместной лаборатории Intel+OnX, там таблицы результатов + графики. ·>Я помню только ссылки на onixs.biz. Я что-то пропустил? Повтори, плз.
V>>А все эти брокерские конторы — они же клиенты и есть. ·>Так у них там UI в основном... какой там LL?..
UI — это всякие утилиты для декларирования стратегий и обзора происходящего.
Торгуют-то роботы с микросекундными задержками. Какое там уже в опу UI? ))
·>Ты что-то не то смотришь. Это просто перф-тест для juc queue, для сравнения.
Я смотрю именно то — тест быстродействия в сценарии один-ко-многим. Очень популярно в сценарии "сливания" данных для обработки из разных UDP-каналов, например.
·>В дизрапторе используется ring buffer преаллоцированных объектов (то самое 2-е поколение), к которому магией обеспечивается эксклюзивный доступ из всяких разных тредов.
Ой, магия. ))
Мне по работе как раз положено такую "магию" придумывать и доводить до совершенства. В нейтиве, ес-но.
Поверь, я прекрасно отдаю себе отчёт, на какой именно тест дизраптора я дал ссылку.
Просто ты в такой низкий уровень не лезешь, судя по твоим комментам.
V>>Тут фишка в том, что объект в джава (я испытывал оракловую), будучи "потерянным" текущим потоком, перестаёт быть объектом 0-го поколения. По-другому объяснить наблюдаемое я не мог, бо если пихать в очередь того же самого потока, то всё в джаве пашет гладко. ·>Хз, не знаю, много разных объяснений. Может escape analysis мутит или Thread Local Area. В любом случае, это не самый лучший подход для организации многопоточности.
Не самый лучший в джава?
Поверь, качественная перекачка данных из потока в поток — это ноу-хау каждой конторы, которая делает подобного рода решения — обработку сумасшедших потоков данных в реалтайме. Хорошо оттюненный конвейер data-flow перемалывает в секунду до миллиона ордеров на каждой паре системных потоков. Для джавы это всё недостижимо, ес-но.
Просто такая фишка — в самых загруженных сценариях вовсе не требуется будить обрабатывающий поток, он и так работает. Ну и грамотно выстроенная стратегия "батчей" ордеров что при приёме, что при отсылке, что при межпоточной передаче — наше всё. По-сути, трудоёмкость обработки каждого ордера в нейтиве — это сотни наносекунд (редко больше полутора микросекунд). Всё остальное время тратится как раз на системные вызовы ОС. Сумеешь минимизировать их кол-во, а лучше вообще их избежать (кроме вызовов сетевого АПИ с коэффициентом размножения 1 вызов на 100-200 ордеров) — и ты победишь.
V>>А ведь, казалось бы, data flow в этой области надо вылизывать еще на уровне концепта максимально тщательно, а не применять стандартный джавовский подход: наколенный эксперимент -> рефакторинг -> продакшен. ))) ·>Ну может быть какой-нибудь nasdaq и может вылизывать годами, но не все это могут себе позволить.
Потребовалось пол-года и 3 нейтивных программиста, чтобы вывести продукт в топы.
Т.е. слухи о дороговизне нейтивной разработки на деле сильно преувеличены.
V>>С байт-буфером будет сериализация-десериализация на каждый чих. ·>Данные обычно плоские и фиксированной ширины. Просто обращаешься по фиксированным смещениям, сериализация тривиальна и быстра.
Ну вот, ты опять показал невладение темой. Что происходит в железе, если мы читаем, например, невыровненное 32-хразрядное слово в 32-хразрядной архитектуре? (или 64 в 64 аналогично?)
Так вот, происходит прерывание "ошибка адресации", где обработчик прерывания сначала разбирается, на какой машинной инструкции идиот-программист полез в память, потом достаёт данные нужной ширины (согласно разобранной инструкции) побайтно, собирает эти байты в целевой регистр и возвращает результат. И это страшный тормоз в итоге, проверено многократно. Поэтому, никакого чтения/записи по смещению быть не может, нужна честная побайтная сериализация/десериализация. А вот уже как побайтно разбирать стрим — тут уже можно оптимизировать, например, читать за раз из памяти выровненные 8 байт в 64-хразрядной аритектуре и САМИМ жонглировать затем байтами уже сугубо в регистрах проца. Тоже ведь это всё далеко от уровня абстракции Джавы, верно?
V>>В общем, что в джаве до сих пор нет value-типов — это серьезный косяк, как по мне. ·>Да, не удобно. Всякиеп proposals постоянно висят, но это не так всё просто — каким образом оно скажется на оптимизатор и сборщик мусора...
На них как раз несильно скажется, чуть усложнится логика БЕЗ потери быстродействия. Тут больше засада в изменении системы типов в самой VM. А это будет больно. Очень больно.
V>>Тут несколько лет назад был знатный срач по дотнету, где я просто показал эффект от уменьшения косвенности всего вдвое — там быстродействие подскочило в 2.4 раза. V>>Некоторые коллеги высказали мне кучу "фе" за эдакое "байтодрочерство", но факт остаётся фактом — управляемые среды так мощно сливают нейтиву в том числе из-за чудовищной лишней косвенности. КАЖДАЯ коллекция объектов дотнета или джавы — это сразу ТРИ уровня косвенности: сама коллекция является ref-типом, внутри себя содержит ref-array, который внутри себя содержит ref-объекты. В нейтиве в таких сценариях зачастую один уровень косвенности или даже ни одного (если с ограничением на макс. размер коллекции). ·>Да, это недостаток управляемых сред, но бенефиты нередко значительно перевешивают этот недостаток.
Да я же не против, хосподя.
Но мы же здесь и сейчас говорим о сфере наилучшей во всей IT-индустрии эффективности, об HFT.
Понимаешь, область HFT — это область малого кол-ва сложных задач, по-сути. А управляемые среды, наоборот, хорошо себя показывают в реализации систем, где решается огромное кол-во простых, т.е. в системах с большой суммарной информационной сложностью. HFT явно находится не в этой области.
Здравствуйте, ·, Вы писали:
·>LL-тред не блокируется, тем более на IO, он крутит busy spin пока отсутствуют данные во входящем сетевом буфере. Да, процессор жжот.
На серверной стороне это невозможно в принципе. Вот у тебя тысяча клиентов висит, а ядер всего 32. Твои действия?
Здравствуйте, Ikemefula, Вы писали:
Ф>>>Почти не зависит: чтобы это было возможно, нужно чтобы СУБД все свои действия сразу писала на диск. А на практике оно чаще всего откладывает запись (доступ к диску так оптимизируют) C>>ЩИТО? I>Где, по твоему, БД хранит буфер транзакций и в какой момент она его сбрасывает на диск ?
В журнале. И естественно, с гарантией записи (журнал сбрасывается fsync'ом перед коммитом).
Ф>>>да и сама запись не мгновенно происходит, и это не атомарная операция — это во-первых. C>>Атомарная. I>Похоже, вы про разные вещи говорите.
Операция "перемотать указатель на текущее состояние" — атомарна.
Ф>>>А во-вторых часть данных может писаться не в БД, а в файлы, которые лежат рядом... C>>А это не проблема БД. I>Спасибо, капитан. Это проблема юзера — старые файлы повреждены, новых нет. Что делать ?
Использовать CoW-системы, которые не меняют данные в старой версии. Например, BTRFS.
Здравствуйте, vdimas, Вы писали:
V>·>Обеспечивать качество и стабильность проще с управяемыми средами. В общем есть свои достоинства, причём тут бедность?.. V>Потому что всё имеет свою цену. V>Почему медиакодеки до сих пор нейтивные? V>Неужели задачи обработки ордеров сложнее обработки медиа? ))
Они специфичные — битодробилки и строгие (или не очень) доказательства что нигде не выходит за границы массивов. К кодекам не предоставляется таких требований надёжности. Пропажа или искажение пары кадров из видео никто не заметит, а всякие глюки в играх чуть ли не рекламой являются — о, какой прикольный глитч в очередной игрушке — смотрите, корова летает.
Пропажа одного ордера — можно попрощаться с бизнесом.
Кодеки пишутся один раз и на всегда, по строгим продуманным стандартам. Биржы постоянно догоняют друг-друга по фичам.
V>>>Потому что JNI принципиально идёт там, где требуется эффективность, иначе он НЕ нужен. V>·>Он идёт в основном там, где есть что-то системнозависимое. Конечно, может быть есть какие-то числодробилки, типа видеокодеков, но тоже непонятно откуда там возьмётся сложный JNI — отдал массив байт, забрал массив байт. V>Во многих АПИ-вызовах или нейтивных либах параметры бывают чуть сложнее, чем массив байт.
А бывают и не сложнее. В общем ценность и необходимость JNI ты преувеличиваешь основываясь на своём опыте с С++CLR или как он там. V>·>Подавай что-то более удобное, массив байт, например. В общем бывают всякие ситуации, но далеко не всегда требуется весь ужас которым тут меня ты пытаешься запугать. V>Да, целые структуры маршаллятся БЕЗ лишнего копирования через тормозной reflection, просто передаются по ссылке. Кароч, в плане интеропа с нейтивом джава дотнету не конкурент ни разу.
Ну и нафиг, да и необходимости нет такой. С учётом того, что Ява бегает на всех платформах, это довольно сложно реализовать, в отличие от win-only c#, да и там он необходим, чтобы MS мог свой легаси код хоть как-то тащить.
V>>>Тут проблема в разрыве второго рода. В джаве так любят рефакторинг, что от малейшего чиха затем твой собственный JNI начинает затем тупо бегать по памяти. )) V>·>В джаве любят хорошее покрытие тестами. Пусть бегает, дальше первого же прогона тестов не убежит. V>Пробежка по памяти никакими тестами может быть и не отловлена, потому что в случае тестирования, скажем, мы могли бегать по какой-нить свободной, но закомиченной странице памяти, а в реальной приложухе затем можем убежать куда угодно.
Есть и perf test, и staging с проигрыванием prod-данных, расстрелы памяти поймаются.
V>>>И с отладкой там ж-па, потому что из нейтивного отладчика не видно, правильно ли дергаются методы и поля джавовского объекта. Со студией в плане одновременной отладки нейтивного и дотнетного кода тут не сравнить. V>·>Можно и оба отладчика подцепить одновременно — ява и нейтив. V>Жесть. )) V>Ты часто так делал? V>Понравилось?
Один раз, ради любопытства, под линухом. Ничего осбенного. И нафиг не нужно.
V>·>Не знаю, мне вообще не приходилось клепать навороченные JNI, обычно это тонкие обёртки над нативными либами или обращение к какой-то простенькой системной api. V>Обертки-то тонкие, а кода немеряно на пустом месте. И сам код — сплошной птичий язык. )) V>Да чего тут упорствовать-то, оно как есть так есть.
В общей сложности этого наверное тысяча строк.
V>Речь не о яве, а о решаемых задачах. Да, прототипы я писал не под Яву. V>Да, на управляемых средах на коленке можно банально быстрее что-то сляпать и посмотреть результат эксперимента. V>Хотя, после покупки последнего Решарпера для С++, похоже, этот период моей жизни уже окончательно в прошлом. )) V>Дотнет, похоже, останется у меня только для GUI-утилит.
Угу. Ещё один камень в огород c#.
V>>>Ну так матчить ордера в нейтиве еще эффективнее. Это же просто "плоские" структуры в памяти, в случае нейтива. V>·>Так говорю же. Жестких LL сервисов всего пара — EV и EMS. А обвязки вокруг этого ещё штук 40 сервисов, включая пост-трейд проверки, генераторы отчётов, архиваторы данных, субд, http client/server, и т.д. и т.п. Гораздо удобнее когда оно всё написано на одном языке и прозрачно взаимодействует друг с другом, чем мешанина кучи технологий. Или ты предлагаешь веб-приложения тоже на нейтиве лабать? V>Я уже отвечал на это — внутренние утилитные задачи сейчас всё чаще делают на скриптах/вебе. Это банально универсальнее, один и тот же язык (скрипт) на клиенте и сервере. Сейчас под node.js чего уже только нет. И отчеты генерят зачастую через XSLT, сейчас развелось уже WYSIWYG-редакторов и для него, т.е. задача из элитной перешла в разряд для новичков.
Жуть. Ф топку этот зоопарк.
V>>>Поэтому вычисления в джава вдвое сливали после выхода дотнета, угу. V>·>И именно для этого дотнет без нативного нутра не используется? V>Опять троллинг. Я хочу знать, откуда ты взял, что Джава в целом быстрее дотнета?
Я этого не утверждал, тем более "в целом". Я утверждал максимум, что тайминги быстрее в LL.
V>Да, порой приводились еще какие-то совсем редкие сценарии, где Джава была чуть-чуть быстрее, но они погоду не делали, скорее, наоборот — своей редкостью лишь подтверждали правило.
Я сейчас не про скорость, а про latency.
V>>>Ну это уже троллинг как он есть. Без комментариев. )) V>·>Пару минут прогретый код почти весь компилируется. V>Ааа... Ты просто не понял. JIT-компиляторы рождают хреновый неоптимизированный код, что в Джаве, что в Дотнете. И это непреодолимо, потому что им некогда. Поэтому я и указывал на доступность изкаробки для дотнета быть скомпиллированным в хорошо оптимизированный нейтивный бинарник. Да, будет потрачено некоторое время на компиляцию и оптимизацию, но это же однократная задача, по-сути, только по время сборки релиза.
В дотнете — не спорю. С Джавой — не так уверен. В рантайнме больше данных для оптимизации, чем в во время компиляции, а времени можно выделить достаточно.
V>>>Да какая разница? Каждое строковое значение — это отдельный объект в хипе. V>·>Не используйте строковые значения. Есть даже интерфейс CharSequence. Ну или даже char[]. V>char[] ничем не лучше строки.
Он мутабельный, отлично живёт в gen2.
V>·>А если так нужны строки — их можно и в пул сложить. V>Иммутабельные объекты в пул. V>Оригинально.
Ээээ. По сути мапа <variable length string -> long>
Да и строк в финансовой инфе мало. Всё заменяется на id.
V>>>Ты мне не ссылки давай, а просто ответь: может ли джава-машинка гарантировать, что каждый её логический поток будет в течении всей своей жизни выполняться на одном и том же потоке ОС? Потому что везде строго предупреждают об обратном. V>·>Общий стандарт явы — нет, но данная реализация машинки для данной инфраструктуры — да, может гарантировать. V>И какая из реализаций Джава-машинки это гарантирует?
Все известные мне реализации так делают. Вроде были какие-то с зелёными тредами давным давно, может ещё какие-нибудь экзотические, типа под мобильные платформы, хз.
В любом случае, можно скачать исходники, посмотреть и убедиться — будет 100% гарантия. Да, де-юро это не так, но де-факто именно так.
V>>>Пффф... ну тогда можно строить произвольные предположения об "эффективности Джава". Тут уже сколько фантазии хватит. V>·>У меня есть примеры когда ява используется как основной язык LL-системы. А шарп в лучшем случае как нашлёпка над нейтивом. Этого достаточно, конкретные цифры не так важны. V>Ну я-то прекрасно понял ход твоих мыслей, просто с моей колокольни это выглядит забавно, когда человек по конечному результату пытается восстановить ход работ. И вдвойне это забавно после того, как я указал на все причины, а именно — в дотнете нет смысла делать иначе, потому что это ОЧЕНЬ дешевый для дотнета способ, в отличие от джавы. Т.е., писать максимально-эффективные решения на pure .Net можно только из спортивного интереса и исключительно за свой счёт, бо это будет обман инвесторов. Например, наша дотная обертка написана на C++/CLR и мне сложно на словах передать всю бесконечную гамму удобств такого подхода в сравнении с JNI.
Это я уж понял. От .net там только название и фантик, ну и свечку приходится ставить, чтоб не дай боже гц сработал.
V>>>·>Но в любом случае Fix gateway не самый быстрый и важный компонет биржи, да и дистрибьютится он на ура. V>>>На стороне клиента и сервера важна связка ордера и соответствующего сетевого сообщения. Т.е., FIX-движки (а часто FAST-кодирование или аналогичное сверху) — они не вещи в себе, они должны обеспечивать именно такую связку. V>·>От сетевого сообщения там нужен только sequence number для связки. Порванная из-за проблем в сети сессия может восстановиться на другом сервере с другим клиентом. V>Мы на разных языках разговариваем. У нас представление FIX-сообщения в памяти и сетке идентично, т.е. мы тупо пихаем тело сообщения в сетку и точно так же принятый блоб без изменений хранится в памяти, просто будет размечен индексами при парсинге. Для джавы такой подход — недостижимый хайтек, потому и результаты более чем на порядок отличаются.
И что запрещает то же самое сделать в java? Где я сейчас работаю — именно так и сделано (правда код — жуть, написан >10 лет назад).
V>Для Rapid и B2BITS: V>Для OnixS:
Ок, посмотрю.
V>>>А все эти брокерские конторы — они же клиенты и есть. V>·>Так у них там UI в основном... какой там LL?.. V>UI — это всякие утилиты для декларирования стратегий и обзора происходящего. V>Торгуют-то роботы с микросекундными задержками. Какое там уже в опу UI? ))
А где эти боты торгуют по-твоему? Все ломятся на тот же самый lmax exchange.
V>·>Ты что-то не то смотришь. Это просто перф-тест для juc queue, для сравнения. V>Я смотрю именно то — тест быстродействия в сценарии один-ко-многим. Очень популярно в сценарии "сливания" данных для обработки из разных UDP-каналов, например.
ЭТО ТЕСТ java.util.concurrent.BlockingQueue!!! Это тесты для сравнения производительности стандартных JDK-классов с дизраптором, они специально размещены в отдельном фолдере perftest/java/com/lmax/disruptor/queue/. Посмотри внимательно на импорты и найди там классы дизраптора, если сможешь.
V>·>В дизрапторе используется ring buffer преаллоцированных объектов (то самое 2-е поколение), к которому магией обеспечивается эксклюзивный доступ из всяких разных тредов. V>Ой, магия. ))
Да шучу я с магией, просто атомарные lock-free счётчики.
V>Мне по работе как раз положено такую "магию" придумывать и доводить до совершенства. В нейтиве, ес-но. V>Поверь, я прекрасно отдаю себе отчёт, на какой именно тест дизраптора я дал ссылку.
Может ты просто со ссылкой ошибся. Или не вникал.
V>Просто ты в такой низкий уровень не лезешь, судя по твоим комментам.
Ты просто не понял что дал.
V>>>Тут фишка в том, что объект в джава (я испытывал оракловую), будучи "потерянным" текущим потоком, перестаёт быть объектом 0-го поколения. По-другому объяснить наблюдаемое я не мог, бо если пихать в очередь того же самого потока, то всё в джаве пашет гладко. V>·>Хз, не знаю, много разных объяснений. Может escape analysis мутит или Thread Local Area. В любом случае, это не самый лучший подход для организации многопоточности. V>Не самый лучший в джава?
Везде.
V>Поверь, качественная перекачка данных из потока в поток — это ноу-хау каждой конторы, которая делает подобного рода решения — обработку сумасшедших потоков данных в реалтайме. Хорошо оттюненный конвейер data-flow перемалывает в секунду до миллиона ордеров на каждой паре системных потоков. Для джавы это всё недостижимо, ес-но.
Хз что и как считать. Тут 25млн https://github.com/LMAX-Exchange/disruptor/wiki/Performance-Results
V>Просто такая фишка — в самых загруженных сценариях вовсе не требуется будить обрабатывающий поток, он и так работает. Ну и грамотно выстроенная стратегия "батчей" ордеров что при приёме, что при отсылке, что при межпоточной передаче — наше всё. По-сути, трудоёмкость обработки каждого ордера в нейтиве — это сотни наносекунд (редко больше полутора микросекунд). Всё остальное время тратится как раз на системные вызовы ОС. Сумеешь минимизировать их кол-во, а лучше вообще их избежать (кроме вызовов сетевого АПИ с коэффициентом размножения 1 вызов на 100-200 ордеров) — и ты победишь.
Это не означает что надо плодить мусор и мусор в таком случае хоть чем-то помешает. Фишка ордеров, что они примерно фиксированного размера.
Если я правильно помню, в плюсах вообще создание удаление из общей кучи может блокироваться, а потом ещё фрагметация кучи и прочие радости. Т.е. даже в плюсах такие вещи пишутся со специальными аллокаторами и другими техниками, позволяющими переиспользовать буферы, вместо "классического" malloc/free new/delete.
V>>>А ведь, казалось бы, data flow в этой области надо вылизывать еще на уровне концепта максимально тщательно, а не применять стандартный джавовский подход: наколенный эксперимент -> рефакторинг -> продакшен. ))) V>·>Ну может быть какой-нибудь nasdaq и может вылизывать годами, но не все это могут себе позволить. V>Потребовалось пол-года и 3 нейтивных программиста, чтобы вывести продукт в топы. V>Т.е. слухи о дороговизне нейтивной разработки на деле сильно преувеличены.
Сложности разработки LL на java по сравнению просто гигантски преувеличены.
V>>>С байт-буфером будет сериализация-десериализация на каждый чих. V>·>Данные обычно плоские и фиксированной ширины. Просто обращаешься по фиксированным смещениям, сериализация тривиальна и быстра. V>Ну вот, ты опять показал невладение темой. Что происходит в железе, если мы читаем, например, невыровненное 32-хразрядное слово в 32-хразрядной архитектуре? (или 64 в 64 аналогично?) V>Так вот, происходит прерывание "ошибка адресации", где обработчик прерывания сначала разбирается, на какой машинной инструкции идиот-программист полез в память, потом достаёт данные нужной ширины (согласно разобранной инструкции) побайтно, собирает эти байты в целевой регистр и возвращает результат. И это страшный тормоз в итоге, проверено многократно. Поэтому, никакого чтения/записи по смещению быть не может, нужна честная побайтная сериализация/десериализация. А вот уже как побайтно разбирать стрим — тут уже можно оптимизировать, например, читать за раз из памяти выровненные 8 байт в 64-хразрядной аритектуре и САМИМ жонглировать затем байтами уже сугубо в регистрах проца. Тоже ведь это всё далеко от уровня абстракции Джавы, верно?
Это ты в c# регистрами жонглируешь?? Регистры проца и в C недоступны, не выдумывай. Верно, Ява по стандарту не предоставляет direct memory access, а при чтении из того же ByteBuffer может только атомарность нарушаться, что никак не беспокоит при однопоточном доступе к буферу текущего евента. В любом случае последовательное побайтное чтение килобайтного буфера не нужно. Можно сразу прыгать на нужные позиции данных.
И все эти проблемы уровня наносекунд, что далеко до микросекунд какого-нибудь сетевого обмена.
V>>>В общем, что в джаве до сих пор нет value-типов — это серьезный косяк, как по мне. V>·>Да, не удобно. Всякиеп proposals постоянно висят, но это не так всё просто — каким образом оно скажется на оптимизатор и сборщик мусора... V>На них как раз несильно скажется, чуть усложнится логика БЕЗ потери быстродействия. Тут больше засада в изменении системы типов в самой VM. А это будет больно. Очень больно.
Не то, что больно, а то чтобы это хорошо подружилось с текущими фичами.
V>Понимаешь, область HFT — это область малого кол-ва сложных задач, по-сути. А управляемые среды, наоборот, хорошо себя показывают в реализации систем, где решается огромное кол-во простых, т.е. в системах с большой суммарной информационной сложностью. HFT явно находится не в этой области.
Java достаточно хороша, чтобы решить и малое количество сложных задач hft (пусть и не идеально) и огромное кол-во число простых задач, т.е. именно то, чем является типичная hft-система в целом. В этом и ценность. C# же не может решить это малое количество, да и не сильно выделяется в остальном.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
И давно у тебя создание да пробуждение потока стало дешовой операцией ? 
