C++ korkean taajuuden kaupankäynnissä: markkinatiedoista deterministiseen latenssiin

Johdanto

Korkean taajuuden kaupankäynnillä on tapa yksinkertaistaa teknisiä argumentteja. Monilla ohjelmistoalueilla järjestelmä voi pysyä kunnioitettavana ja piilottaa tehottomuuden mittakaavan, laitteistobudjetin tai anteliaiden vasteaika-odotusten taakse. HFT:ssä hitaus on kallista. Epävakaus heikentää strategian laatua, hämärtää diagnoosia ja heikentää luottamusta koko pinoon. Alue pakottaa teorian vastaamaan aikaan.

Siksi C++ on edelleen niin tärkeä kaupankäyntijärjestelmissä. Kieli säilyy siellä, koska HFT pyytää toistuvasti yhdistelmää ominaisuuksia, jotka C++ tarjoaa edelleen epätavallisen hyvin: muistin asettelun hallinta, tarkka suorituskykytyö, kypsät alkuperäiset työkalut, syvä käyttöjärjestelmä- ja verkkointegraatio sekä valtava määrä käytännön tietoa, joka on kertynyt vuosikymmeniä kestäneiden todellisten järjestelmien aikana.

On houkuttelevaa tiivistää tämä yhteen iskulauseeseen, kuten C++ on nopea. Mutta se slogan on liian pieni. HFT ei palkitse raakanopeutta abstraktisti. Se palkitsee deterministisen käyttäytymisen koko polulla markkinatiedoista päätöksentekoon tilauksen siirtoon. Keskimääräinen latenssi auttaa, mutta ennustettava latenssi auttaa enemmän. Järjestelmä, joka on toisinaan loistava ja säännöllisesti tärisevä, on usein huonompi kuin se, joka on hieman hitaampi ja johdonmukaisesti ymmärrettävä. Syvempi tarina on, että C++ on edelleen yksi vahvimmista kielistä matalan latenssin järjestelmien rakentamisessa, joiden käyttäytymistä voidaan muokata, mitata ja korjata yksityiskohtaisesti.

Miksi HFT palaa jatkuvasti C++

Ajoissa kilpaileva kaupankäyntipino välittää yksityiskohdista, joita useimmilla muilla verkkotunnuksilla on varaa hämärtää. Kuinka monta allokaatiota tapahtuu kuumalla polulla? Mitkä tiedot ovat yhdessä välimuistissa? Mikä lanka kulkee missä? Kuinka monta jonohyppelyä erottaa pakettien saapumisen strategialogiikasta? Koskeeko jäsentäjä enemmän muistia kuin on tarpeen? Siirtyykö yhdyskäytävä ytimien välillä? Leventääkö oletettavasti vaaraton kirjaus- tai normalisointivaihe latenssijakauman häntää? Nämä eivät ole koristekysymyksiä. He ovat työtä.

C++ on luonnollinen koti tälle työlle, koska sen avulla insinöörit voivat kohdata nämä yksityiskohdat suoraan. Kieli ei pakota yhtä allokointimallia, yhtä jonotusjuttua, yhtä omistajuusjuttua tai yhtä ajonaikaista ajastinta koko järjestelmään. Tämä vapaus on vaarallista huolimattomien joukkueiden käsissä, mutta HFT on yksi niistä paikoista, joissa vapauden kurinalainen käyttö luo todellista etua. Kypsät kauppajärjestöt eivät halua kysyä koneelta kauniisti. He haluavat tietää tarkalleen, mitä konetta käsketään tekemään ja missä kustannukset ovat piilossa.

On myös ekosysteemiargumentti, jolla on enemmän merkitystä kuin ihmiset myöntävät. HFT on kieli-, työkalu- ja kokemusongelma. C++ sisältää kypsät kääntäjät, profiloijat, liekkikaaviot, laitteistolaskurin työnkulkuja, puhdistustuen, käyttöjärjestelmätason integrointimalleja ja pitkän perinnön viereisiltä suorituskykykriittisiltä teollisuudenaloilta. AI avustajat hyötyvät yhä enemmän samasta julkisesta perinnöstä. Kun insinööri pyytää apua jäsentimen parantamisessa, jonon tiukentamisessa tai profiloinnin tulosten tulkitsemisessa alkuperäisellä kuumalla polulla, C++:n historiallinen tiheys on edelleen vakava etu.

Mitä markkinatietotapahtuma todella kokee

Se auttaa kuvittelemaan yhden markkinatietotapahtuman fyysisenä taakana, joka liikkuu koneen läpi. Paketti saapuu. Se on vastaanotettava verkkopinosta tai syötteen käsittelijästä, jäsennetty, kartoitettava johonkin sisäiseen esitykseen, sovellettava yhteen tai useampaan kirjarakenteeseen, tarkkailtava strategialogiikalla, suodatettava riskitarkistusten läpi ja mahdollisesti muunnettava lähteväksi tilaukseksi tai peruutukseksi. Jos kaikki on hyvin, tämä ketju tuntuu välittömältä. Jos arkkitehtuuri on huolimaton, paketti saa painon jokaisessa vaiheessa.

Yksi ylimääräinen allokaatio täällä, yksi jaettu jono siellä, normalisointipassi, joka kopioi enemmän kuin pitäisi, kirjarakenne, joka on oppikirjallisessa mielessä tyylikäs mutta kylmä muistissa, vain turvallisuuden vuoksi tarkoitettu kirjauspolku, lanka, joka siirtyy väärällä hetkellä: mikään näistä kustannuksista ei kuulosta myyttiseltä erikseen. Niiden vaara on kertyminen ja toisto. HFT insinöörit oppivat ajattelemaan tällä kumulatiivisella tavalla, koska järjestelmä rankaisee optimismia. Tehottomuus, joka on pieni tapahtumakohtaisesti, kasvaa suureksi, kun se kerrotaan markkinoiden aktiivisuudella, strategiatiheydellä ja ennakoitavan reaktioajan tärkeydellä liiketoiminnassa.

