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

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

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

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

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

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

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

@engineer10x

В продолжение вчерашнего

Пересмотрел лекцию Yaron Minsky, в незапамятные времена пересадившего с VBA(!) на OCaml Jane Street - единственную в своём роде HFT-фирму, пишущую почти всё на OCaml. Хотя лекции уже 8 лет, она не потеряла своей свежести.

В то время Jane Street - это 35 пишущих код инженеров, 190 человек всего, 4 офиса в мире, оборот 48 млрд долларов в день(!) на одних только американских биржах.

Требования Jane Street:
- Высокие требования к корректности и качеству (иначе можно потерять гигабаксы в микросекунду).
- Крайне важна скорость и лёгкость переписывания кода/итераций из-за высокого уровень неопределённости и быстро меняющихся внешних (биржи/регуляторы) и внутренних (стратегии) требований.
- Уверенность в сохраняющейся корректности на протяжении всего процесса независимо от высоких скорости и масштабов изменений.
- Обрабатывается огромный объём данных, для этого нужно много инфраструктуры и железа. Железо не дешёвое, а управление железом забирает внимание у людей, которые могли бы наносить непоправимую пользу где-то ещё. Поэтому программы должны летать.
- Лёгкость чтения кода - сами основатели фирмы читали и одобряли каждую строчку нового кода.

Как OCaml позволяет им проще достигать этих целей:
- Лаконичный. Boilerplate (есть хороший термин на русском? "строительные леса"?) забирает большое количество умственных ресурсов и снижает эффективность review. Одно время думали переезжать на C# и отказались - слишком многословный и (внезапно) читая код сложно представить как сработает ООП. Это он ещё своими впечатлениями от Java не поделился.
- Хорошо работает с алгебраическими типами данных - тип-произведение (struct) и тип-сумма (union) и pattern matching на последних (à la switch - case - default) гарантирует, что переберёт все возможные варианты, что снижает ошибки при изменениях и повышает уверенность в качестве.
- Гораздо более высокое качество инженеров, если они смогли осилить OCaml.
- Хотя их меньше на рынке, чем специалистов по другим языкам, нанимать их - сплошное удовольствие: например, на первое письмо в список рассылки по OCaml - 15 ответов - 12 телефонных собеседований - 5 приглашний в офис - 3 наняли. Очень эффективная воронка.

@engineer10x

P.S. Это не то, чтобы реклама OCaml, или даже Jane Street :). Просто применение такого высокого уровня абстракции ("функан от программирования") на практике да ещё и так эффективно - завораживает.

ChatGPT для работы

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

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

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

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

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

@engineer10x

Что пишут программисты определяется потребностями заказчиков. В продуктовых компаниях их роль выполняют Product Managers. Они должны узнать, что хочет клиент (или убедить клиента, что он хочет именно это) и нацелить программистов (и остальных) на решение этой задачи. PM являются олицетворением заказчика внутри компании, но между исполнителем и реальным клиентом получается достаточно много шагов.

В торговых фирмах заказчики гораздо ближе, как правило это трейдеры, сидящие с программистом за соседним столом. Они точно знают чего хотят и испорченный телефон между реальным клиентом и исполнителем сведён к минимуму. Поэтому роли Product Manager нет, а её задачи делятся между трейдером и программистом (который, как уже обсуждалось выше, человек-оркестр, то есть в том числе и product manager, project manager, SRE и много кто ещё). Обычно трейдер говорит куда хочет прийти, программист по существующему коду предлагает несколько разных путей как туда прийти с разной стоимостью, оба пытаются выбрать минимальную. Дальше выбранный путь радикально очищается от лишнего/не самого срочного и разбивается на кусочки, каждый из которых, в идеале, будет нести самостоятельную ценность.

Трейдеры как никто понимают высокую стоимость времени программиста и часто говорят "нуууу, это development work, давайте попробуем найти какой-нибудь другой способ покрутить систему за ручки так, чтобы получить то, что нам надо?".

Успешные торговые компании стараются решительно отбрасывать 90%+ непрофильной работы (типа "мы не в бизнесе по прозводству build-систем!") и стоять на плечах гигантов - брать готовые библиотеки/решения у FAANG-а и прочих, а также делегировать непрофильное (но нужное) внешним консультантам за фиксированную плату. Свои программисты должны работать только над задачами, которые являются конкурентным преимуществом фирмы.

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

@engineer10x

