Stefan Schlamp очень интересно пишет про разные статистические закономерности и наблюдения в торговле на основе очень подробных данных с Eurex.

Пока что это единственный блог с Линкедина, показавшийся мне полезным, т.к. в основном я там вижу восторженное мотивационное графоманство. Знаете ли вы какие-то полезные блоги на Линкедине?

https://www.linkedin.com/in/stefanschlamp

@engineer10x

Думать о решении задач бизнеса вместо почасовой продажи своего времени - первый шаг в развитии своей консалтинговой фирмы.

Patrick McKenzie рассказывает, как однажды его знакомый ошарашил его признанием того, что ценность содержания их разговора значительно превосходит почасовую плату:

At the end of the conversation, Thomas said something which, no exaggeration, changed my life.

Thomas: Some food for thought: If this hadn't been a coffee date, but rather a consulting engagement, I'd be writing you a check right now.

Me: Three hours at $100 an hour or whatever an intermediate programmer is worth would only be $300. Why worry about that?

Thomas: I got at least $15,000 of value out of this conversation.

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

@engineer10x

Данные с Eurex показывают как с 2021 года доля участников Eurex с tick-to-trade latency < 20 нс выросла с 0 до >50% (и в 2023 году почти все HFT работают с такой задержкой).

Казалось бы - 20 нс - это меньше минимального теоретического предела реакции: события с рынка приходят через UDP multicast, чтобы прочесть одни только заголовки нужно больше времени: заголовок Ethernet 14 байтов, IP - 20 байтов, UDP - 8 байтов. Чтобы прочитать их через 10 ГГц Ethernet (10 бит в наносекунду) нужно минимум 33.6 нс (42 байта х 8 бит/байт / 10 бит/нс) и это мы ещё не дошли до полезной нагрузки в UDP пакете, чтобы понять хотим ли мы вообще отправлять ордер.

Как же они это делают?

@engineer10x

Speculative Triggering

Конечно постоянно и гарантированно отвечать за 50 нс или меньше через память и процессор невозможно, можно только через сетевушку с FPGA, которая сразу закольцевывает сигнал из Rx в Tx порты. FPGA - это матрица логических элементов и связей между ними, которую можно перепрошивать. На каждом такте вся матрица может параллельно продвигать сигнал на следующий этап, визуально отличие от CPU выглядит так. Поэтому при тактовой частоте 10 ГГц такая сетевушка может начинать выплёвывать первый бит Ethernet кадра в Tx канал уже через доли наносекунды после поступления первого бита на Rx.

Ещё в/до 2020 года некоторые умельцы научились реагировать на рыночные события за < 50 нс. Делали они это примерно так.

Рис 1. FPGA решает что приходящий с рынка пакет может быть потенциально интересным, посмотрев на начало UDP payload или даже немного раньше. Если да - то начинает отправлять заголовки для TCP-пакета с будущими ордерами, параллельно продолжая читать. Если payload оказывается неинтересным на самом деле, то уже отправляемый пакет отправляется в помойку. Его нельзя просто перестать слать, а надо как-то закончить. Для этого можно например записать какой-нибудь закрытый порт в поле dst TCP port, а когда биржа его получит, то отбросит, послав RST. К моменту записи порта можно прочитать достаточно много из payload, чтобы понять действительно ли он интересен.

Такие мусорные пакеты приходили на биржу очень часто, что создавало ощутимую лишнюю нагрузку на биржу и ей это достаточно быстро поднадоело. Руководствуясь принципом "не можешь остановить процесс - нужно его возглавить", в феврале 2020 Eurex выпустила циркуляр 010/20, который, с одной стороны, ввёл ограничения на это безобразие, а с другой - дал техническую возможность продолжать это делать так, чтобы биржа не ломалась. (После этих изменений мусорного трафика - больше 70%, и его доля постоянно растёт).