Tästä syystä kaupankäynnin kuuma polku on harvoin vain yksi toiminto. Se on ekologiaa. Markkinatiedot, tilanhallinta, aikataulutus, sarjoittaminen, riskit ja siirto ovat kaikki vuorovaikutuksessa. Insinöörit, jotka optimoivat vain loistoisimman silmukan jättäen koordinoinnin ja asettelun huolimattomaksi, tuottavat usein järjestelmiä, jotka vertailevat hyvin fragmenteissa ja pettävät ainoassa tärkeässä paikassa: koko polussa.

Deterministinen latenssi on arkkitehtoninen kurinalaisuus

Ilmaisua alhainen latenssi käytetään usein ikään kuin se kuvaisi funktion ominaisuutta. Vakavassa HFTissa alhainen latenssi on arkkitehtuurin ominaisuus. Se ilmenee siitä, kuinka koko järjestelmä on muotoiltu. Kuumien tietojen tulee pysyä kuumana. Muistin omistajuuden tulee olla selvä. Langat tulee sijoittaa tarkoituksella sen sijaan, että ne jätettäisiin ajautumaan. Jaettuun muuttuvaan tilaan tulee suhtautua epäluuloisesti. Jonoja tulee olla vain silloin, kun ne ovat välttämättömiä. Havainnoinnin tulee olla tarpeeksi halpaa, jotta järjestelmä pysyy tarkastettavissa ilman, että se hukkuu omaan diagnostiikkaansa.

Tietojen asettelulla on merkitystä, koska kone liikkuu edelleen muistin, ei aikomusten kautta. Vierekkäiset asettelut, kompaktit kirjaesitykset ja rakenteet, jotka heijastavat käyttötapoja ohjelmoijan tunteen sijaan, ovat arvokkaampia kuin älykkäät abstraktiot, jotka näyttävät uudelleenkäytettäviltä, ​​mutta hajottavat kuumaa tilaa kaikkialle. Varauskurilla on merkitystä, koska kuumalla polulla oleva dynaaminen muisti voi aiheuttaa värinää, kiistaa ja yllättäviä vuorovaikutuksia muun suoritusajan kanssa. HFT:ssä värinä on usein nöyryyttävämpi ongelma.

Lankailu ansaitsee saman vakavuuden. Enemmän säikeitä ei automaattisesti tarkoita parempaa suorituskykyä. Joskus ne tarkoittavat enemmän koordinaatiota, enemmän välimuistin liikettä, enemmän affiniteettivirheitä ja enemmän paikkoja, joissa käyttöjärjestelmä voi tulla tahattomaksi tekijäksi. Aikuiset kaupankäyntijärjestelmät kiinnittävät säikeitä tarkoituksella, kunnioittavat NUMA rajoja tarvittaessa ja pitävät jaettujen päätösten määrän niin alhaisena kuin arkkitehtuuri sallii. Tämä ei saa koodista tuntumaan muodikkaalta. Se tekee käyttäytymisestä vakaampaa, mikä on yleensä paljon arvokkaampaa.

Verkottuminen, jäsentäminen ja kirjojen ylläpito

Kaupankäynnin verkostoituminen ansaitsee omanlaisensa kunnioituksensa, koska se on se paikka, jossa abstraktio on eniten houkutteleva valehtelemaan. Binäärisyöte on tilanmuutosvirta, joka on tulkittava uskollisesti ja nopeasti. Mitä nopeampi jäsentäjä, sitä vähemmän tilaa loppupään sekaannukselle on. Mitä vähemmän allokointia ja haaroitusta se suorittaa, sitä helpompi on ymmärtää, mistä kone maksaa. Syötteenkäsittelykoodi näyttää usein ankaralta juuri tästä syystä. Se on oppinut kivun kautta, mitä eleganssin muotoja markkinat eivät palkitse.

Tilauskirjan ylläpidolla on samanlainen luonne. Kirja ansaitsee arvoa, kun sitä voidaan päivittää, kysellä, toistaa uudelleen ja perustella sitä kuormitettuna. Toistettavuudella on tässä enemmän merkitystä kuin ulkopuoliset joskus odottavat. HFT-tiimit oppivat valtavasti toistamalla todellista liikennettä, vertaamalla strategiakäyttäytymistä versioiden välillä ja diagnosoimalla, missä järjestelmästä tuli hitaampi tai vähemmän vakaa. Kirjaesitys, jota on vaikea toistaa tai tarkastaa, voi silti näkyä nopeasti kapeassa testissä ja silti olla toiminnallisesti heikko. Kaupankäynnissä nopea ja diagnosoitava voittaa nopeasti ja salaperäisesti.

Tähän C++ sopii erityisen hyvin. Sen avulla sama koodikanta voi puhua sujuvasti syöttääkseen jäsentimiä, muistitietoisia tietorakenteita, profilointityökaluja ja matalan tason käyttöjärjestelmän toimintaa. Muut kielet voivat osallistua kaupankäyntijärjestelmiin, ja monet tekevät, mutta kun kyseessä oleva osajärjestelmä on itse kuuma polku, C++ tarjoaa silti yhden parhaista hallinnan ja ekosysteemituen yhdistelmistä.

Riski, uusinta ja toimintakyky

