Biography of an HFT startup

Matt Hurd (https://meanderful.blogspot.com)

I started my HFT career at one of the larger American trading firms as a C++ jockey. On my first day, I was greeted by full panes of glass boasting glorious Sydney Harbour views which were modestly obscured by a hand-scrawled “< 2ms” on that glass. This was the main goal for the dozen of us in IT. That wasn’t my remit at the start though. First things first…

Early daze
One of the desk guys had an idea for trading tailor-made combinations on the Australian Stock Exchange (ASX). That is, equity option spreads and combinations, along with their associated hedges. He needed something that could handle a bunch of intricate auto-trading rules that could be integrated with the Orc front-end being used for ASX trading. It was the early 2000s, so I developed a quick resizing UI with VB6 for the Windows 2000 desktops. This involved C++, Boost, multi-threading with a Spirit parser for the Orc integration at the back end. Orc calculated the binomial or trinomial trees for the ASX-listed American options on demand. For my binomial pricing code, I used simple Haug VBA code that I had transliterated to C++.

However, Orc didn’t calculate solely on demand, rather it used simple memoization for pricing. If the parameters were the same, Orc remembered, rather than recalculated the price. Our Orc Trader had been too slow to beat Timber Hill’s custom platform or IMC’s exclusively-licensed Orc Liquidator, the fastest vendor system at the time. The stack seemed too lame to be latency competitive, no matter what tricks I could come up with. However, with a large price cache from the busy C++ threads diligently filling out a multi-dimensional cache of option prices by parameter proximity for easy interpolation, suddenly we could hit trades that were previously unhittable.

By changing an interest rate, or selecting another volatility curve adjustment in Orc Trader, my pricing cache got busy replenishing itself. This wasn’t an entirely original solution. I first heard about the idea of pre-caching option prices in an old article about either Hull or CRT some years prior. Just as a modern out-of-order microprocessor can speculate on the next thing that’s going to be required, so can you. Market prices are discrete after all. Remember, the fastest calculation is always the one you don’t have to do. A later lesson was it was hard, but not impossible, to beat zero latency. This strange corollary to this speculative lesson exists because the fastest message is the one you don’t have to send. This is perhaps even more significant.

In my view, the best architecture is no architecture. That is a little facetious, but an important system truth. Reification just becomes legacy without a sufficient lack of architecture. As premature optimization is the root of all good, it is best to not talk too loudly about computing myths as it is best for your competitors to stumble.

The Orc Trader hackery I concocted wasn’t a great solution, but it made a few people happy getting some trades that were previously out of reach. Indeed, there was a bit of fist pumping and mirth when they first got some types of trades they’d never seen before. Overall, it was only mildly successful. It grew to hundreds of manual rules monitoring trading potentials and seemed to pay for itself when someone bothered to turn it on. It was a fun build for me at least.

@engineer10x

Кстати подписчик @tophel из Alpha Tech Lab ищет плюсовика - писать модули подключения к классическим биржам для торговли фьючерсами, желательно уже делавшего такое в прошлом. См. подробное описание вакансии внутри.

@engineer10x

Сколько инженеров в HFT?

Когда-то, ещё в позапрошлой жизни, мне рассказывали, что технических людей в банках в России не так уж и много, мир тесен, и, в принципе, все друг друга знают.

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

Цифры примерно такие:

Singapore  370 Hong Kong  488 Australia  792 Europe    2714 USA       5432

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

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

(Отвечая на вопрос в комментариях не с линедкина ли эти цифры. После нескольких лет в торговле, видимо добившись неплохого положения, многие специалисты уходят с линкедина, потому что там остаётся одна только личка забитая предложениями от рекрутеров и лента из восторженных мотивационных постов).

@engineer10x

300

Тем временем эти скромные измышления читают уже более 300 человек. Спасибо!

Расскажите немного о том, какие темы вам показались интересными, о чём хотелось бы узнать подробнее, из какой вы индустрии, чем занимаетесь сейчас и куда хотели бы двигаться дальше?

@engineer10x

Синхронизация потоков

При обсуждении многопоточности в первую очередь говорят про синхронизацию доступа к общей памяти из разных потоков через mutex или аналогичный синхронизационный примитив. Однако одновременный доступ из нескольких потоков к одному и тому же участку памяти не так уж прост. Как учит нас MIT, у него немало подводных камней и редко проявляющихся багов, его сложно организовать и тестировать, как правило он плохо влияет на дизайн, и так далее.

Другой способ, лишённый этих недостатков, это общение потоков через сообщения. В таком случае потоки общаются друг с другом явно через очереди (вместо неявного общения через изменение общих данных). Использование явной зависимости выпрямляет дизайн, делает код тестируемым и по-сути однопоточным. (Кстати, реализовать эти очереди можно и на мьютексах с условными переменными, главное, чтобы они не вытарчивали наружу).

При этом явными очередями можно не только улучшить дизайн, но и скорость, если реализовать их на неблокируемых инструкциях процессора вместо мьютексов. Классический пример такой реализации - это LMAX disruptor.

В этом подходе обмен сообщениями между потоками (одним писателем и множеством читателей) организован через кольцевой буфер, находящийся в общей памяти. Писатель записывает новое сообщение в буфер по индексу записи и сдвигает его на единичку через инструкцию процессора с префиксом lock, а читатели всё время проверяют не поменялся ли индекс записи и читают значение по этому индексу, если это произошло.

При таком подходе нет столпотворения читателей, пытающихся взять mutex или rwlock, им не нужно уходить спать в ядро, ожидая его освобождения, а latency может приближаться к пределу, ограниченному только скоростью синхронизации кешей между ядрами, особенно если удастся упаковать свои данные в L1 cache, как рекомендовалось выше.

@engineer10x

О подходах к работе и бизнес-моделях в торговле

Хозяин одной из успешных крупных американских торговых фирм создаёт и нагружает команды так, чтобы у них было значительно больше работы, чем ресурсов, а также чтобы ответственность пересекались с другими командами (для развития беспощадной конкуренции).

Для каждой создаваемой бизнес-единицы с самого начала вычисляется стоимость её мгновенного закрытия (например, досрочный разрыв контракта на офис, выплаты выходного пособия всем сотрудникам при увольнении и т. д.). Эта цифра постоянно ревностно обновляется, а хозяин всё время сравнивает её с доходами от подразделения.

Выжившие зарабатывают очень хорошо, но риск того, что могут разогнать, всегда присутствует на фоне и атмосфера бывает так себе.

@engineer10x

ChatGPT для работы

Сначала, в незапамятные времена, к библиотекам прикладывали мегабайты документации по каждому классу/функции. Чтобы понять как с помощью этой библиотеки решить конкретную задачу нужно было изучить много отдельных функций и приобрести кругозор, чтобы знать где искать (либо спросить у старших товарищей, у которых тоже был встроенный rate limiter). Либо могло повезти и документация содержала хорошие примеры типа "как построить такое-то приложение", но обычно примеров было меньше процентов пяти.

Потом развился поиск, документацию стало можно найти в интернете, но принцип её организации особо не поменялся.

Потом появился stackoverflow.com, где можно было наконец описать свою задачу и спросить как наиболее красиво и правильно её решить и с помощью каких библиотек. Нередко ведущие мировые эксперты начинали тебе отвечать через наносекунду. Поиск стал выдавать ответы со stackoverflow на первых страницах и жить стало существенно удобнее.

Теперь, когда появились LLM, можно попросить ChatGPT (или его конкурента) прямо написать затравку какой-то программы, включая обвязку и boilerplate для тестов, на ходу меняя используемые библиотеки.

Кроме этого, ChatGPT разбирал для меня сообщения из разных протоколрв и описывал их составные части. Или реализовывал стандартную агрегатную функцию из базы данных на С++. Однако мне кажется, что я не использую его и на 5% возможностей. Поделитесь как LLM помогает вам увеличивать свою эффективность в программировании и вообще?

@engineer10x

Как выбрать язык программирования?

Как оценивают какой-то язык когда на нём пишут? Например, "мои программы летают со скоростью света!" или "тяп-ляп и в production за 5 минут!" или "библиотеки всего мира на все случаи жизни под рукой".

Когда выбираешь язык для своего бизнеса количество измерений, над которыми приходится думать, увеличивается.
- Сколько мне нужно будет людей, хорошо знающих этот язык?
- Как легко найти и нанять нужно их количество?
- Сколько людей нужно будет на единицу выхлопа и как её измерить?
- Какие у нас требования и как данный язык помогает достигать их самым простым способом? Или может быть он активно мешает?
- Насколько быстро и легко можно поменять уже написанное?
- Или даже: сколько он жрёт процессорного времени и не станет ли счёт за электричество узким местом?

По каким критериям вы бы выбирали язык(и) программирования для своего проекта?

А для своей фирмы? Особенно если вы вкладываете в неё все накопленные за свою жизнь сбережения...

@engineer10x

Павел Дуров

Очень интересное и насыщенное интервью. Возможно что всё это широко известно, но для меня многое было новым.

- Телеграм пишет и обслуживает ~30 человек 10х инженеров.- Для их найма в компании 0 HR - люди выбираются по результатам соревнований на https://contest.com/

- Компания была и остаётся lean, что делает её похожей на торговые фирмы, торгующие своим капиталом. Причём не только в инженерном смысле, но и в ~~бес~~полезной регуляторной нагрузке. Но при этом мотивирована не деньгами, как торговцы, а идеалами свободы и беспристрастности, если верить Павлу ;)

- Например, компания не планирует размещаться на бирже - единственный сосредоточенный хозяин позволяет всем участникам кооператива сохранять независимость и концентрироваться на деле вместо ерунды. К тому же, по словам Павла, прежний Твиттер не мог поувольнять -10х инженеров из-за возможного волнения инвесторов ("массовые сокращения == в компании что-то не так").

- (Интересно, что, насколько мне известно, Маск увольнял людей из Твиттера так: всех сотрудников спросили кто в их команде самый лучший. Этих лучших оставили, остальных уволили. Опять-таки, чтобы это сделать, ему пришлось сделать компанию частной и убрать её с биржи).

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

- Для сравнения, приехав в Германию с уже готовой командой, Павел встретился с визовой/трудовой бюрократией (сначала нужно пробовать нанять местных и только если не получится через полгода - можно нанимать своих).

- А в США слишком много внимания со стороны спецслужб (да и пришлось отбивать свой телефон от гопников на улице в Сан-Франциско).

- Лондон и Сингапур тоже почему-то не подошли.

@engineer10x

Telegram

Du Rove's Channel

***🐥******🐥*** The full version of my interview with Tucker is out https://www.youtube.com/watch?v=1Ut6RouSs0w ***🎙***