Что поменялось: во-первых, в поле DSCP (2 байт) IP заголовка добавлялись нестандартные флаги, показывающие насколько интересные данные будут в пакете. (Так как эти пакеты не уходили бы во внешний интернет, нестандартность флагов не приводила к проблемам). Во-вторых, вводились discard IP-адреса, всё отправленное на которые отбрасывалось первым же биржевым маршрутизатором. Также вводились ограничения на размер "брандспойта", которым участник рынка мог заливать биржу трафиком, и дополнительные комиссии "за злоупотребления".

Рис. 2. Теперь стало можно начинать писать исходящий пакет прочитав 16-й байт входящего, т.е. в пределах 20 наносекунд, а к моменту заполнения dst IP-адреса можно было даже немного посмотреть в конкретные цены из payload и отправить пакет в помойку, если они оказывались неинтересными. Или начать писать чуть-чуть позже чтобы посмотреть в payload подольше. Или извращаться как-то ещё.

Ссылки.

1. HFT Market Data Share - статья , из которой картинка в предыдущем посте.

2. Описание Speculative Triggering (и других интересных вещей про динамику рынка) от самой Eurex.

3. Как работает FPGA.

@engineer10x

Я в телеге относительно недавно, а ретвитов тут особо нет, поэтому вопрос.

Какой для вас самый ценный и любимый (ну после Валеры, конечно ;) ) канал (или два) по программированию/IT в телеге, чтобы прямо 100% must read?

Хотелось бы набрать хороших и подписаться.

Интересный минималистичный пример торговой стратегии с backtest на исторических данных. Контора продаёт доступ к ним и статья (да и весь блог) рекламирует простоту их использования.

Стратегия набирает позицию до определённого предела если в книжке перекос выше определённого порога. Реальные стратегии принимают решение покупать или продавать на основе множества факторов, тут для наглядности выбран очень простой - book skew.

Другое допущение - это отсутствие задержки между отправкой и исполнением заявки. В реальности за это время рынок часто уходит в другую сторону и стратегия "промахивается"; для backtest с хорошей предсказательной силой это надо как-то моделировать.

Стратегия получается даже прибыльной, но только до учёта комиссий.

@engineer10x

Знакомство с FPGA для программиста

В торговлю заходил через острозаточенный С++, да и изначальный профиль - программирование, поэтому о железе познания были в основном теоретические. Но вот я здесь и, оказывается, самые скоростные части execution работают на FPGA, поэтому обязательно надо посмотреть что это за зверь. Сказано - сделано, учебная плата DE10-Lite куплена за $100 (сейчас стоит ~$150) и вот я уже продираюсь сквозь дебри Verilog. Железячники: прошу дальше не смеяться :).

Оказалось очень интересно, но в то же время совершенно другой мир и большие трудозатраты, ведь там с нуля нужно писать вообще всё (ну если библиотеки не покупать). То есть если хочешь например что-то вывести на экран через VGA, то нужно покурить стандарт VGA и написать свои модули для правильной генерации сигнала с точно подобранной вертикальной и горизонтальной частотой (подробнее например здесь). За что-то чуть более сложное, чем VGA, лучше вообще не браться, поэтому до чтения Ethernet пакетов дойти (пока?) не удалось :).

Открытий много. Это что же получается, в этом мире нельзя просто обратиться к памяти и взять значение, а нужно самостоятельно писать целый контроллер памяти?? Начинаешь его писать и сразу понимаешь почему L1 cache - это SRAM, а обычная память - DRAM. Вкратце, ячейка SRAM - это 6 транзисторов, а DRAM - транзистор и конденсатор. SRAM значительно быстрее, но больше размером и дороже из-за количества транзисторов. DRAM - меньше и дешевле, но тормознее, а ещё из-а того, что конденсатор "течёт", её надо регулярно перезаряжать. Вот реально - сидишь ты, значит, в контроллере памяти, схватился за сигнал от генератора тактовой частоты и раз в N периодов вешаешь на дверь табличку "обед", читаешь каждую ячейку памяти и тут же записываешь её обратно.

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