On virhe kuvitella HFT pelkkää nopeutta, josta on poistettu hallinto. Maailman nopein polku on hyödytön, jos se voi lähettää väärän tilauksen, epäonnistua tilan palauttamisessa tai muuttua selittämättömäksi epävakaan markkinatapahtuman jälkeen. Hyvät kaupankäyntijärjestelmät pitävät riskitarkistukset selkeänä, vikojen käsittelyn harjoitellaan ja toistoinfrastruktuurin lähellä päivittäistä suunnitteluelämää. Nämä eivät ole byrokraattisia lisälaitteita. Ne ovat osa kilpailukykyä.

Terve HFT-koodikanta kuvastaa yleensä tätä kypsyyttä. Se sisältää halvan havaittavuuden ennemmin kuin ei havaittavuutta. Se sisältää uusintatyökaluja, koska joukkueet tietävät, että sitä, mitä ei voida toistaa, ei voida parantaa luottavaisesti. Se sisältää vertailuarvoja ja profiloijia, jotka tarkastelevat koko polkua, mukaan lukien käsin poimitut mikroytimet, kun niistä on hyötyä. Se käsittelee käyttöönoton johdonmukaisuutta, kääntäjän asetuksia, affiniteettistrategiaa ja koneen konfigurointia ensiluokkaisina suunnittelukysymyksinä. Toisin sanoen parhaat kaupankäyntijärjestelmät ovat kurinalaiset tekniset ympäristöt.

Tämä on yksi syy, miksi vakaus voittaa niin usein raakaa älykkyyttä. Pienikin parannus laboratorion vertailuarvoon on vähemmän arvokas kuin toistettava järjestelmä, jonka pyrstö ymmärretään, jonka rehun käsittely on selitettävissä ja jonka strategiakäyttäytyminen voidaan rekonstruoida jälkikäteen. HFTiin tulevat insinöörit odottavat toisinaan sankareita. Se, mitä kypsät tiimit usein harjoittavat, on eräänlaista rauhallista kurinalaisuutta. Ne poistavat yllätyksiä. Markkinat tarjoavat niitä jo tarpeeksi.

Yleiset myytit ansaitsevat jäädä eläkkeelle

Useat myytit säilyvät, koska ne imartelevat insinöörejä. Eräs sanoo, että HFT suorituskyky liittyy enimmäkseen käsin kirjoitettuun kokoonpanoon tai esoteeriseen mikrooptimointiin. Todellisuudessa merkittävimmät voitot tulevat arkkitehtuurista, mittauksista ja tavallisen jätteen toistuvasta poistamisesta. Toinen sanoo, että lukitsemattomat rakenteet ovat automaattisesti ylivoimaisia. Joskus he ovat aivan oikeassa. Joskus ne tuovat monimutkaisuutta ja muistitilauskustannuksia paikkoihin, joissa yksinkertaisempi muotoilu olisi toiminut paremmin. Kolmas sanoo, että lisää lankoja auttaa aina. Matalalatenssisissa järjestelmissä ylimääräinen samanaikaisuus voi heikentää ennustettavuutta nopeammin kuin parantaa suorituskykyä.

On myös nykyaikainen myytti, jonka mukaan C++:n jatkuvan käytön HFT:ssä täytyy olla enimmäkseen historiallista inertiaa. Historialla on toki väliä, mutta inertia ei yksin selviä alalla, jossa järjestelmiä mitataan jatkuvasti rahassa ja ajassa. C++ pysyy, koska tiimit huomaavat jatkuvasti, että kieli, sen työkalut ja sitä ympäröivä suunnittelukulttuuri sopivat edelleen hyvin deterministisen matalan latenssin suunnittelun todellisuuteen. Jos jokin toinen kieli toisi jatkuvasti parempia tuloksia kuumimmilla kauppapoluilla, HFT-yritykset huomaisivat. Heillä on tarpeeksi vahvat kannustimet kiinnittää huomiota.

Miksi tämä verkkotunnus on edelleen tutkimisen arvoinen

Jopa insinööreille, jotka eivät koskaan työskentele kauppayrityksessä, HFT on edelleen arvokas opettaja, koska se tekee järjestelmän totuuden välttämisestä vaikeaa. Se pakottaa läheisen suhteen koodin ja seurausten välille. Se opettaa, että tietojen asettelu ei ole koristelu, että jonot eivät ole vapaita, että keskimääräinen latenssi voi valehdella, että uusinta on ymmärtämisen muoto ja että arkkitehtuuri on usein tärkein optimointi. Nämä opetukset siirtyvät paljon kaupankäynnin ulkopuolelle.

C++ on edelleen tämän oppitunnin keskipisteessä, koska sen avulla insinööri voi säilyttää vaikean tasapainon. Se on tarpeeksi ilmeikäs rakentaakseen merkittäviä järjestelmiä, tarpeeksi alhainen paljastaakseen kustannukset rehellisesti ja tarpeeksi vanha, jotta se sisältää laajan perinnön työkaluja ja käytäntöjä. Tällä yhdistelmällä on edelleen merkitystä yhdellä vaativimmista suorituskykyalueistamme.

Jos HFTissa on jotain motivoivaa, se ei ole nopeuden mytologia sen itsensä vuoksi. Se on muistutus siitä, että ohjelmistosta voidaan tehdä tarkkoja, mitattavia ja arvokkaita paineen alaisena. C++ on edelleen yksi niistä kielistä, joilla tätä alaa puhutaan edelleen sujuvasti.

Hands-On Lab: Luo pieni syötteestä kirjaan -toisto

