C++/core Java, low-latency, high frequency trading, NY/Ch

[Alexandr]

Ок но HTF ведь не ограничивается алгоритмами ложащимися в разумное время на такты проца?

нет, но джава - это всегда там где возможны компромисы, либо они задаются окружением

Вы можете как эксперт добавить конкретики? Есть место для джавы в HFT или нет?

В его линкедин профиле написано что он писал мониторинг трейдинговой системы на эрланге.

ну так это мониторинг, можно на чем угодно написать

Согласен, но это по его словам был не простой мониторинг: so that trading decisions can be prioritized based on congestion and queuing delays.

HFT помимо ядра есть много сопутствующего софта, который вполне себе живет на жабе (тот же мониторинг, тот же риск-менеджмент)
+ есть заданные средой ограничения, например, наш шлюз к interactivebrokers написан на жабе, ибо один пинг к нему длинной в жизнь )) (я бы уже это не назвал HFT )

[Alexandr]

Если правда интересно, но можете полистать этот код, это LMAX, кстати.
http://code.google.com/p/disruptor/

Вы смеетесь? Это барахло в качестве примера low latency приводить?

вы будете смеяться, но эта штука используется в дойче в connectivity софте, сам не знаю, но есть мысль, что для связи с оооочень удаленными биржами

но опять же, это ни разу не HFT

[Jerry]

У нас risk checks настолько же latency sensitive как и order execution, и Джаву к нему близко не подпустят. Насчет около-low latency экосистемы соглашусь, бывает и Джава. Но там есть любая технология и любой язык, если хорошо покопаться.

Автору топика по теме - если 140К это total compensation, то не фонтан. Если это база, то без части deferred compensation, которую еще называют "бонус" - мало информации. Она может быть вполне сравнима с базовой зарплатой и тогда это уже нормальная с плюсом цифра.

[natladner]

У нас все HFT core operations только на С++.
Есть немного жабы для мониторинга и R&D.

[Orest]

У нас risk checks настолько же latency sensitive как и order execution, и Джаву к нему близко не подпустят. Насчет около-low latency экосистемы соглашусь, бывает и Джава. Но там есть любая технология и любой язык, если хорошо покопаться.

Автору топика по теме - если 140К это total compensation, то не фонтан. Если это база, то без части deferred compensation, которую еще называют "бонус" - мало информации. Она может быть вполне сравнима с базовой зарплатой и тогда это уже нормальная с плюсом цифра.

Ок, т.е. где-то 220К - нормальная цифра (аs a total comp). Спасибо. В Сити, кстати, предлагали 140 за все про все.

[АццкоМото]

А вы действительно считаете что обладаете достаточной компетенцией в вопросе что бы делить мнения исключительно на ваши и неправильные? Вон Алейников на эрланге писал, который по performance отстает от джавы, и ниче.

Да, я обладаю достаточной компетенцией, чтобы судить на том уровне, на котором я сужу.
И еще я обладаю достаточным здравым смыслом, чтобы не строить свое представление об HFT на основе сомнительных фактов биографии мелкого, но знаменитого, воришки и - держите меня семеро - опенсорсного проекта сомнительной ценности

[Orest]

А вы действительно считаете что обладаете достаточной компетенцией в вопросе что бы делить мнения исключительно на ваши и неправильные? Вон Алейников на эрланге писал, который по performance отстает от джавы, и ниче.

Да, я обладаю достаточной компетенцией, чтобы судить на том уровне, на котором я сужу.
И еще я обладаю достаточным здравым смыслом, чтобы не строить свое представление об HFT на основе сомнительных фактов биографии мелкого, но знаменитого, воришки и - держите меня семеро - опенсорсного проекта сомнительной ценности

По-моему мы путаем UHFT and HFT. Если робот принимает решение по времени, сопоставимым с network latency, то вам и С++ не поможет. Здесь весь engine должен быть на С и ниже. Если робот думает секунды, то почти не важно на чем.

[Alexandr]

А вы действительно считаете что обладаете достаточной компетенцией в вопросе что бы делить мнения исключительно на ваши и неправильные? Вон Алейников на эрланге писал, который по performance отстает от джавы, и ниче.

Да, я обладаю достаточной компетенцией, чтобы судить на том уровне, на котором я сужу.
И еще я обладаю достаточным здравым смыслом, чтобы не строить свое представление об HFT на основе сомнительных фактов биографии мелкого, но знаменитого, воришки и - держите меня семеро - опенсорсного проекта сомнительной ценности