Часто учить FPGA начинают с реализации RISC-V процессора. Его преимущество в том, что спецификация открытая, инструкции простые и их немного, можно реализовывать подмножества стандарта, поэтому можно делать MVP на каждой итерации - всё как мы любим. Потом пишешь программу на С++, собираешь её gcc под получившийся процессор и voilà - она работает на твоём собственном процессоре, фантастика! Был бы студентом с бесконечным временем - обязательно бы занялся сейчас.

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

@engineer10x

P.S.

DE-Lite, кстати, хоть карточка дешёвая и учебная, но весьма функциональная ("the board utilizes the maximum capacity MAX 10 FPGA, which has around 50K logic elements(LEs) and on-die analog-to-digital converter (ADC). It features on-board USB-Blaster, SDRAM, accelerometer, VGA output, 2x20 GPIO expansion connector, and an Arduino UNO R3 expansion connector in a compact size"). Правда проекта для применения в домашнем хозяйстве ей придумать пока так не удалось, поэтому ограничился игрушечными проектами.

Hard skills in HFT (for software execution devs)

- С++ - потому что большинство HFT фирм используют для low latency именно его;
- template metaprogramming - в HFT используется значительно чаще чем вне, потому что из-за желания срезать каждую возможную микросекунду многое (иногда даже слишком) пишется на шаблонах;
- как работает какая нибудь конкретная биржа, какие у неё feed & transaction протоколы - спецификации обычно опубликованы на сайте биржи;
- как подписаться на market feed через multicast udp (и что делать если начнёшь терять пакеты);
- как быстро читать multicast udp с сетевой карточки через user space networking и построить вокруг этого mainloop (см. Solarflare/EfVi) и понимать почему kernel space networking не подойдёт;
- как быстро собирать order book из market feed;
- как максимально упаковать часто используемые данные в L1 cache, а редкоиспользуемые отложить в сторонку;
- как работает процессор и память (см. WEPSKAM и учебный FPGA);
- как спроектировать торговое приложение, какие в нём должны быть компоненты;
- как написать надёжные автотесты;
- как сделать бизнес-логику по-максимуму независимой от специфики конкретной биржи;
- как присоединить приложение к биржевым сессиям и ввести ограничение на транзакции в секунду;
- как добавить ограничение рисков и гарантировать, что они сработают.

@engineer10x

Пример разделения горячих и холодных данных в одной структуре

Patrick Moran из Headlands Tech придумал OutOfLine – A Memory-Locality Pattern for High Performance C++.

Если структура состоит из двух частей - горячей (часто используется в runtime) и холодной (нужна только в начале и конце существования объекта), то можно достаточно небольшим шаблоном разнести их по разным участкам памяти. Вместо того, чтобы держать горячую и холодную части рядом в одной структуре, в ней можно оставить только горячую, а холодную отложить в сторонку, создав косвенную связь через статический key-value контейнер, где ключом будет указатель на горячую часть. Если из таких структур сделать вектор, то только горячие части будут уложены в памяти друг за другом и попадут в кеш.

@engineer10x

Функциональные языки в торговле

В чистых функциональных языках функции не имеют побочных эффектов и результат вызова функции зависит только от её аргументов. Однако взаимодействие с внешним миром (например ввод-вывод) не может быть чистым, потому что изменяет его. К примеру, Haskell синтаксически отделяет "нечистый" код от чистого через систему типов: если функция f() зовёт функцию g() помеченную как IO, то функция f() тоже должна быть помечена как IO. Поэтому если в программе есть хоть один вызов putStrLn, то эта "зараза" распространяется вверх до самой main(). Однако чистые функции можно звать изнутри функций с IO, поэтому их можно сгруппировать в отдельный граф.

Если код - чистый, то порядок вычисления аргументов функции становится неважен, в отличие от скажем С++, где это часть стандарта (причём менявшаяся последние годы и не раз). Раз порядок вычисления аргументов неважен и они полностью независимы, то вычислять их можно параллельно. Это начинает напоминать внутренний параллелизм FPGA, который мы уже обсуждали выше. Действительно, получается что чистая часть функционального языка типа Haskell теоретически изоморфна языку проектирования FPGA типа System Verilog.