Viimeistään rakentamalla pienoismalli HFT-tyylinen lelu. Siitä ei tule rahaa. Se on erinomaista. Useimmat koodiesimerkit, jotka lupaavat tehdä rahaa, ovat opetuksellisia pahimmalla mahdollisella tavalla.

Mitä se tekee, on hyödyllisempää: toista sarja markkinapäivityksiä pieneksi muistikirjaesitykseksi ja raportoi parhaan tarjouksen ja kysy.

main.cpp

#include <algorithm>
#include <chrono>
#include <cstdint>
#include <iostream>
#include <limits>
#include <string>
#include <vector>

enum class Side { Bid, Ask };

struct Update {
    Side side;
    int price;
    int qty;
};

struct Book {
    std::vector<Update> bids;
    std::vector<Update> asks;

    void apply(const Update& u) {
        auto& side = (u.side == Side::Bid) ? bids : asks;
        auto it = std::find_if(side.begin(), side.end(), [&](const Update& x) {
            return x.price == u.price;
        });

        if (u.qty == 0) {
            if (it != side.end()) side.erase(it);
            return;
        }

        if (it == side.end()) {
            side.push_back(u);
        } else {
            it->qty = u.qty;
        }
    }

    int best_bid() const {
        int best = 0;
        for (const auto& b : bids) best = std::max(best, b.price);
        return best;
    }

    int best_ask() const {
        int best = std::numeric_limits<int>::max();
        for (const auto& a : asks) best = std::min(best, a.price);
        return best;
    }
};

int main() {
    std::vector<Update> replay{
        {Side::Bid, 10010, 5},
        {Side::Bid, 10020, 3},
        {Side::Ask, 10040, 4},
        {Side::Ask, 10035, 8},
        {Side::Bid, 10020, 0},
        {Side::Ask, 10035, 6},
        {Side::Bid, 10025, 7}
    };

    Book book;
    const auto t0 = std::chrono::steady_clock::now();

    for (const auto& u : replay) {
        book.apply(u);
    }

    const auto t1 = std::chrono::steady_clock::now();
    const auto ns = std::chrono::duration_cast<std::chrono::nanoseconds>(t1 - t0).count();

    std::cout << "best_bid=" << book.best_bid() << "\n";
    std::cout << "best_ask=" << book.best_ask() << "\n";
    std::cout << "replay_ns=" << ns << "\n";
}

Rakentaa

Linux tai macOS:

g++ -O2 -std=c++20 -o tiny_book main.cpp
./tiny_book

Windows:

cl /O2 /std:c++20 main.cpp
.\main.exe

Mitä tämä opettaa sinulle

Jopa tämä pieni uusintaohjelma herättää nopeasti todellisia HFT kysymyksiä:

• pitäisikö hintatason elää vektoreissa, kartoissa, taulukoissa tai mukautetuissa tikkaissa?
• mitä tapahtuu, kun uusinta kasvaa seitsemästä päivityksestä 7 miljoonaan?
• kuinka paljon aikaa kuluu tilapäivityksiin verrattuna raportointiin?
• missä allokaatiot näkyvät, jos rakenne laajenee dynaamisesti?

Esimerkki on pieni, mutta kysymykset eivät ole ollenkaan pieniä.

Testitehtävät harrastajille

1. Korvaa lineaarinen haku koodissa apply rakenteella, joka skaalautuu paremmin ja vertaa toistoaikoja.
2. Luo miljoona synteettistä päivitystä ja mittaa, kuinka naiivi rakenne heikkenee.
3. Lisää yksi tuottajasäie ja yksi kuluttajasäie SPSC-jonolla syötteen toiston ja kirjan päivityksen välillä ja vertaa sitten vakautta ja monimutkaisuutta.
4. Kiinnitä toistosäie Linux:n ytimeen ja vertaa run-to-run -varianssia.
5. Lisää tarkoituksellisesti meluisa lokipolku ja tarkkaile, kuinka nopeasti "vaaraton" virheenkorjauspäätös saastuttaa latenssimittaukset.

Nämä harjoitukset ovat vaatimattomia, ja juuri siksi ne ovat hyviä. Todellinen matalan latenssin suunnittelu on rakennettu monista vaatimattomista rakenteista, jotka joko valitaan huolellisesti tai katuvat myöhemmin.

Yhteenveto

C++ on edelleen keskeinen korkean taajuuden kaupankäynnissä, koska HFT pyrkii rakentamaan deterministisiä matalan viiveen järjestelmiä koko polulle markkinatiedoista tilausten siirtoon ja pitämään nämä järjestelmät riittävän ymmärrettävinä, jotta ne voidaan tehdä paineen alaisena. Tämä työ riippuu kurinalaisesta tietojen asettelusta, hillitystä allokoinnista, huolellisesta ketjutuksesta, rehellisestä profiloinnista, toistetusta validoinnista ja kulttuurista, joka arvostaa vakautta yhtä paljon kuin nopeutta.

Tästä syystä C++ pitää edelleen paikkansa. Se antaa insinööreille sen hallinnan tason, työkalujen syvyyden ja historiallisen käytännön, jota tällä alalla edelleen palkitaan. Muut kielet voivat edistää ja auttavat kaupankäyntipinoissa, mutta kun ongelma on itse kuuma polku, C++ on edelleen yksi vahvimmista tunnetuista tavoista muuttaa suorituskyky iskulauseesta toistettavaksi suunnitteluominaisuudeksi.

Viitteet

