Мне кажется архитектура — не совсем системно правильная конструкция. Т.е. все, что описано выше — опирается только на good will людей. Но у людей нет мотиваторов делать правильно/неправильно. Архитектура не несет риск от принятых ими решений. И то выражается в том, что крайне сложно архитектурным подразделениям поставить хоть какие-то цели/kpi.
ну понятно же, что автор имеет в виду разницу во времени отправки первого и последнего ордера. Идеальная картина мира — все отправляется в один момент времени, но в реальности будет небольшая разницы во временах отправки, это и названо дисперсией. На мой взгляд, сравнение достаточно уместно здесь
Хороший вопрос)) я бы подошел к этому вопросу немного с другой стороны. Мне кажется, что критерии soft real time (большие материальные потери при не выполнении SLA) ~ latency-sensitive. А low-latency зависит от сложности алгоритмов, выполняющихся при реакции системы на внешний раздражитель. Т.е. для HFT, которые арбитражат стаканы биржи low-latency это одно, а для тех, у кого пересчитываются сложные модели, low-latency — совсем другое.
Лично мне проще написать какое-то узкое место на С++. Но код состоит далеко не только из таких критичных кусков. Итого, если говорить про конкретные участки кода — лично мне проще сделать из на C++. Но если говорить не только про эти супер-критичные куски то проще и быстрее сделать на Java а потом допилить до требуемой производительности, ИМХО
Интересный момент, как влияет использование try-with-resources на скорость работы сгенерированного кода. В С++ компиляторах раньше при включении исключений некоторые оптимизации просто отключались.
тут вопрос не в том, что медленнее, а в том, что предсказуемей, т.е. если на критическом пути market date'ы плодить объекты, то GC рано или поздно случится. Получается мы теряем некоторый throughput ради предсказуемого правого хвоста распределения.
Я боюсь, что даже те, кто знает ничего не скажут. Если интересно, есть хорошие мануалы от Agner Fog, которые лучше публичной документации некоторых компаний.
«Не раз встречал мнение, что однажды ушедших обратно в компанию принимать нельзя. Это бред, миф и глупость.» — на сколько я знаю, в Акронисе именно так…
Зашел на сайл CLion. Раздел «What’s New in CLion 2017.1». Пункт — «Disassembly view». о_О чего же еще там нет, раз простой disassembly и тот только что появился…
Как же тогда связать CLion с autotools или plain Makefiles? И может ли работать CLion через ssh + screen/tmux? На сколько понимаю, по обоим пунктам — ответ отрицательный.
Разрешите не согласиться на счет С++ «прозрачный».
Поясню: В Java достаточно строгий контроль типов и нет явно вычурных синтаксических конструкций. В С ++ же даже простое выражение «a || b && c» может выполняться совершенно по разному, если a, b, c — интегральные типы или классы с перегруженными операторами. Плюс, без отладчика, дизассемблера, совершенно не понятно, что будет выполняться, т.е. читать код достаточно сложно (ну, или как минимум, лщутимо сложнее, чем код на Java). Про неявное создание объектов в С++ даже говорить не буду…
Но да, именно С++ позволяет оперировать любым уровнем абстракции: от ассемблера до лямбд. И не смотря ни на что, именно этот язык мне нарвится больше всего.
Вообще, JUG.ru делали почтовую рассылку
Мне тоже в С++ очень импонирует, что все можно выразить в терминах инструкций железа и адресов памяти.
Поясню: В Java достаточно строгий контроль типов и нет явно вычурных синтаксических конструкций. В С ++ же даже простое выражение «a || b && c» может выполняться совершенно по разному, если a, b, c — интегральные типы или классы с перегруженными операторами. Плюс, без отладчика, дизассемблера, совершенно не понятно, что будет выполняться, т.е. читать код достаточно сложно (ну, или как минимум, лщутимо сложнее, чем код на Java). Про неявное создание объектов в С++ даже говорить не буду…
Но да, именно С++ позволяет оперировать любым уровнем абстракции: от ассемблера до лямбд. И не смотря ни на что, именно этот язык мне нарвится больше всего.