Qminers Masterclass vol. 1: Low-latency systémy

Qminers je technologická firma zaměřená na algoritmické obchodování. Vyvíjíme vlastní high-frequency trading systémy, které obchodují na finančních trzích v reálném čase. Neprodáváme software klientům. Stavíme a provozujeme vlastní infrastrukturu, vlastní strategie i vlastní technologický stack. Výkon pro nás není kosmetická vlastnost. Je to základní parametr produktu.

V high-frequency tradingu rozhodují nanosekundy. Ne obrazně, ale doslova. Rychlost může znamenat rozdíl mezi provedeným obchodem a promarněnou příležitostí. A právě proto v klíčových částech systému používáme C++.

Python má v našem světě taky pevné místo. Používáme ho pro výzkum, analytiku i prototypování nových strategií. Je rychlý na vývoj, flexibilní a produktivní. Jenže jakmile se rychlost stane přímo součástí výsledného produktu, potřebujeme plnou kontrolu nad tím, co se děje mezi kódem a hardwarem. A tu nám dává C++.

C++ umožňuje ovlivnit, co CPU skutečně vykonává. Dává nám kontrolu nad pamětí, nad strukturou dat, nad tím, jak se pracuje s cache a jak se chová predikce větví. V prostředí, kde je latence klíčová, už nejde jen o algoritmus. Jde o to, jak se ten algoritmus fyzicky propisuje do instrukcí a jak se ty instrukce chovají na konkrétním procesoru.

Kód na papíře versus realita hardwaru

Kód může na papíře vypadat dokonale. Čistý, s dobrými asymptotickými vlastnostmi, s přehlednou strukturou. To ale samo o sobě nic negarantuje. Výkon není o syntaxi ani o tom, kolik řádků má funkce. Rozhodující je, co se děje mezi zdrojovým kódem a procesorem.

Abychom mohli kódu opravdu věřit, musíme rozumět tomu, jak se chová v paměti, jak využívá cache a jak se větve v podmínkách trefují do očekávání branch predictoru. To ale neznamená optimalizovat všechno od první chvíle.

Známá věta říká, že předčasná optimalizace je kořenem všeho zla. Optimalizovat příliš brzy vede k méně čitelnému kódu a často ani nepřinese reálné zrychlení. V Qminers postupujeme opačně. Nejprve měříme. Identifikujeme skutečný bottleneck a teprve potom hledáme způsob, jak ho odstranit.

Problémy s výkonem jsou zrádné, protože závisí na konkrétních datech i konkrétním hardwaru. To, co funguje v testu nebo v teoretickém modelu, se může v produkci chovat úplně jinak. Pravdu zjistíme jen skrze měření.

Když latence vystřelí nahoru

Matěj popisuje situaci, kdy jsme spouštěli obchodování na novém trhu s jemnou cenovou mřížkou a vysokou volatilitou. Implementace knihy objednávek byla postavená na hash tabulce, která byla dobře naladěná na hustší knihy.

Na novém trhu se ale začaly vytvářet dlouhé kolizní řetězce. Na papíře vše vypadalo správně. Počty instrukcí seděly. Jenže latence náhle vystřelila nahoru. Každý lookup znamenal skákání po paměti, opakované míjení cache a nepředvídatelné zdržení.

V high-frequency tradingu je takové chování kritické. Nestabilní latence je problém sama o sobě.

Na příčinu jsme nepřišli odhadem. Změřili jsme ji. Nástroje jako perf a flamegraph ukázaly časové hotspoty i tam, kde callgrind žádný zásadní problém neindikoval. Právě rozdíl mezi těmito pohledy napověděl, že problém neleží ve výpočetní náročnosti, ale v přístupech do paměti.

Jak se rodí stabilní výkon

Řešení nespočívalo v radikálním přepsání celého systému, ale v cílených úpravách. Bylo potřeba správně nastavit velikost tabulky pro konkrétní trh, zvolit pro cache přívětivější datové struktury, například flat_map nebo vector, a zároveň zjednodušit control flow tak, aby branch predictor nemusel zbytečně hádat.

Výsledkem byla proměna nevyzpytatelných zpomalení ve stabilně rychlé odezvy s nízkou latencí. Nešlo jen o zrychlení průměru, ale o odstranění výkyvů.

Z této zkušenosti vyplývají tři obecné principy. Měř skutečné chování programu a nespoléhej se jen na teoretické úvahy. Navrhuj systém s ohledem na datovou lokalitu. A snaž se o předvídatelné větve a souvislý přístup do paměti. Skutečný výkon vzniká právě tam.