1. NASDAQ TotalView-ITCH: ITCH
2. DPDK-dokumentaatio: https://doc.dpdk.org/guides/
3. Linux socket API man page: Linux
4. Linux aikaleimadokumentaatio: Linux
5. Linux PTP-laitteiston kelloinfrastruktuuri: Linux
6. Linux Linux -man sivu: https://man7.org/linux/man-pages/man1/perf.1.html
7. Brendan Greggin liekkikaaviot: https://www.brendangregg.com/flamegraphs.html
8. Intel VTune Profiler -dokumentaatio: https://www.intel.com/content/www/us/en/docs/vtune-profiler/overview.html

   Miltä tämä näyttää, kun järjestelmä on jo paineen alainen

C++ korkean taajuuden kaupankäynnissä on yleensä kiireellinen juuri sillä hetkellä, kun joukkue toivoi hiljaisempaa neljännestä. Ominaisuus on jo asiakkaiden edessä tai alustalla on jo sisäinen riippuvuus, ja järjestelmä on valinnut kyseisen viikon paljastaakseen, että sen elegantti teoria ja sen ajonaikainen käyttäytyminen ovat eläneet kohteliaasti erillistä elämää. Tästä syystä niin moni vakava insinöörityö alkaa sovinnolla. Tiimin on sovitettava yhteen se, mitä se uskoo järjestelmän tekevän, sen kanssa, mitä järjestelmä todella tekee kuormitettuna, muutoksen aikana ja sellaisissa määräajoissa, jotka tekevät kaikista hieman luovempia ja hieman vähemmän viisaita.

Pienen latenssin järjestelmissä tärkeimmät tapaukset ovat yleensä markkinatietojen käsittely, tilausten reititys determinististen budjettien mukaisesti sekä regression ohjauksen työnkulkujen uudelleentoisto ja profilointi. Näillä tilanteilla on teknisiä, budjetti-, luottamus-, tiekartta- ja joskus mainevaikutuksia. Tekninen ongelma kasvaa poliittisesti suuremmiksi sillä hetkellä, kun useat tiimit ovat riippuvaisia ​​siitä, eikä kukaan voi selittää, miksi se käyttäytyy edelleen kuin pesukarhu seinien sisällä: meluisa yöllä, vaikea paikantaa ja kallis jättää huomiotta.

Siksi suosittelemme lukemaan ongelman käyttöpaineen ja toimitustodellisuuden linssin läpi. Suunnittelu voi olla teoreettisesti kaunis ja toiminnallisesti tuhoisa. Toinen malli voi olla melkein tylsä ​​ja silti viedä tuotetta eteenpäin vuosia, koska se on mitattavissa, korjattavissa ja rehellinen kompromissiensa suhteen. Vakavat insinöörit oppivat pitämään parempana toista luokkaa. Se tekee vähemmän eeppisiä puheita, mutta myös vähemmän hätätapahtumia, joissa kaikki puhuvat passiivisella äänellä eikä kukaan muista, kuka hyväksyi pikakuvakkeen.

Käytännöt, jotka vanhenevat jatkuvasti hyvin

Ensimmäinen kestävä käytäntö on pitää yksi edustava polku jatkuvassa mittauksessa. Ryhmät keräävät usein liian paljon epämääräistä telemetriaa ja liian vähän päätöslaatuista signaalia. Valitse polku, jolla on aidosti merkitystä, mittaa sitä toistuvasti ja kieltäydy antamasta keskustelua ajautua koristeelliseen tarinankerrontaan. C++:n ympärillä korkean taajuuden kaupankäynnissä hyödyllisiä toimenpiteitä ovat yleensä hännän latenssi, jonokuri, välimuistin sijainti ja toiminnan toistettavuus. Kun ne ovat näkyvissä, loput päätökset muuttuvat inhimillisemmiksi ja vähemmän mystisiksi.

Toinen kestävä käytäntö on erottaa todiste lupauksesta. Insinöörejä painostetaan usein sanomaan, että suunta on oikea, ennen kuin järjestelmä on ansainnut tämän johtopäätöksen. Vastusta sitä painetta. Rakenna ensin kapea todiste, varsinkin kun aihe on lähellä asiakkaita tai rahaa. Pienellä todennetulla parannuksella on enemmän kaupallista arvoa kuin suurella todentamattomalla kunnianhimolla. Tämä kuulostaa itsestään selvältä, kunnes vuosineljänneksen lopun tarkastelu muuttaa hypoteesin määräajaksi ja koko organisaatio alkaa kohdella optimismia kuin aikataulutusartefaktia.

Kolmas kestävä käytäntö on kirjoittaa suositukset omistajakielellä. Kappale, jossa sanotaan "parantaa suorituskykyä" tai "vahvistaa rajoja", on emotionaalisesti miellyttävä ja toiminnallisesti hyödytön. Kappale, joka kertoo kuka muuttaa mitä, missä järjestyksessä, millä palautusehdon kanssa, on se, joka todella selviää maanantaiaamuna. Täällä monet tekniset kirjoittamiset epäonnistuvat. Se haluaa kuulostaa enemmän edistyneeltä kuin se haluaa olla aikataulutettu.

Vastaesimerkkejä, jotka säästävät aikaa

Yksi yleisimmistä vastaesimerkeistä näyttää tältä: tiimillä on jyrkkä paikallinen menestys, oletetaan, että järjestelmä on nyt ymmärretty, ja sitten skaalaa idean paljon vaativampaan ympäristöön ilman, että mittauskuria päivitetään. Se on tekninen vastine, kun opetellaan uimaan hotellin uima-altaassa ja sitten pidettäisiin itsevarma TED-puhe meren säästä. Vesi on vettä, kunnes sitä ei ole.

