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

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

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

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

Я рядом уже давал ту инфу, что крупнейшие брокеры размещены физически близко в бирже. Чаще всего — в одном здании и имеют доступ по локальной сетке к торгам. Там +- одна микросекунда уже влияет, а не секунда. ))


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

Да ладно, если тебе письмо вовремя не дошло, то это редко бывает проблемой. А если ордера вовремя не снял, то потерять десятки-сотни тыщ за один день можно запросто.


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

JPEG-LS, JPEG XR — относительно новые.


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

Когда речь идёт о выходе за границы диапазона неких массивов, то это не важно. ))


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

Ну вот как раз в данных и патчат более всего.

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

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


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

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


V>>Убежать за границы сильно сложнее.
·>Почему? std::vector<int> с итераторами ничем по защищённости не отличается от int*.

На практике отличается сильно.
— пробежка "ручками" обычно идёт по итераторам;
— 99% алгоритмов над вектором никакими ручками не делаются, заполнение через всякие input_iterator, обработка через пару итераторов (раньше) или напрямую сейчас (boost::range).

Ну т.е. доступ к элементам вектора по индексу — это что-то из ряда вон выходящее и причина обратить внимание на происходящее.


V>>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().
·>В каких? Кто сравнивает? std::vector — не сравнивает.

Любой алгоритм сравнивает два итератора.


·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.

Дык, уровень косвенности на единицу меньше.


·>Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы.

90% кода типичной HFT-системы не требует вообще ничего из того, что дают управляемые среды.
А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но.


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

Давнее заблуждение, родом из 95-го года, когда объем библиотек в поставке джавы натурально поражал воображение. ))
Сейчас библиотек под С++ уже просто тонны под все случаи жизни.

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

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

Я рядом уже давал ту инфу, что крупнейшие брокеры размещены физически близко в бирже. Чаще всего — в одном здании и имеют доступ по локальной сетке к торгам. Там +- одна микросекунда уже влияет, а не секунда. ))


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

Да ладно, если тебе письмо вовремя не дошло, то это редко бывает проблемой. А если ордера вовремя не снял, то потерять десятки-сотни тыщ за один день можно запросто.


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

JPEG-LS, JPEG XR — относительно новые.


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

Когда речь идёт о выходе за границы диапазона неких массивов, то это не важно. ))


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

Ну вот как раз в данных и патчат более всего.

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

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


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

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


V>>Убежать за границы сильно сложнее.
·>Почему? std::vector<int> с итераторами ничем по защищённости не отличается от int*.

На практике отличается сильно.
— пробежка "ручками" обычно идёт по итераторам;
— 99% алгоритмов над вектором никакими ручками не делаются, заполнение через всякие input_iterator, обработка через пару итераторов (раньше) или напрямую сейчас (boost::range).

Ну т.е. доступ к элементам вектора по индексу — это что-то из ряда вон выходящее и причина обратить внимание на происходящее.


V>>Там всей разницы, что у тебя при этом никаких проверок, а в контейнерах, таки, итератор сравнивают на end().
·>В каких? Кто сравнивает? std::vector — не сравнивает.

Любой алгоритм сравнивает два итератора.


·>В Шарпе да... даже банальный string.cs это сплошной треш, угар и unsafe. Гы.

Дык, уровень косвенности на единицу меньше.


·>Да не важно, даже с 3 таблицами работать удобнее из Java чем из native. 300 таблиц не является необходимым минимумом для того, чтобы управляемая среда начала рулить. Она рулит практически везде, где не требуется мощное числодробление и бито-жонлгирование — и это, как минимум, 90% кода типичной HFT-системы.

90% кода типичной HFT-системы не требует вообще ничего из того, что дают управляемые среды.
А вот 90% кода действительно сложной учётной системы — уже требуют, ес-но.


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

Давнее заблуждение, родом из 95-го года, когда объем библиотек в поставке джавы натурально поражал воображение. ))
Сейчас библиотек под С++ уже просто тонны под все случаи жизни.