Comments 49
интересно, полезно — плюсую
В-третьих, компилятор Java оптимизирует программу под конкретное железо, на котором он был запущен.
Насколько мне известно — HFT-ники всё собирают там, где запускают. А там -mtune=native -mtune=native
Для всех сборщиков мусора, поставляемых с Java,
Есть еще и другие не поставляемые с ней. Для успешных торгов, в которых решаются такие проблемы.
Т.е. для подобных систем нормально остановить обработку на какой-то ощутимый промежуток времени (миллисекунды/секунды)
Секунда это довольно дофига даже на больших кучах (у нас десятки гигабайт). Не стоит забывать про всякие доп возможности ускорения GC типа ручного заnullения ссылок. Это помогает:)
Да, согласен. Но тем не менее, длительность задержки напрямую зависит от размера хипа, а он может достигать ощутимых размеров, т.е. это всего лишь вопрос времени, когда время GC также достигнет ощутимых значений.
Если говорить концептуально, то именно управление памятью — та область, где и у Java и у C++ достоинства — продолжение их недостатков.
Если говорить концептуально, то именно управление памятью — та область, где и у Java и у C++ достоинства — продолжение их недостатков.
UFO just landed and posted this here
В частности для разных generational GC, если объекты окажутся в разных поколениях, то получится быстрее. Подглядел такой трюк с описанием в исходниках JDK.
С другой стороны, если вероятность попадания в разные поколения низкая — тогда раскидывание по коду обнуления ссылок приводит к выполнению лишних инструкций.
К примеру для young generation проще скопировать малое количество живых объектов и «зачистить» всю область. Если не делать пуллинг — это должно быть дешевле (был на эту тему даже доклад).
К примеру для young generation проще скопировать малое количество живых объектов и «зачистить» всю область. Если не делать пуллинг — это должно быть дешевле (был на эту тему даже доклад).
UFO just landed and posted this here
Про переиспользование объектов — возможно мы напишем немного подробнее.
С Azul C4 не все так однозначно :-)
А хранить все в офф-хипе, я думаю, может сильно повлиять на оптимизации в JIT'е: не факт, что компилятор осилит весь alias-анализ.
Про ордера — да, такая проблема есть. Тут есть несколько вещей, которые можно подкрутить в Java: количество вызовой, после которых происходит JIT-компиляция. А вторая возможность ощутимо побороть этот аспект — использовать ReadyNow от AZUL. Эта технология позволяет сохранить информацию динамическом профиле в файл и использовать ее при следующем запуске. Т.е. warm-up сокращается очень ощутимо.
А вообще, спасибо за интересный комментарий!
С Azul C4 не все так однозначно :-)
А хранить все в офф-хипе, я думаю, может сильно повлиять на оптимизации в JIT'е: не факт, что компилятор осилит весь alias-анализ.
Про ордера — да, такая проблема есть. Тут есть несколько вещей, которые можно подкрутить в Java: количество вызовой, после которых происходит JIT-компиляция. А вторая возможность ощутимо побороть этот аспект — использовать ReadyNow от AZUL. Эта технология позволяет сохранить информацию динамическом профиле в файл и использовать ее при следующем запуске. Т.е. warm-up сокращается очень ощутимо.
А вообще, спасибо за интересный комментарий!
Кстати насчёт Azul, Клифф Клик, помню презентацию делал про современные железки. Вот она, кажется. Там он говорит, что для HFT Java удобна по многим причинам, в том числе потому что память выделяет одним большим куском.
А можно поподробнее что не так с Azul, был опыт в бою?
Сейчас кстати смотрим на Shenandoah
Сейчас кстати смотрим на Shenandoah
Так а вы пользуетесь ReadyNow? Как он себя показал?
Да даже c/c++ проигрывают железкам.
----К сожаления, для C++ нет сред разработки, сравнимых с IDEA
Вы имели ввиду IntelliJ?
Сравнивая с Visual Studio у меня есть глубокие сомнения, может развеете их ссылкой на сравнительные характеристики?
Вы имели ввиду IntelliJ?
Сравнивая с Visual Studio у меня есть глубокие сомнения, может развеете их ссылкой на сравнительные характеристики?
Ее самую. Тут дело не в сравнительных характеристиках, так как подавляющее большинство разработчиков не используют и десятой части функций современной среды разработки.
Если говорить про мои претензии к VS:
1. VS начинает сильно тормозить на больших проектах
2. Всплывающая подсказка при программировании на C++ работает фундаментально хуже, чем при программровании на Java в виду значительно большей мощности языка (нет в Java даже примерных аналогов метапрограммрования на шаблонах, макросов, перегруженных операторов '->' и '.' и многого другого).
3 VS не работает на линуксе…
Если говорить про мои претензии к VS:
1. VS начинает сильно тормозить на больших проектах
2. Всплывающая подсказка при программировании на C++ работает фундаментально хуже, чем при программровании на Java в виду значительно большей мощности языка (нет в Java даже примерных аналогов метапрограммрования на шаблонах, макросов, перегруженных операторов '->' и '.' и многого другого).
3 VS не работает на линуксе…
Delphi + Lazarus, к слову, не имеет всех этих минусов. Имея при том плюс — нативный код.
Если я правильно помню, 64-битный компилятор Delphi появился совсем недавно. И я очень сильно не уверен в качестве генерируемого кода.
64 битный компилятор появился уже довольно давно. код генерируется хороший. более того — в новых версиях уже под все основные платформы собирается, правда — с помощью llvm.
Лазарь же + fpc генерирует код сам под где-то 20 платформ. И бинарники и среда работает на линуксе без особых вопросов как по скорости так и по надёжности.
KDevelop пробовали?
По теме: знакомый как раз занимается HFT и у них как раз всё на Java но сейчас начинают потихоньку переписывать на С++, упёрлись в лимит производительности…
По теме: знакомый как раз занимается HFT и у них как раз всё на Java но сейчас начинают потихоньку переписывать на С++, упёрлись в лимит производительности…
KDevelop пробовал много лет назад. До VS тогда было еще далеко. Если приходится писать на C++, в основном использую emacs + gud-gdb; никак не соберусь прикрутить всплывающаю подсказку к Emacs'у.
Попробуйте новую, 5 версию, мы парсер на clang переписали.
https://www.kdevelop.org/
https://www.kdevelop.org/
А CLion как же?
QtCreator. Кроссплатформенный, поддерживает несколько систем сборки, два вида подсветки синтаксиса с++ (оба с недостатками, tbh). Функционал пониже студии, но и весит в 50 раз меньше.
Если я правильно помню, вм java умеет оптимизировать обращения к данным с кучи на стек (как в вашем примере с *int)
В остальном — c++ позволяют переопределять аллокаторы, используя более эффективные алгоритмы управления памятью (всё равно, оптимизировать аллокацию надо в 1-2 местах в программе). И не забывайте про link-time optimization — он позволяет и встраивать функции, и девиртуализировать
В остальном — c++ позволяют переопределять аллокаторы, используя более эффективные алгоритмы управления памятью (всё равно, оптимизировать аллокацию надо в 1-2 местах в программе). И не забывайте про link-time optimization — он позволяет и встраивать функции, и девиртуализировать
Да, IPO здорово может помочь с inline и versioning'ом. Но на практике девиртуализация случается не так часто, как хочется. Кроме того, если в некоторый момент времени девиртуализация перестанет выполняться, узнать об этом можно будет только при анализе ассемблера или на перф.тестах.
А на счет скаляризации в Java — не самая работающая оптимизация в VM, на мой взгляд. Плют такие же проблемы, что сложно отследить, когда перестает выполняться. Т.е. просто дописали код в метод А, а в методе В, вызывающем А, перестала работать скаляризация, т.к. привышен лимит на inline
А на счет скаляризации в Java — не самая работающая оптимизация в VM, на мой взгляд. Плют такие же проблемы, что сложно отследить, когда перестает выполняться. Т.е. просто дописали код в метод А, а в методе В, вызывающем А, перестала работать скаляризация, т.к. привышен лимит на inline
Что-то в моём восприятии картинка должна быть с точностью до наоборот: C/C++ — простые, но крепкие ножи; Java — сложный с кучей обёрток, C# — как изображён C++.
Ни кого ни в чём не пытаюсь убедить, понимаю, что на одни и те же вещи можно смотреть с разных ракурсов.
Ни кого ни в чём не пытаюсь убедить, понимаю, что на одни и те же вещи можно смотреть с разных ракурсов.
«простой» — это точно не про С++ :-)
Ну, скажем так, по сравнению с Java/C#, он гораздо более «прозрачный». В том плане, что мы можем работать (при желании) low-level — то, что мы пишем, то и делается. А в Java/C# мы более оторваны от low-level.
(Вообще, я бы привёл скорее такую аналогию: C — лопата; C++ — лопата с кучей усовершенствований (типа попытки сделать эргономичную рукоять) и допфич (в стиле швейцарского ножа), неидеальная и уродливая с теоретической точки зрения, но на практике для умеющего пользоваться оказывающаяся таки удобнее обычной лопаты; Java, C# — трактора (это не плохо, но это другой класс механизмов), — но на выбранной картинке я бы поставил надписи именно так, как написал выше.)
(Вообще, я бы привёл скорее такую аналогию: C — лопата; C++ — лопата с кучей усовершенствований (типа попытки сделать эргономичную рукоять) и допфич (в стиле швейцарского ножа), неидеальная и уродливая с теоретической точки зрения, но на практике для умеющего пользоваться оказывающаяся таки удобнее обычной лопаты; Java, C# — трактора (это не плохо, но это другой класс механизмов), — но на выбранной картинке я бы поставил надписи именно так, как написал выше.)
Разрешите не согласиться на счет С++ «прозрачный».
Поясню: В Java достаточно строгий контроль типов и нет явно вычурных синтаксических конструкций. В С ++ же даже простое выражение «a || b && c» может выполняться совершенно по разному, если a, b, c — интегральные типы или классы с перегруженными операторами. Плюс, без отладчика, дизассемблера, совершенно не понятно, что будет выполняться, т.е. читать код достаточно сложно (ну, или как минимум, лщутимо сложнее, чем код на Java). Про неявное создание объектов в С++ даже говорить не буду…
Но да, именно С++ позволяет оперировать любым уровнем абстракции: от ассемблера до лямбд. И не смотря ни на что, именно этот язык мне нарвится больше всего.
Поясню: В Java достаточно строгий контроль типов и нет явно вычурных синтаксических конструкций. В С ++ же даже простое выражение «a || b && c» может выполняться совершенно по разному, если a, b, c — интегральные типы или классы с перегруженными операторами. Плюс, без отладчика, дизассемблера, совершенно не понятно, что будет выполняться, т.е. читать код достаточно сложно (ну, или как минимум, лщутимо сложнее, чем код на Java). Про неявное создание объектов в С++ даже говорить не буду…
Но да, именно С++ позволяет оперировать любым уровнем абстракции: от ассемблера до лямбд. И не смотря ни на что, именно этот язык мне нарвится больше всего.
Ну, скажем так: С++ представляет собой (не совсем удачную) попытку расширить низкоуровневое до высокоуровневого (просто добавив «физическому» побольше абстракций). Java/C# же имеют или только высокоуровневое, или плохо связанные островки высокоуровневого и низкоуровневого.
Несмотря на то, что я считаю C++ очень неудачным языком, сама идея «просто добавить нижнему уровню побольше абстракций» мне импонирует гораздо больше. Так язык получается гораздо «осязаемее», ты «чувствуешь» что ты делаешь, что ли (разница как между нажимать кнопочки управления гидравлическими приводами экскаватора и физически «щупать» землю лопатой в руках — первое, может, и эффективнее, но…).
Но Ваш взгляд я тоже понимаю (просто я вижу «прозрачность» в прямой и очевидной связи low-level'а и high-level'а; а хреновый контроль типов и местами дурацкий синтаксис — это, конечно, отстой, но после привычки к ним всё равно имеешь контроль, хоть и сопровождающийся матами; а в случае отсутствия прямой связи между low-level'ом и high-level'ом контроля в принципе нет).
P.S.: Но, да, я Вас понял и во многом согласен.
Несмотря на то, что я считаю C++ очень неудачным языком, сама идея «просто добавить нижнему уровню побольше абстракций» мне импонирует гораздо больше. Так язык получается гораздо «осязаемее», ты «чувствуешь» что ты делаешь, что ли (разница как между нажимать кнопочки управления гидравлическими приводами экскаватора и физически «щупать» землю лопатой в руках — первое, может, и эффективнее, но…).
Но Ваш взгляд я тоже понимаю (просто я вижу «прозрачность» в прямой и очевидной связи low-level'а и high-level'а; а хреновый контроль типов и местами дурацкий синтаксис — это, конечно, отстой, но после привычки к ним всё равно имеешь контроль, хоть и сопровождающийся матами; а в случае отсутствия прямой связи между low-level'ом и high-level'ом контроля в принципе нет).
P.S.: Но, да, я Вас понял и во многом согласен.
простоту инструментальных средств (К сожаления, для C++ нет сред разработки, сравнимых с IDEA)В этом вопросе вы не компетентны ) Сначала исследуйте вопрос CLion от того же JetBrains ;)
Как же тогда связать CLion с autotools или plain Makefiles? И может ли работать CLion через ssh + screen/tmux? На сколько понимаю, по обоим пунктам — ответ отрицательный.
В статье написано «Аллокация выглядит как уменьшение указателя, указывающего на начало свободной памяти.», а затем идет пример с аллокацией 16 байт в диапазоне 0х4000:0х4010. Не должен ли быть диапазон 0х3990:0х4000, если следовать 1му утверждению?
«В мире HFT то, насколько успешна торговая система зависит от суммы двух параметров: скорости самой торговой системы и скорости ее разработки, развития.»
Мне кажется такой взгляд на вещи немного однобоким :) Хотя я половину статьи не понял, и вообще я не настоящий программист :)
Успешность любой торговой системы, на мой взгляд, это прибыль, которую она приносит с учетом стоимости накладных расходов, при заданном уровне риска.
HFT реализует идею получения преимущества за счет более быстрого доступа на торговую площадку по сравнению с другими участниками. Для успеха HFT системы важна как идея бизнес логики, так и возможность её практической реализации, то есть надежного исполнения ордеров и контроля остатков. Для инструмента программирования важно наличие хорошей библиотеки для подключения по скоростному протоколу к биржевому шлюзу. А основные инфраструктурные расходы, это размещение своего ПО на сервере брокера в дата-центре биржи и выбор скоростных линий связи.
Если же все эти задачи у основных участников решены схожим образом, и поиск конкурентного преимущества сосредоточился на выборе Java/C++, то прошу простить меня за дилетантский взгляд.
Мне кажется такой взгляд на вещи немного однобоким :) Хотя я половину статьи не понял, и вообще я не настоящий программист :)
Успешность любой торговой системы, на мой взгляд, это прибыль, которую она приносит с учетом стоимости накладных расходов, при заданном уровне риска.
HFT реализует идею получения преимущества за счет более быстрого доступа на торговую площадку по сравнению с другими участниками. Для успеха HFT системы важна как идея бизнес логики, так и возможность её практической реализации, то есть надежного исполнения ордеров и контроля остатков. Для инструмента программирования важно наличие хорошей библиотеки для подключения по скоростному протоколу к биржевому шлюзу. А основные инфраструктурные расходы, это размещение своего ПО на сервере брокера в дата-центре биржи и выбор скоростных линий связи.
Если же все эти задачи у основных участников решены схожим образом, и поиск конкурентного преимущества сосредоточился на выборе Java/C++, то прошу простить меня за дилетантский взгляд.
Sign up to leave a comment.
Место Java в мире HFT