Toinen vastaesimerkki on työkalujen inflaatio. Uusi profiloija, uusi ajonaika, uusi kojelauta, uusi agentti, uusi automaatiokerros, uusi kääre, joka lupaa harmonisoida vanhan kääreen. Mikään näistä asioista ei ole luonnostaan ​​huono. Ongelmana on, mitä tapahtuu, kun heitä pyydetään kompensoimaan rajaa, jota kukaan ei ole nimennyt selvästi. Järjestelmästä tulee sitten instrumentoidumpi, vaikuttavampi ja vain toisinaan ymmärrettävämpi. Ostajat tuntevat tämän hyvin nopeasti. Jopa ilman tätä ilmaisua he voivat haistaa, kun pinosta on tullut kallis korvike päätökselle.

Kolmas vastaesimerkki on ihmisen tarkastelun käsitteleminen automaation epäonnistumisena. Todellisissa järjestelmissä ihmisen tarkastelu on usein ohjaus, joka pitää automaation kaupallisesti hyväksyttävänä. Aikuiset tiimit tietävät, missä automatisoida aggressiivisesti ja missä pitää hyväksyntä tai tulkinta näkyvänä. Epäkypsät tiimit haluavat koneen tekevän kaiken, koska "kaikki" kuulostaa tehokkaalta diassa. Sitten tapahtuu ensimmäinen vakava tapaus, ja yhtäkkiä manuaalinen tarkistus löydetään uudelleen konversiokokemuksen vilpittömästi.

Suosittelemamme toimitusmalli

Jos työ on tehty hyvin, ensimmäisen suorituksen pitäisi vähentää stressiä antamalla tiimille riittävän vahva tekninen lukema, jotta se lopettaa kiistelyn. Sen jälkeen seuraavan rajoitetun toteutuksen pitäisi parantaa yhtä ratkaisevaa polkua, ja uudelleentestauksen pitäisi tehdä suunta luettavaksi sekä suunnittelulle että johdolle. Tämä järjestys on tärkeämpi kuin tarkka työkaluvalinta, koska se muuttaa teknisen taidon eteenpäinliikkeeksi.

Käytännössä suosittelemme kapeaa ensimmäistä sykliä: kerää esineitä, tee yksi kova diagnoosi, lähetä yksi rajoitettu muutos, testaa todellinen polku uudelleen ja kirjoita seuraava päätös selkeällä kielellä. Selkeällä kielellä on väliä. Ostaja harvoin katuu selkeyttä. Ostaja katuu usein olevansa vaikuttunut ennen kuin kuitit saapuvat.

Tässä myös sävyllä on väliä. Vahvan teknisen työn pitäisi kuulostaa siltä kuin se on kohdannut tuotannon ennenkin. Rauhallinen, tarkka ja hieman huvittunut hypeistä sen sijaan, että se ravitsee sitä. Tämä ääni välittää toimintasignaalin. Se osoittaa, että tiimi ymmärtää järjestelmäsuunnittelun vanhan totuuden: koneet ovat nopeita, tiekartat ovat hauraita, ja ennemmin tai myöhemmin lasku saapuu jokaisesta olettamuksesta, jonka annettiin pysyä runollisena.

Tarkistuslista, jota käyttäisimme ennen kuin kutsumme tämän valmiiksi

Matalan latenssin järjestelmissä valmius ei ole mieliala. Se on tarkistuslista, jolla on seurauksia. Ennen kuin kutsumme kiertämään C++ korkean taajuuden kaupankäynnissä valmiina laajempaan käyttöönottoon, haluamme, että muutama asia on tylsää parhaalla mahdollisella tavalla. Haluamme yhden polun, joka käyttäytyy ennustettavasti edustavan kuormituksen alla. Haluamme yhden mittasarjan, joka ei ole ristiriidassa itsensä kanssa. Haluamme joukkueen tietävän, missä raja menee ja mitä sen rikkominen merkitsisi. Ja haluamme työn tulosten olevan riittävän selkeitä, jotta joku toteutushuoneen ulkopuolella voi silti tehdä siitä järkevän päätöksen.

Tämä tarkistuslista koskettaa yleensä viivettä, jonokuria, välimuistin sijaintia ja toiminnan toistettavuutta. Jos luvut liikkuvat oikeaan suuntaan, mutta tiimi ei silti osaa selittää järjestelmää improvisoimatta, työ ei ole valmis. Jos arkkitehtuuri kuulostaa vaikuttavalta, mutta ei kestä vaatimatonta vastaesimerkkiä kentältä, teos ei ole valmis. Jos toteutus on olemassa, mutta palautustarina kuulostaa rukoukselta aikaleimoineen, teos ei ole valmis. Mikään näistä ei ole filosofisia vastaväitteitä. Ne ovat yksinkertaisesti muotoja, joissa kalliilla yllätyksillä on tapana esitellä itsensä.

Täällä myös tiimit huomaavat, ratkoivatko he todellista ongelmaa vai vain harjoittelivat osaamista sen yleisessä läheisyydessä. Monet tekniset ponnistelut tuntuvat onnistuneilta, kunnes joku pyytää toistettavuutta, tuotantotodisteita tai päätöstä, joka vaikuttaa budjettiin. Sillä hetkellä heikko työ hämärtyy ja vahva työ muuttuu oudon selväksi. Plain on hyvä. Pelkkä tarkoittaa yleensä sitä, että järjestelmä on lakannut luottamasta karismaan.

Kuinka suosittelemme puhumaan tuloksista

Lopullisen selityksen tulee olla riittävän lyhyt selviytyäkseen johtajuuden kokouksesta ja riittävän konkreettinen selviytyäkseen teknisestä katsauksesta. Se on vaikeampaa kuin miltä se kuulostaa. Liian tekninen kieli piilottaa järjestyksen. Liian yksinkertaistettu kielenkäyttö piilottaa riskin. Oikea keskitie on kuvata polkua, todisteita, rajallista muutosta ja seuraavaa suositeltua askelta tavalla, joka kuulostaa mieluummin rauhalliselta kuin voittoisalta.