Кажется у Маска работают примерно как в торговле, только с железом (что сложнее):

It depends on what you want to count as a tech breakthrough because I think there is significant learning by doing. This is an important point is that a lot of the progress is made outside of the science lab, but it's still an innovation, it's still an idea, and it comes from deploying, having contact with the real world, seeing what goes wrong, iterating. If you think about why SpaceX and Boeing have such divergent paths. Well, Boeing just designs the product. Whether it's a rocket or capsule or an airplane, they design the product end-to-end and then build it and then fly it and expect it to work flawlessly, whereas SpaceX is, "Well, we're going to build this half-baked version. We're going to fly it. We're going to see where the weak points are, why it blows up. Then we're going to figure out what the problems are and address those in the next iteration."

Iteration speed is so important for development. I don't know if you count that as pure ideas or pure deployment, but it seems really important as attested by the fact that SpaceX has a higher valuation than Boeing's market cap with 1/10 of the employees.

https://twitter.com/AlecStapp/status/1798880702080950569

https://www.danschulz.co/p/eli-dourado

@engineer10x

Кирилик задаёт тот же вопрос про chat gpt и собирает в коментах множество примеров, некоторые из них - просто 🔥

https://t.me/kyrillic/758

Торговля - достаточно узкая отрасль и про её техническую сторону не так много можно прочитать в сети. Тем ценнее реальная информация от тех, кто работает в индустрии.

@hft_dev публикует подборки литературы и программистские трюки, полезные в торговле, и рассказывает как зайти в HFT.

Всячески рекомендую подписаться если интересуетесь этой темой.

@engineer10x

Test driven development

На просторах телеграма встретилось мнение:

для TDD нужен серьезный уровень экспертности, иначе человеком это воспринимается как «это все пустая трата времени»

в связи с чем вопрос - вы пользуетесь TDD, пишете тесты? или это "мешает вовремя выкатывать задачи"?

@engineer10x

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

Тесты:

• выпрямляют дизайн, заставляя автора разбивать программу на компоненты и устанавливать между ними явные зависимости. При этом становится понятно неудобство неявных зависимостей между компонентами (вроде Singleton или глобальных переменных).

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

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

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

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

@engineer10x

Dependency injection

Продолжаем разговор.

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

Последовательно применяя этот подход ко всем компонентам системы можно существенно увеличить уверенность в правильности её работы.

На практике (C++ с gtest/gmock) это выглядит примерно так:

// interface.h
#pragma once

struct Interface {
    struct Arg {
        // ...
    };
    virtual void call(const Arg&) = 0;
    virtual ~Interface() = default;
};

// component.h
#pragma once

#include "interface.h"

class Component {
    struct State {
        // ...
    };
    Interface &output;
    State state{};
public:
    explicit Component(Interface& output_)
        : output{output_}
    {}

    struct Input {
        // ...
    };
    void input(const Input& input) {
        auto out_args = combine_input_and_state(input);
        output.call(out_args);
        update_state_based_on_input(input);
    }

private:
    Interface::Arg combine_input_and_state(const Input& input)
    {
        // ...
        return {};
    }

    void update_state_based_on_input(const Input&)
    {
        // ...
    }
};

Тесты:

// test.cpp

#include "component.h"

#include <gmock/gmock.h>
#include <gtest/gtest.h>

struct Mock : Interface {
    MOCK_METHOD(void, call, (const Interface::Arg&), (override));
};

struct InputOutputTest : ::testing::Test
{
    Mock output;
    Component tested{output};
};

TEST_F(InputOutputTest, Test)
{
    using namespace ::testing;
    auto input = Component::Input{};
    EXPECT_CALL(output, call(_ /* IsExpectedOutputForThisInput */));
    tested.input(input);
}

Production:

// production.h
#pragma once

#include "interface.h"

struct Production : Interface {
    void call(const Arg&) override
    {
        // ...
    }

    ~Production() override = default;
};

//main.cpp
#include "production.h"
#include "component.h"

int main()
{
    // build the graph
    Production p;
    Component c{p};

    // start the graph
    // ...

    return 0u;
}

Если хочется немного ускорить, то можно заменить (небесплатные) виртуальные функции на zero cost dependency injection на шаблонах. Оставим реализацию этого подхода в качестве упражнения для заинтересованного читателя. Если эта тема интересна читателям (скажем этот если пост наберёт в ближайший месяц 1000 просмотров), то напишу пример.

@engineer10x