Оказывается этот изоморфизм реализован и на практике - см. Clash - Haskell-подобный язык для проектирования железа, который компилируется в традиционные VHDL/Verilog/System Verilog. По отзывам, проектировать железо на нём значительно быстрее, чем на традиционных, а тестировать бизнес-логику вообще одно удовольствие - тесты, написанные на языке высокого уровня, отрабатывают на CPU и не нужно городить массивную инфраструктуру вокруг симуляторов Verilog или живых железок. Это становится конкурентным преимуществом и в торговле (см. пример в комментариях).

Jane Street широко известна как единственная в своём роде фирма, использующая OCaml (почему). Им до того нравилось его использовать для написания софта, что когда возникла необходимость начать делать железо, они наняли Andrew Ray, который до этого начал придумывать Hardcaml, и предложили ему делать то же самое, что и раньше, только работая на них.

Встречались ли вы с чем-то подобным в своей карьере?

@engineer10x

Про эффективность

На работе нужно сделать что-то скучное и неприятное, а хочется "уйти в себя на пару дней", реализовать какой-нибудь красивый алгоритм, отпрофилировать и порефакторить какой-то кусочек, ускорить его через SIMD раз в 10 или ещё как-то закопаться вглубь и решить красивую инженерную задачку. Знакомая ситуация?

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

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

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

@engineer10x

Сложности фокусировки

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

Встречались команды, у которых template metaprogramming превратился в самоцель и активно мешал достижению бизнес-задач, потому что был доведён до абсурда. Казалось, что технические предводители хвастались друг перед другом насколько сильнее можно поиздеваться на С++ и были похожи на того пилота, последними словами которого были "смотри как я умею!"

Или другая команда, спроектировавшая систему на основе CRTP так, что каждый биржевой инструмент был отдельным шаблонным параметром. В итоге в одном бинаре можно было использовать только небольшое число инструментов, потому что при его превышении gcc падал.

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

В общем, сосредотачиваться на бизнес-целях и бороться с sunk-cost fallacy непросто, но очень важно.

Встречались ли вам подобные проблемы, из которых компаниям удалось выбраться? Что они для этого сделали?

@engineer10x

Сергей Перфильев, уйдя из Goldman Sachs после 4х лет работы, рассказал о том, как работается квантом в большой торговле и что там ценится.

Там много интересного, но основное, как мне кажется, это то, что для получения большей премии инженерам нужно выкатывать новые проекты (достаточно 70% качества) и правильно рекламировать свой вклад бизнесу, улучшать старые ценится значительно ниже (не удивительно, что в торговле столько лапшекода):

7/ Similar to FAANG companies, one is rewarded for rolling out new features rather than improving/supporting old ones.

No one is interested if your code runs better and is easy to debug and extend.

If it works and meets the "barely usable" criteria, then it's good enough.

Ship it and send that congratulatory email to sales and trading.

There is significantly more emphasis on items that qualify as deliverables and can be shown to senior management.

Time spent fixing issues, improving your code or helping other teams doesn't count as such.

@engineer10x

Ещё про эффективность (и дофамин)

Торговля стала первой отраслью в моей программистской карьере где оказалось возможно хлебать дофамин литрами без того, чтобы от скуки уходить за ним в соцсети. Очень впечатляет когда для решения внезапно появившейся серьёзной проблемы специалисты из разных команд и ролей мгновенно собираются в ad hoc team, бросая всю более медленную проектную работу которой занимались до этого, и интенсивно решают проблему "здесь и сейчас", не расслабляясь от начала и до конца.

Все имена и события в истории вымышлены, любые совпадения с реальными людьми, живыми или мертвыми, случайны.

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

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

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

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

Видели ли вы похожую по насыщенности работу? Дополнительные баллы за примеры не из биржевой торговли.

@engineer10x

Павел Дуров

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

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

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

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

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

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

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

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

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

@engineer10x