Suosittelemme tällaista rakennetta. Sano ensin, mitä polkua arvioitiin ja miksi sillä oli merkitystä. Toiseksi sano, mikä oli vialla tai epävarmaa kyseisessä polussa. Kolmanneksi sano, mitä muutettiin, mitattiin tai vahvistettiin. Neljänneksi sano, mikä on vielä ratkaisematta ja mitä seuraava sijoitus ostaisi. Tämä rakenne toimii, koska se kunnioittaa sekä suunnittelua että ostokäyttäytymistä. Insinöörit haluavat yksityiskohtia. Ostajat haluavat sekvensoinnin. Kaikki haluavat vähemmän yllätyksiä, myös ihmiset, jotka teeskentelevät nauttivansa niistä.

Tällä tavalla puhumisen piilotettu hyöty on kulttuurinen. Tiimit, jotka selittävät teknisen työn selkeästi, tekevät sen yleensä myös selkeämmin. He lakkaavat käsittelemästä monitulkintaisuutta hienostuneisuutena. Heihin on vaikeampi tehdä vaikutuksen ammattikieltä ja helpompi luottaa vaikeiden järjestelmien kanssa. Se on yksi insinööritaidon aliarvostetuimmista muodoista.

Mitä emme edelleenkään kieltäytyisi väärentämästä

Jopa järjestelmän parantumisen jälkeen kypsät tiimit pitävät epävarmuuden rehellisenä matalan latenssin järjestelmissä. Heikko mittaus vaatii selkeämpää näyttöä, kovat rajat selkeää kieltä ja rauhallisemmat demot todellista toimintavalmiutta. Epävarmuutta on vähennettävä; jotkut on nimettävä rehellisesti. Nämä kaksi tehtävää sekoitetaan siinä, kuinka kunniallisista projekteista tulee kalliita vertauksia.

Sama sääntö koskee C++:a koskevia päätöksiä korkean taajuuden kaupankäynnissä. Jos tiimiltä puuttuu edelleen toistettava vertailukohta, luotettava palautuspolku tai selkeä omistaja kriittiselle käyttöliittymälle, hyödyllisin tulos voi olla terävämpi ei tai kapeampi seuraava askel suuremman lupauksen sijaan. Tämä kurinalaisuus pitää teknisen työn linjassa sen todellisuuden kanssa, jota sen on tarkoitus parantaa.

Tällä työskentelyllä on outo helpotus. Kun järjestelmä ei enää ole riippuvainen optimistisesta tarinankerronnasta, insinöörikeskustelu yksinkertaistuu, vaikka työ olisikin kovaa. Ja tuotannossa se on usein vähäistä armon muotoa.

Lisähuomautuksia korkean taajuuden kaupankäyntijärjestelmistä

HFT:ssä malli ansaitsee kunnioituksen, kun se käyttäytyy paineen alaisena samalla tavalla kuin tarkastuksessa. Se on harvinaisempaa kuin markkinointiosastot haluaisivat ja paljon arvokkaampaa kuin tyylikäs pseudomatematiikka diassa. Deterministinen latenssi ei ole iskulause. Se on tulosta tuhansista tylsistä valinnoista, jotka on tehty oikein ja tarkistettu uudelleen, kun laitteisto, kääntäjä, ydin tai työmäärä muuttuu jollain pienellä ja loukkaavalla tavalla.

Suosittelemme myös käsittelemään uusintapeliä ja kaupan jälkeistä tutkimusta pinon ensiluokkaisina kansalaisina. Nopeista järjestelmistä, jotka eivät pysty selittämään itseään, tulee kalliita kulttuurisia ongelmia. Kauppiaat haluavat nopeutta. Insinöörit haluavat totuuden. Compliance haluaa kirjaa. Parhaat C++ HFT-järjestelmät kunnioittavat kaikkia kolmea teeskentelemättä, että ne ovat sama keskustelu. Tämä tasapaino on yksi syy C++ on edelleen niin tärkeä: se antaa joukkueelle tarkan hallinnan käyttäytymisessä jättäen samalla riittävästi tilaa ympäröivälle kurinalaiselle, mikä tekee nopeudesta uskottavan.

Kentän muistiinpanot todellisesta teknisestä katsauksesta

C++-järjestelmätoimituksessa työ muuttuu vakavaksi, kun demo kohtaa todellisen toimituksen, todelliset käyttäjät ja todelliset käyttökustannukset. Se on hetki, jolloin siisti idea alkaa käyttäytyä kuin järjestelmä, ja järjestelmillä on tunnetusti kuiva huumorintaju. He eivät välitä siitä, kuinka tyylikkäältä aloituspakka näytti. He välittävät rajoista, vikatiloista, käyttöönottopoluista ja siitä, voiko kukaan selittää seuraavan vaiheen keksimättä uutta mytologiaa pinon ympärille.

C++ in High-Frequency Trading: From Market Data to Deterministic Latency:n kohdalla käytännön kysymys on, luoko se vahvemman toimituspolun ostajalle, jolla on jo paineita etenemissuunnitelman, alustan tai tietoturvatarkastuksen suhteen. Tuo ostaja ei tarvitse sumuksi kiillotettua luentoa. He tarvitsevat teknisen luennon, jota he voivat käyttää.

Mitä tarkastaisimme ensin