По-моему мы путаем UHFT and HFT. Если робот принимает решение по времени, сопоставимым с network latency, то вам и С++ не поможет. Здесь весь engine должен быть на С и ниже. Если робот думает секунды, то почти не важно на чем.

на С почти никто не пишет, С++ + template metaprogramming (что с лихвой покрывает boost::mpl) делает свою работу как надо, никаких тебе накладных расходов на полиморфизма

[crypto5]

А вы действительно считаете что обладаете достаточной компетенцией в вопросе что бы делить мнения исключительно на ваши и неправильные? Вон Алейников на эрланге писал, который по performance отстает от джавы, и ниче.

Да, я обладаю достаточной компетенцией, чтобы судить на том уровне, на котором я сужу.
И еще я обладаю достаточным здравым смыслом, чтобы не строить свое представление об HFT на основе сомнительных фактов биографии мелкого, но знаменитого, воришки и - держите меня семеро - опенсорсного проекта сомнительной ценности

Конечно я профан в этом деле, но мнение Фаулера по поводу полезности опенсорс проекта изложенное в статье с деталями для меня авторитетнее чем ваша лирика про Петра Семеновича.

[dotcom]

По-моему мы путаем UHFT and HFT. Если робот принимает решение по времени, сопоставимым с network latency, то вам и С++ не поможет. Здесь весь engine должен быть на С и ниже. Если робот думает секунды, то почти не важно на чем.

Вам надо вернутся к основам, если вы хотите получить серьезную работу в HFT.

[dotcom]

на С почти никто не пишет, С++ + template metaprogramming (что с лихвой покрывает boost::mpl) делает свою работу как надо, никаких тебе накладных расходов на полиморфизма

На C таки пишут. Знаю лично по крайней мере одного человека. Сейчас много людей, которые уже перешли на CUDA и Verilog. С такой скоростью, скоро начнут кастомные процессоры делать и писать на на микрокоде.

[Medium-rare]

Ерунда, конечно, про принципиальную разницу в latency между C и C++.

И там, и там, только от конкретных приёмов программирования зависит, можно вдруг увеличить latency, главным образм, от dynamic allocation. Что new/delete неразумно навтыкать, что malloc/free.

[vtl]

С такой скоростью, скоро начнут кастомные процессоры делать и писать на на микрокоде.

Что вы имеете в виду "скоро"? У нас давно на лисповом DSL специализированные процессоры пишутся, который потом в оптимизированный VHDL перегоняется. Руками на VHDL/Verilog упаришься столько кода оптимизировать и отлаживать. В отличии от выполнения даже оптимизированного на ассемблере кода на магазинных процессорах, нет никакого queueing даже на 10G. Даже если фейсбук на IPO выходит.

[crypto5]

Сколько нас ждет открытий науки и техники когда прикроют эту лавочку и люди начнут заниматься чем нибудь полезным.

[Orest]

По-моему мы путаем UHFT and HFT. Если робот принимает решение по времени, сопоставимым с network latency, то вам и С++ не поможет. Здесь весь engine должен быть на С и ниже. Если робот думает секунды, то почти не важно на чем.

Вам надо вернутся к основам, если вы хотите получить серьезную работу в HFT.

К каким основам? Может к этим?
"Surprisingly, Roberts said he used C++ sparingly. "I never really used anything very esoteric and, in fact, tended to rely on tools that were fairly common and unsophisticated. For example, back between 2001 and 2003, I wrote two entire HFT trading systems (one for option market making and the other for equity pairs trading) using VB6, which even back then would've struck many as silly. The reality was that the applications worked, they were reliable and they were fast (since VB6 is compiled)."
http://adtmag.com/articles/2011/07/29/w ... aries.aspx

Серьезно, всегда интересно послушать человека, кот. есть что сказать по существу.

[Medium-rare]

http://adtmag.com/articles/2011/07/29/w ... aries.aspx

Серьезно, всегда интересно послушать человека, кот. есть что сказать по существу.

Где же там пойнт про преимущества C над C++ в low latency? Там разное, включая системы на Visual Basic 6, к которым один гуру на C++ таки приписывал алгоритмы, использовал, но иногда.

[АццкоМото]

По-моему мы путаем UHFT and HFT. Если робот принимает решение по времени, сопоставимым с network latency, то вам и С++ не поможет. Здесь весь engine должен быть на С и ниже. Если робот думает секунды, то почти не важно на чем.

1. Если робот думает секунды, то это и не UHFT и не HFT
2. Тезис о том, что С быстрее, чем С++ мммм выражаясь вежливо, очень странен. "и ниже", кстати, я упоминал

