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

V>·>В какой клиентской проге? HFT для роботов, а не для человеков.
V>Роботов надо удобно программировать в GUI и отслеживать текущую картинку.
V>Ну и "большая красная кнопка Stop" — как же без неё? Вот тебе и графический декодер большой красной иконки. ))
С иконкой вряд ли сможет случиться беда, незамеченная на этапе разработки, ибо это константная картинка. Вот какие-то генерируемые по текущим данным графики, да...

V>Ну и клиентское биржевое приложение не сильно в плане многопоточности отличается от серверного — у нас есть клиенты, которые создают многие десятки (до двух-трех сотен) подключений одновременно.
Да, но микросекундные задержки рояли не играют, всё что меньше 1 секунды — никто не заметит. Да и подключения, как правило, куда угодно по миру, вплоть до пингов в сотни миллисекунд.

V>·>А любые клиентские проги в HFT не важнее как Оутлука.
V>Важность для каждого отдельного клиента просто катастрофическая.
Как и Оутлука или какого-нибудь news-фида.

V>·>Потом, сравни JPG-кодек, созданный много лет назад и не меняющийся с тех пор, отлаженный, перелопаченный просмотренный и тп., и какую-нибудь очередную секретную алго-фичу, которую нужно срочно запилить до вчера.
V>Во-первых, сам JPEG меняется, как и MPEG. Во-вторых, реализации меняются.
Когда последний раз менялся стандарт JPEG? И сколько раз за свою жизнь?

V>В третьих, ЛЮБЫЕ "алгофичи" торговых роботов задаются как композиция базовых стратегий/операций/условий, т.е. фактически декларативно из небольшого набора простых отлаженных кирпичиков.
Сам ведь знаешь, что сложность композиции компонент не означает простое сложение их сложности.

V>>>Летающая корова не противоречит законам физики, если из скрипта ей задали параметры как у воздушного шарика. ))
V>·>Всяко бывает. В старых играх без скриптов глитчей не было? Что ты хочешь доказать-то? Игроделы — идиоты, должны выкинуть скрипты и писать на Плюсах?
V>По опыту того же CS (был грешен лет 15 назад), глитчи были в основном в картах (игровых уровнях), т.е. в данных, а не в коде.
Ты среднюю температуру по больнице посчитай. И как скоро и как часто выходят патчи после первой версии какой-либо игры.

V>>>Да нормальный аргумент. Если имеем исключение при выходе за диапазон, то это не значит, что прога стала работать лучше. Всё-равно нужную операцию совершить не удастся.
V>·>fail-fast — важный критерий оценки качества.
V>Та блин, я тебе как раз привел именно такой пример — необходимо снять ордера с торгов, а операция совершается с ошибкой.
А я имею в виду, что гораздо хуже, когда операция завершается "успешно", но делает хрен знает что, из-за того, что итератор куда-то не туда убежал. И обнаруживается это сильно потом.

V>Я ж не думал, что мне надо всё пояснять до самого конца, а именно — если ты вышел из клиентского приложения (джавовское fail-fast), это НЕ значит, что твои ордера перестали торговаться на бирже (для системы в целом нет никакого fail-fast).
Если GUI глючит, обычно можно позвонить в саппорт и попросить снять ордера.
В общем какая-то гипотетическая ситуация с гипотетическими проблемами, не хочу фантазировать и спекулировать.

V>>>Однако, в С++ принято бегать итераторами по коллекциями.
V>·>И что? Какая разница?
V>Убежать за границы сильно сложнее.
Почему? std::vector<int> с итераторами ничем по защищённости не отличается от int*. Можно, конечно at() использовать, но редко наблюдал на практике...

V>>>>>И это я еще не даже не начинал спрашивать, где ты видел в плюсах выходы за границы. Не в С, а именно в С++. Мне было бы ОЧЕНЬ любопытно взглянуть на пойманную такую хрень в реальном коде, это была бы сенсация.
V>>>·>Разве оператор std::vector[] проверяет границы в проде? Или вы боитесь делать релизные сборки?
V>>>А разве кто-то использует индекс в векторе вместо итератора?
V>·>Ты хочешь меня обмануть, надеясь, что я Плюсы не знаю? Итераторы за границы могут выходить на ура
V>Так и ты в свой байт-буфер может мимо написать, в отсутствии статической типизации.
V>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().
В каких? Кто сравнивает? std::vector — не сравнивает.

V>>>Про ценность JNI. Выглядит так, что ты еще не сильно любопытствовал устройство многих джавовских системных библиотек, которые поверх JNI писаны. Вот как полюбопытствуешь, так приходи.
V>·>Да, это полный кашмар! Но это ещё не всё, я тебе открою страшную тайну: java на Плюсах написана.
V>Сам движок? Ну так это совсем другое дело. Например, Java-машинка знает многие базовые джавовские типы "в лицо" (string, array и т.д.) и обращается с ними вполне типизированно, т.е. безопасно и эффективно — через типизированное отражение их разметки в памяти на соответствующие нейтивные структуры. Это на психику не давит, в отличие от нейтивного АПИ динамической типизации Джава-машинки. Вот как раз писать и читать из ByteBuffer, эмулируя "плоские структуры", — примерно того же уровня задачка. Т.е. всё держится на честном слове, а не на контроле компилятора.
Нет, String это обычный plain-java класс поверх "char[]", ArrayList — тоже, поверх Object[]. Нативные штуки там есть для работы с примитивными типами данных "char[]" (типа System.arraycopy), "Object" и системными штуками типа FileSystem и т.п.
В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.

V>·>Я понял что ты говоришь, но ты, похоже, не понял моё возражение. Первое твоё предложение верно, второе — нет. HFT-система — большое число простых задач + небольшое число сложных.
V>Да не понял ты меня. Я говорил, что твоя оценка насчет "большое число" — неверная. Число задач в HFT относительно небольшое. Относительно тех же программ для складов/бухгалтерий. Просто довелось несколько лет работать в области автоматизации предприятий и я хорошо знаю, о чем говорю. Например, в типичной снапшотовой БД огромнейшей популярной биржи будет примерно 3-4 десятка таблиц всего, в то время как в самой несчастной бухгалтерии+складе — примерно 3-4 сотни. А если система учета не несчастная, а вполне себе на уровне, то и до тысячи таблиц и выше аж бегом.
Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы.

V>·>HFT-система это например биржа. Там 2-3 сервиса жесткий HFT — сложная задача, а остальные пол сотни — всякая шелуха, куча простых задач.
V>Пол-сотни — это ни о чем от слова совсем. Когда в базе или в прикладном коде одних прикладных запросов несколько тысяч, вот это уже хоть какая-то информационная сложность.
И даже с этой полусотней работать проще из Java чем из native.