Aloitamme yhdellä edustavalla polulla: natiivi päättely, profilointi, HFT-polut, DEX-järjestelmät ja C++/Rust-modernisointivaihtoehdot. Tuon polun tulee olla tarpeeksi kapea mitatakseen ja riittävän leveä paljastaakseen totuuden. Ensimmäisen läpimenon pitäisi tallentaa allokointikäyttäytyminen, p99-viive, profiilin todisteet, ABI kitka ja vapauttaa luottamus. Jos nämä signaalit eivät ole saatavilla, projekti on edelleen enimmäkseen mielipidettä laboratoriotakissa, ja mielipiteellä on pitkä historia laskuttaa itsensä strategiana.

Ensimmäinen hyödyllinen artefakti on alkuperäisten järjestelmien luku, jossa on vertailuarvoja, profilointitodistusta ja laajennettu toteutussuunnitelma. Sen pitäisi näyttää järjestelmä sellaisena kuin se käyttäytyy, ei niin kuin kaikki toivoivat sen käyttäytyvän suunnittelukokouksessa. Jäljitys, toisto, pieni benchmark, politiikkamatriisi, jäsennyslaite tai toistettava testi kertovat usein tarinan nopeammin kuin toinen abstrakti arkkitehtuurikeskustelu. Hyvät esineet ovat hämmästyttävän töykeitä. Ne keskeyttävät toiveajattelua.

Vastaesimerkki, joka säästää aikaa

Kallis virhe on vastata ratkaisulla, joka on suurempi kuin ensimmäinen hyödyllinen todiste. Tiimi näkee riskin tai viiveen ja tavoittaa välittömästi uuden alustan, uudelleenkirjoituksen, laajan refaktorin tai hankintaystävällisen kojelaudan, jonka nimi kuulostaa siltä kuin se tekee joogaa. Joskus tämä mittakaava on perusteltu. Hyvin usein se on tapa lykätä mittausta.

Parempi liike on pienempi ja terävämpi. Nimeä raja. Ota todisteet talteen. Muuta yksi tärkeä asia. Testaa samaa polkua uudelleen. Päätä sitten, kannattaako seuraava investointi olla suurempi. Tämä rytmi on vähemmän dramaattinen kuin muutosohjelma, mutta sillä on taipumus selviytyä kosketuksista budjetteihin, julkaisukalentereihin ja tuotantotapahtumiin.

Suosittelemamme toimitustapa

Luotettavimmassa mallissa on neljä vaihetta. Kerää ensin edustavia esineitä. Toiseksi, muuta nämä esineet yhdeksi vaikeaksi tekniseksi diagnoosiksi. Kolmanneksi lähetä yksi rajoitettu muutos tai prototyyppi. Neljänneksi, testaa uudelleen samalla mittauskehyksellä ja dokumentoi seuraava päätös selkeällä kielellä. Tässä työluokassa CMake-kalusteet, profilointivaljaat, pienet alkuperäiset reprot ja kääntäjä/ajonaikaiset muistiinpanot ovat yleensä arvokkaampia kuin toinen tapaus yleisestä suunnasta.

Selkeällä kielellä on väliä. Ostajan tulee pystyä lukemaan tulos ja ymmärtämään, mikä muuttui, mikä on edelleen riskialtista, mikä voi odottaa ja mitä seuraava askel ostaisi. Jos suositusta ei voida ajoittaa, testata tai määrittää omistajalle, se on silti liian koristeellinen. Koristeellinen tekninen kirjoittaminen on miellyttävää, mutta tuotantojärjestelmiä ei tunneta miellyttävyyden palkitsemisesta.

Kuinka arvioida, auttoiko tulos

Kohdassa C++ in High-Frequency Trading: From Market Data to Deterministic Latency tuloksen pitäisi parantaa ainakin yhtä kolmesta asiasta: toimitusnopeus, järjestelmän luottamus tai kaupallinen valmius. Jos se ei paranna mitään näistä, tiimi on saattanut oppia jotain, mutta ostaja ei ole vielä saanut hyödyllistä tulosta. Sillä erolla on merkitystä. Oppiminen on jaloa. Myös palkallisen toimeksiannon pitäisi siirtää järjestelmää.

Vahvin tulos voi olla kapeampi tiekartta, kieltäytyminen vaarallisen polun automatisoinnista, parempi raja mallin ympärille, puhtaampi natiiviintegraatio, mitattu todiste siitä, että uudelleenkirjoitusta ei vielä tarvita, tai lyhyt korjauslista, jonka johto voi todella rahoittaa. Vakava suunnittelu on sarja parempia päätöksiä, ei pukukilpailua työkaluista.

Miten SToFU suhtautuisi asiaan

SToFU käsittelee tätä ensin toimitusongelmana ja sitten teknologiaongelmana. Tuomme asiaan liittyvän suunnittelusyvyyden, mutta pitäisimme sitoutumisen ankkuroituna todisteisiin: polkuun, rajaan, riskiin, mittaukseen ja seuraavaan tekemisen arvoiseen muutokseen. Tarkoitus ei ole saada kovaa työtä kuulostamaan helpolta. Tarkoitus on tehdä seuraavasta vakavasta liikkeestä riittävän selkeä suoritettavaksi.

Sitä osaa ostajat yleensä arvostavat eniten. He voivat palkata mielipiteitä missä tahansa. He tarvitsevat tiimin, joka voi tarkastaa järjestelmän, nimetä todellisen rajoitteen, rakentaa tai vahvistaa oikean osion ja jättää taakseen artefakteja, jotka vähentävät sekaannusta puhelun päätyttyä. Meluisillä markkinoilla selkeys ei ole pehmeä taito. Se on infrastruktuuri.