[Medium-rare]

Сколько нас ждет открытий науки и техники когда прикроют эту лавочку и люди начнут заниматься чем нибудь полезным.

Согласен, business-wise лавочка HFT вообще-то сугубо паразитическая для рынка, бреют центы со стоков со скоростью света. Какие нахрен инвестиции? Но технические подробности интересны. Как военка, Пентагон, помимо всего, таки продвигает технологии, стимулирует разработчиков разного-разного технического добра.

[АццкоМото]

Конечно я профан в этом деле, но мнение Фаулера по поводу полезности опенсорс проекта изложенное в статье с деталями для меня авторитетнее чем ваша лирика про Петра Семеновича.

ну да, я все понял. глупцы платят специалистам по HFT большие деньги и окружают свой бизнес дичайшей секретностью
все что было нужно - скачать опенсорсный проект и попросить у crypto5 ссылочку на Фаулера - а voila! - ваши миллиарды уже у вас в кармане
глупцы тюнят риалтаймовые ядра, оптимизируют сетевые драйвера и даже клепают железки на FPGA. crypto5 АРГУМЕНТИРОВАННО показал всем, что Джавы или Эрланга более, чем достаточно. у него вот и ссылка на Фаулера есть
простите, я лучше буду дружить со здравым смыслом

[crypto5]

Конечно я профан в этом деле, но мнение Фаулера по поводу полезности опенсорс проекта изложенное в статье с деталями для меня авторитетнее чем ваша лирика про Петра Семеновича.

ну да, я все понял. глупцы платят специалистам по HFT большие деньги и окружают свой бизнес дичайшей секретностью
все что было нужно - скачать опенсорсный проект и попросить у crypto5 ссылочку на Фаулера - а voila! - ваши миллиарды уже у вас в кармане

В вас умирает великий писатель фантаст.

глупцы тюнят риалтаймовые ядра, оптимизируют сетевые драйвера

Это все вполне стыкуется с джавой.

простите, я лучше буду дружить со здравым смыслом

Можете начинать.

[Orest]

http://adtmag.com/articles/2011/07/29/w ... aries.aspx

Серьезно, всегда интересно послушать человека, кот. есть что сказать по существу.

Где же там пойнт про преимущества C над C++ в low latency? Там разное, включая системы на Visual Basic 6, к которым один гуру на C++ таки приписывал алгоритмы, использовал, но иногда.

Вопрос-то был очень прост. Чего надо знать по Java для HFT? To что Java нужна для HFT - это не вопрос, просто поищите на indeed по ключевым словам.

[АццкоМото]

В вас умирает великий писатель фантаст.

талантливый человек талантлив во всем

Это все вполне стыкуется с джавой.

Разумеется, стыкуется. Ровно у тех "специалистов", которые в одиночку забацали аж две HFT системы за два года на VB6 и объяснили миру, что они быстры потому что VB6 "кампелируица". Тут, действительно, крыть нечем

Можете начинать.

жаль, что у вас это никак не получается

[Alexandr]

на С почти никто не пишет, С++ + template metaprogramming (что с лихвой покрывает boost::mpl) делает свою работу как надо, никаких тебе накладных расходов на полиморфизма

На C таки пишут. Знаю лично по крайней мере одного человека. Сейчас много людей, которые уже перешли на CUDA и Verilog. С такой скоростью, скоро начнут кастомные процессоры делать и писать на на микрокоде.

да я не спорю, писать то можно, + старое поддерживать
просто, имхо, уже нет смысла

[crypto5]

В вас умирает великий писатель фантаст.

талантливый человек талантлив во всем

Это все вполне стыкуется с джавой.

Разумеется, стыкуется. Ровно у тех "специалистов", которые в одиночку забацали аж две HFT системы за два года на VB6 и объяснили миру, что они быстры потому что VB6 "кампелируица". Тут, действительно, крыть нечем

жаль, что у вас это никак не получается

К счастью не вам это решать.
Ну а выдирать цитаты мои и чужие из контекста это вообще достаточно тупой тролизм.

[Alexandr]

Ерунда, конечно, про принципиальную разницу в latency между C и C++.

И там, и там, только от конкретных приёмов программирования зависит, можно вдруг увеличить latency, главным образм, от dynamic allocation. Что new/delete неразумно навтыкать, что malloc/free.

все что нужно выделить, выделяется заранее, поэтому на критических участках кода выделений памяти (ровно как и освобождений) просто нет