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

V>>>>Опять загоняешь, кароч.
V>>·>JPG-иконки и HFT? Хм... Я промолчу.
V>>В клиентской проге? Именно так.
·>В какой клиентской проге? HFT для роботов, а не для человеков.

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

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


·>А любые клиентские проги в HFT не важнее как Оутлука.

Важность для каждого отдельного клиента просто катастрофическая.


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

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


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

По опыту того же CS (был грешен лет 15 назад), глитчи были в основном в картах (игровых уровнях), т.е. в данных, а не в коде.


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

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


V>>·>Это лучше, если операцию совершить невозможно, да ещё и с громким бабахом, чем если бы совершилась втихую какая-то другая операция.
V>>Однако, в С++ принято бегать итераторами по коллекциями.
·>И что? Какая разница?

Убежать за границы сильно сложнее.


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

Так и ты в свой байт-буфер может мимо написать, в отсутствии статической типизации.
Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().


V>>·>Какие советы?
V>>Про ценность JNI. Выглядит так, что ты еще не сильно любопытствовал устройство многих джавовских системных библиотек, которые поверх JNI писаны. Вот как полюбопытствуешь, так приходи.
·>Да, это полный кашмар! Но это ещё не всё, я тебе открою страшную тайну: java на Плюсах написана.

Сам движок? Ну так это совсем другое дело. Например, Java-машинка знает многие базовые джавовские типы "в лицо" (string, array и т.д.) и обращается с ними вполне типизированно, т.е. безопасно и эффективно — через типизированное отражение их разметки в памяти на соответствующие нейтивные структуры. Это на психику не давит, в отличие от нейтивного АПИ динамической типизации Джава-машинки. Вот как раз писать и читать из ByteBuffer, эмулируя "плоские структуры", — примерно того же уровня задачка. Т.е. всё держится на честном слове, а не на контроле компилятора.


·>Я понял что ты говоришь, но ты, похоже, не понял моё возражение. Первое твоё предложение верно, второе — нет. HFT-система — большое число простых задач + небольшое число сложных.

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


·>HFT-система это например биржа. Там 2-3 сервиса жесткий HFT — сложная задача, а остальные пол сотни — всякая шелуха, куча простых задач.

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


·>Или ты хочешь сказать, что если в некой системе информационная сложность меньше бухгалтерии, то ява для такой системы будет работать как-то плохо?

Я говорю о том, где именно рулят управляемые среды.


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

Ну вот поэтому в каждой сложной системе есть как минимум два уровня — "ядерный" и "прикладной".