Pull to refresh

Comments 27

В итоге получается, что проще подпилить в нужных местах Java, чтобы она работала достаточно быстро, чем делать всё с нуля и очень долго на С++

так а что в итоге сложнее: придумать оптимальный код и написать его на с++ или заставить JVM сгенерировать тот же самый код?
Лично мне проще написать какое-то узкое место на С++. Но код состоит далеко не только из таких критичных кусков. Итого, если говорить про конкретные участки кода — лично мне проще сделать из на C++. Но если говорить не только про эти супер-критичные куски то проще и быстрее сделать на Java а потом допилить до требуемой производительности, ИМХО

Ну вот как так? Конференция завтра а обьявление о ней читаю сегодня. Как к вам блин за сутки то добраться через пол земного шара?

А если бы заранее сделали бы анонс на хабре — приехали бы?))
Вообще, JUG.ru делали почтовую рассылку

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

На сколько я понимаю, да, видео должно быть. Как узнаю точно — напишу.
Мы подумали и мне точно помогут с расшифровкой доклада. Так что в любом случае мы опубликуем расшифровку на хабре.

Вы пишете интересные статьи, но в них немного не хватает конкретных цифр.


Low latency — это сколько? Из личного опыта, разные люди отвечали на этот вопрос с разницей в три порядка (если брать исключительно Java)

Это смотря откуда и до куда мерять эту latency.

Хороший вопрос)) я бы подошел к этому вопросу немного с другой стороны. Мне кажется, что критерии soft real time (большие материальные потери при не выполнении SLA) ~ latency-sensitive. А low-latency зависит от сложности алгоритмов, выполняющихся при реакции системы на внешний раздражитель. Т.е. для HFT, которые арбитражат стаканы биржи low-latency это одно, а для тех, у кого пересчитываются сложные модели, low-latency — совсем другое.
10-20 микросов это уже low-latency
в java недоступны некоторые техники, например, блокировка блоков виртуальной памяти в физической памяти, поэтом всегда возможен уход в swap
Достаточно отключить swap на сервере.
Ну то есть не совсем отключить, но поставить swappiness = 0
интересный вариант, а что будет, если дойдет до конца памяти?
Ну если у вас не хватит памяти на сервере, то какая разница из-за чего ваше приложение встанет, из-за того что свалится или из-за того, что уйдет в своп? Для такого типа сервисов и то и другое примерно эквивалентно.

Кроме того, jvm можно ограничить объем памяти, который она будет использовать (с оговорками), так что можно просто xmx поставить меньше, чем физически памяти есть.
Тогда третий вариант — процесс упадет с OutOfMemoryError.
Прежде, чем делать многопоточность надо хорошо подумать над архитектурой.
Инструкция процессора, выполняющая CAS работает раз в 20 медленнее, чем простое присваивание. Плюс многочисленные библиотеки грешат тем, что во многих местах стоит синхронизация. Иногда один поток может выполнить намного операцию быстрее, чем во многих потоках. Я предпочитаю иметь несколько однопоточных изолированных процессов и еще один процесс, который кушает результат их труда и раздает задания.
Интересны ваши секреты про маркетдата (и борьба с GC) и де/сериализацией сообщений во всяких протоколах типа FIX, etc. Да и какие структуры используются для портфолио. А в теории в принципе все равны — и там и там инструмент надо знать, хоть C++ хоть Java. Но что-то подсказывает что секретов вы раскрывать не можете :)
Я даже не знаю, как ответить. NDA ;-)
нам приходится заниматься всем стеком, задействованным в торговле: приватными сетевыми каналами, специальным аппаратным обеспечением, настройками ОС и специальной JVM


А что за JVM? В чем отличие от open source брата?
мы используем специальную JVM, которая ускоряет warm up
А чем вы торгуете, если не секрет? FX?

Статью прочитал, но о чем она? Реклама конференции? Воды много, конкретики мало.

Sign up to leave a comment.