C++, Rust ja High Frequency Trading: Missä deterministinen latenssi ratkaisee väitteen

Johdanto

Ohjelmointikieliset keskustelut ovat yleensä suvaita, koska useimmilla järjestelmillä on varaa vähän teatteria. Palvelu on vähän tehoton, jono levenee kuin sen pitäisi, uudelleenyrityspolitiikka tekee jotain moraalisesti kyseenalaista ja kaikki jatkavat liikkeessä, koska tuote toimii edelleen, tulot laskeutuvat edelleen ja latenssikaavio on ruma selviytymiskelpoisella tavalla. Joukkueet voivat viettää viikkoja kiistellen puhtaudesta, koska järjestelmä itsessään on tarpeeksi kohtelias, jotta ei lyödä heitä heti.

Korkean taajuuden kaupankäynti on vähemmän sentimentaalista. Sillä ei ole väliä, mikä kieli voitti internetin tällä vuosineljänneksellä, millä konferenssipuheella oli puhtaimmat diat tai mikä uudelleenkirjoitusaloite sai ihmiset tuntemaan tulevaisuuden vihdoin saapuneen. Se välittää siitä, muuttuuko markkinatiedoista tila, tilasta päätös ja päätöksestä tilaus ennen kuin ikkuna sulkeutuu. Tällaisessa ympäristössä elegantit mielipiteet, jotka eivät kestä mittausta, ryöstetään nopeasti ja yleensä ilman varoitusta.

Tästä syystä kysymys C++:sta ja Rust:sta HFT:ssä on mielenkiintoinen. Ei siksi, että yksi kieli on pyhä ja toinen petollinen, vaan koska HFT on yksi harvoista aloista, joka pakottaa koko väitteen rahaksi järjestelmän todellisessa toiminnassa. Kuuma polku joko säilyttää muotonsa paineen alaisena tai ei. Hännän latenssi joko pysyy kurinalaisena tai ei. Replay joko kertoo totuuden tai ei. Arkkitehtuuri ei ole siellä persoonallisuustesti. Se on lasku, johon on liitetty kello.

Ja HFT on epätavallisen rehellinen siitä, mistä lasku tulee. Se ei ole vain itse täsmäytys- tai suoritusikkuna. Kustannukset kertyvät syötteiden jäsentämiseen, kirjojen ylläpitoon, sarjoitukseen, ytimien väliseen viestintään, kuormituksen aiheuttamaan tärinään ja kaikkiin pieniin "luultavasti hienoihin" päätöksiin, joista tulee julkista nöyryytystä, kun järjestelmä joutuu todellisen tapahtumapaikan liikenteen kohteeksi. Markkinoilla on julma lahja muuntaa epämääräinen insinöörikieli täsmällisiksi tappioiksi.

Tästä syystä vastaus ei ole "C++ ikuisesti" tai "kirjoita kaikkea uudelleen Rustiin, koska turvallisuus on hyvä asia ja pelko on liiketoimintamalli." Rehellisempi vastaus on kapeampi ja siksi hyödyllisempi. C++ hallitsee edelleen kuumimpia HFT polkuja, koska ympäröivä työkalujen, syötteiden käsittelyn, muistinhallinnan, profiloinnin ja laitteiston kanssa vierekkäisten käytäntöjen maailma on edelleen erittäin C++ muotoinen. Rust on aidosti hyödyllinen tämän ytimen ympärillä ja joskus sen huolellisesti valituissa osissa, mutta se ei poista perusasiaa, että alhaisen latenssin kaupankäynti rankaisee abstraktiovirheitä nopeammin kuin useimmat tiimit voivat nimetä aloitteen uudelleen.

Oikea keskustelu ei siis ole identiteetistä. Kyse on järjestelmän rajoista. Mitkä pinon osat tarvitsevat julman muistin, asettelun, jonojen, affiniteetin ja johtojen toiminnan hallinnan? Mitkä osat hyötyvät eniten vahvemmista oikeellisuusrajoituksista ja turvallisemmista oletusarvoista? Mitkä osat ansaitsevat hybridikäsittelyn heimopuhtauden sijaan? Nämä kysymykset ovat paljon vähemmän lumoavia kuin kielisaarnat, mutta ne ovat myös kysymyksiä, jotka selviävät kosketuksesta tuotantoon, ja kysymykset, jotka antavat ryhmille mahdollisuuden tehdä yhteistyötä todisteiden ympärillä iskulauseiden sijaan.

Miksi HFT saa huonon teknisen filosofian näyttämään kalliilta?

HFT on epätavallisen hyvä paljastamaan tutun insinöörivalheen: valheen, jonka mukaan keskimääräinen käyttäytyminen riittää. Monissa tavallisissa tuotteissa järjestelmä voi pysyä kunniallisena piilottaen satunnaisen kaaoksen suorituskyvyn, uudelleenyritysten tai käyttäjän kärsivällisyyden taakse. HFT:ssä keskimääräinen latenssi on mielenkiintoinen, mutta hännän käyttäytyminen on usein se osa, joka todella nöyryyttää sinua. Järjestelmä, joka näyttää nopealta, kunnes se nykii väärään aikaan, ei ole nopea järjestelmä kaupallisesti mielekkäässä mielessä. Se on luottamustemppu, johon on liitetty vertailukohta.

Tästä syystä HFTin insinöörit ovat allergisia epätarkille abstraktioille. He oppivat, että yksi ylimääräinen allokaatio kuumalla polulla ei ole "vain yksi allokaatio". Se on mahdollinen tärinän lähde. Yksi jonohyppy ei ole "vain yksi jonohyppy". Se on toinen paikka, johon aika tallentuu, koordinaatio laajenee ja näkyvyys huononee. Yksi välimuistiin vihamielinen rakenne ei ole vain esteettinen virhe. Se on jatkuva vero jokaisesta järjestelmän läpi kulkevasta markkinatapahtumasta. Kerro se todellisella syöttömäärällä, ja yhtäkkiä diakannen suunnitteluvalinnasta tulee pettymysbudjetin toistuva rivikohta.

Domainin julmuus on, että se rankaisee myös osittaisista selityksistä. Ryhmä voi tunnistaa yhden ilmeisen latenssilähteen ja silti missata todellisen rikoksentekijän, koska ketju on kumulatiivinen. Muistin asettelupäätös laajentaa välimuistin puuttumisprofiilia. Tämä laajentaa jonotusikkunaa. Tämä muuttaa järjestelmän käyttäytymistä purskeen liikenteessä. Tämä muuttaa järjestystä, jossa "harvinainen" haarakäyttäytyminen näkyy. Sitten joku kävelee post mortemiin ja sanoo, että ongelma oli "verkkokohina", joka on tekninen koodi "emme ole vielä lopettaneet totuuden kertomista".

Rust astuu tähän keskusteluun oikeutetulla voimalla, koska muistin turvallisuus ja samanaikaisuuden oikeellisuus ovat tärkeitä ja järjestelmäkoodi ansaitsee parempia oletusarvoja kuin "ole varovainen jongleeraatessasi veitsillä kuopan päällä". Tuo osa on totta. Mutta HFT ei palkitse totuutta erikseen. Se palkitsee yhdistetyn totuuden. Turvallisuus on tärkeää, kyllä. Samoin kypsät rehunkäsittelijät, vakaat ABI-rajat, toistotyökalut, profiiliohjattu iteraatio, kypsä vaihdon integraatiokulttuuri ja mahdollisuus tarkastaa tarkasti, mitä kone tekee, kun markkinat ovat epäystävälliset. C++ tulee yhä enemmän ympäröivää infrastruktuuria useimpiin HFT-ympäristöihin.

This is one reason buyers and engineering leaders should resist purity narratives. Kieli voi olla erinomainen kapeassa ulottuvuudessa ja silti väärä oletusarvo pinon ajoitusherkimmälle osalle, jos ympäröivä ekosysteemi, työkalut ja tiimin kokemus eivät tue varsinaista toimituspolkua. HFT is where lovely local truths go to learn that the whole path still matters more. The stack does not care that one claim was morally elegant if the resulting system is operationally incoherent.

Siellä myös tiimiekologia on tärkeämpää kuin ihmiset myöntävät. Yhteistyöryhmä, jolla on kurinalainen uusintavaljaat, yhteinen latenssisanasto ja tylsän hyvät profilointitottumukset, päihittää yleensä muodikkaamman tiimin, joka hämmentää todisteiden makua. HFT palkitsee vahvan teknisen kulttuurin luotettavammin kuin muodikkaan muuttovoiman.

Pino ei ole yksi asia, joten kielivalinnan ei pitäisi teeskennellä toisin

Yksi typerimmistä virheistä vakavassa järjestelmätyössä on puhua "HFT-pinosta" ikään kuin se olisi yksi tekninen organismi, jolla on yksi suositeltu kieli. Se ei ole. Se on kokoelma polkuja, joilla on hyvin erilaiset paineet ja epäonnistumiskustannukset.

Markkinatietojen käsittelypolulla on yksi temperamentti. Tilauskirjan päivityspolulla on toinen. Strategialogiikka voi olla numeerisesti tiheä, mutta rakenteellisesti kapea. Riskitarkistukset ovat usein latenssiherkkiä, mutta myös oikeellisuusherkkiä tylsällä, aikuisella, lainmukaisella tavalla. Simulaatio- ja toistoinfrastruktuuri voi arvostaa determinismia ja itsetutkiskelua raakana nanosekunnin turhamaisuuden sijaan. Ohjaustason työkalut, käyttöönoton apulaitteet ja käyttöpinnat välittävät luotettavuudesta, ylläpidettävyydestä ja integrointihygieniasta paljon enemmän kuin ne välittävät viiden mikrosekunnin ajoreitistä, jota kukaan asiakas ei koskaan näe.

Näiden kerrosten välillä on myös ihmistoiminnallisia eroja. Joitakin polkuja muokkaa päivittäin laajempi tiimi. Joihinkin kosketetaan harvoin ja vain valvonnassa. Jotkut komponentit tarvitsevat aggressiivista jäljitettävyyttä, koska vaatimustenmukaisuus tai auditointi herättävät lopulta vaikeita kysymyksiä. Jotkut tarvitsevat vain tiukasti rajatun suorituskyvyn ja erinomaisen toiston. Niiden käsitteleminen yhtenä päätöksenä johtaa siihen, että organisaatiot joko modernisoivat rauhallisia komponentteja tai hallitsevat vaarallisia komponentteja.

Tällä on merkitystä, koska siitä alkaa usein järkevä C++- ja Rust-keskustelu. C++ pysyy vahvimpana, kun polku on raa'an kuuma, laitteistotietoinen, integraatioraskas ja sitä ympäröi jo vuosien natiivi käyttökäytäntö. Rust:sta tulee houkuttelevampi, kun polku on edelleen tärkeä, mutta vahvempien maksuhäiriöiden, selkeämmän omistajuuden ja suppeamman muistiriskialtistuksen taloudellinen arvo ylittää ekosysteemien kitkan kustannukset.

Käytännössä se johtaa usein hybridituloksiin. Kuumimmat syötteenkäsittely- ja yhdyskäytäväreitit pysyvät C++issa. Toistotyökalut, asetusten validointi, tietyt riskipuolen apuohjelmat, viestien normalisointiapuohjelmat, auditointityökalut tai sisäiset käyttäjäkohtaiset komponentit voivat olla erinomaisia ​​Rust-ehdokkaita. Tämä ei ole päättämättömyyttä. Se on arkkitehtonista aikuisuutta. Järjestelmää käsitellään todellisten rajojen joukkona pikemminkin kuin kielifandomina, jossa on datakeskus.

Ja tässä monet uudelleenkirjoitusehdotukset tulevat vihdoin rehellisiksi. Kun tiimi kartoittaa pinon polun polulta, fantasia yhdestä universaalista vastauksesta romahtaa. Tuo romahtaminen on terveellistä. Se antaa organisaatiolle luvan optimoida näyttöä, ylläpidettävyyttä, toiminnallista luottamusta ja toimitusrytmiä sen sijaan, että sillä olisi yksinkertaisen iskulauseen tarjoama tunnemukavuus.

Missä C++ omistaa edelleen kuumimmat polut

C++ säilyttää paikkansa HFT:ssä syistä, jotka ovat vähemmän mystisiä kuin ulkopuoliset joskus kuvittelevat. Ensimmäinen syy on muistin ja asettelun hallinta. HFT kuumat polut välittävät siitä, mitkä tiedot elävät yhdessä, kuinka rakenteet käyttäytyvät välimuistissa, kuinka omistajuus näkyy kuormitettuna ja voiko järjestelmä pysyä allokoinnin kurinalaisena, kun markkinat lakkaavat olemasta kohteliaita. C++ antaa edelleen insinööreille epätavallisen suoraa vaikutusvaltaa näihin valintoihin, ja se tekee niin ekosysteemissä, joka on jo vuosikymmeniä oppinut, mitkä "pienet" kustannukset ovat salaa suuria.

Toinen syy on työkalujen tiheys. C++ in HFT ei tarkoita vain kieltä. Se tarkoittaa kääntäjiä, desinfiointiaineita, liekkikaavioita, C++, VTunea, toistovaljaita, vaihtosovittimia, jonotusperinteitä, allokaattoriasiantuntemusta ja valtavaa joukkoa taloudellisen paineen alaisena kertynyttä suorituskykysotatarinoita. Joukkueet eivät aloita siellä nollasta. He perivät syvän toimintakulttuurin, ja sillä on merkitystä, koska HFT palkitsee mitatun iteroinnin paljon enemmän kuin retorista puhtautta.

Kolmas syy on integraation painovoima. Vaihteet, alkuperäiset verkkopolut, pakettien sieppaustyökalut, ytimen viereinen optimointi, FPGA:n viereinen infrastruktuuri ja koko matalan viiveen ekosysteemi ovat edelleen erittäin mukavia C- ja C++-maailmassa. Rust voi olla vuorovaikutuksessa tuon maailman kanssa, ja joskus erittäin tehokkaasti, mutta "voi olla vuorovaikutuksessa" ei ole sama asia kuin "on pienimmän kitkan polku koko järjestelmän läpi". Vakavassa HFTissa kitka ei ole emotionaalinen haitta. Se on samanaikaisesti mahdollinen latenssivero, virheenkorjausvero ja toimitusvero.

On myös hienovaraisempi syy, joka on tärkeämpi tekoälyn aikakaudella: C++:lla on yksinkertaisesti enemmän toimintamuistia käytettävissä tämän työn ympärille. Tekoälykoodausjärjestelmät, koodihaku, julkiset esimerkit, toimittajan katkelmat, optimoijien kansanperinteet ja virheenkorjausreitit ovat tiheämpiä C++:n ympärillä matalan viiveen järjestelmissä kuin Rust:n ympäristössä. Se ei tee C++:sta jalompaa. Se helpottaa ihmisten ja tekoälytyökalujen yhteistyötä rumien todellisten koodikantojen sisällä, joiden viehätys vanheni vuosia sitten.

Toinen etu on, että monet HFT-tiimit ovat jo muuttaneet C++:sta institutionaaliseksi lihasmuistiksi. He osaavat profiloida sen tapahtumapaikan paineen alla. He osaavat riisua määrärahoja epäilyttäviltä poluilta. He tietävät, miltä "riittävän nopea mikrobenchmarkissa" kuulostaa, kun se on muuttumassa vääräksi tuotannossa. Se eletty tieto ei ole romanttista, mutta se on toiminnallisesti arvokasta. Tiimin, joka jo osaa pitää C++ rehellisenä, ei pitäisi heittää sitä pois kevyesti vain siksi, että uudempi kieli tuntuu yksinään puhtaammalta.

Tästä syystä C++ pysyy vahvimpana ei pelkästään syntaksina, vaan myös ympäröivänä käsityöjärjestelmänä. Kun lisäät sisäiset kirjastot, testausvaljaat, kaappaustyökalut, lankaaffiniteettitottumukset, lihasten vapauttamisen ja diagnoosityönkulkuja, et enää vertaa kieltä toiseen tyhjiössä. Vertaat yhtä kokonaista toimitusekosysteemiä toiseen. HFT:ssä ekosysteemit ylittävät usein ihanteet.

Missä Rust todella auttaa moraalin suorittamisen sijaan

Rust auttaa eniten, kun se ratkaisee todellisen ongelman sen sijaan, että se toimisi arkkitehtuurikaavioiden persoonallisuuden lisävarusteena. HFT:ssä vahvimmat Rust-käyttötapaukset näkyvät usein kuuman ytimen ympärillä sen sijaan, että ne olisivat sen absoluuttisessa keskustassa.

Rust on hyödyllinen komponenteille, joissa virheellisyydet ovat kalliita, mutta latenssibudjettia ei mitata mikroskoopilla. Viestien vahvistuskerrokset, konfigurointi- ja käyttöönottotyökalut, tietyt protokollien normalisointipolut, ohjauspalvelut, hallintaohjelmat, offline-analysaattorit ja sisäiset operaattorin työkalut voivat hyötyä kielen eksplisiittisyydestä. Tarkoitus ei ole näyttää nykyaikaiselta. Tarkoituksena on vähentää tyhmien, toistuvien, rakenteellisesti vältettävissä olevien virheiden luokkaa, jotka vievät huomion tärkeämmästä työstä.

Rust voi myös auttaa huolella valituissa lähes kuumissa komponenteissa, kun tiimillä on oikea asiantuntemus ja raja on rehellinen. Pienen latenssin jäsentäjä, rajoitetun tilan kone tai osa determinististä infrastruktuuria voivat olla vankka Rust-ehdokas, jos tiimi pystyy pitämään FFI- ja allokointitarinan hallinnassa ja jos ympäröivä ekosysteemin kuormitus ymmärretään etukäteen sen sijaan, että se havaitaan kello 2.40 aamulla käyttöönoton aikana, jota kukaan ei halunnut.

Siitä on usein apua myös työhön liittyvässä työssä. Sieppausprosessorit, offline-kirjantoistolaitteet, auditointiapuohjelmat, käyttöönoton validointi tai strategian vieressä oleva infrastruktuuri hyötyvät tiukemmasta omistajuudesta ja selkeämmistä käyttöliittymistä, vaikka ne eivät olisikaan ehdoton nanosekunnin taistelukenttä. Näillä osilla on merkitystä, koska ne määrittävät, kuinka nopeasti tiimi pystyy diagnosoimaan tapaukset, toistamaan poikkeavuuksia ja siirtymään turvallisesti epäilystä vahvistettuun ymmärrykseen.

Mutta juuri tässä joukkueet tarvitsevat kurinalaisuutta. Rust ei ole arvokas, kun se pudotetaan alkuperäisen kauppapinon keskelle uskoon perustuvana remonttina. Se on arvokasta, kun raja on puhdas, mittauspolku selvä ja integroinnin käyttökustannukset ovat alhaisemmat kuin sen luoma turvallisuus- tai ylläpidettävyyshyöty. Muuten projektista tulee kaunis tapaustutkimus siitä, kuinka käyttää vakavaa insinöörityöaikaa siirtämällä epävarmuutta sivuttain.

Tämä on todellinen anti-malli, jota tulee välttää: Rust:n käyttäminen, mutta sen käyttäminen naamioimaan arkkitehtonisen selkeyden puuttuminen. Jos tiimi ei pysty selittämään, mistä omistajuus alkaa, missä latenssi mitataan, missä puskurit risteävät ja missä palautuminen tapahtuu stressin alla, kielen vaihtaminen ei pelasta suunnittelua. Se vain tekee epäonnistumisesta kaksikielisemmän.

Rajalla on enemmän merkitystä kuin saarnalla

Yleinen virhe C++-keskusteluissa Rust-keskusteluissa on oletus, että Rust:n käyttäminen poistaa vaaran automaattisesti. Se ei tee. Se muuttaa vaaran sijaintia. HFT:ssä tämä rajakysymys on erityisen tärkeä, koska kuumat polut päättyvät harvoin kieliriville. Ne päättyvät verkon rajoihin, jonorajoihin, ajoitusrajoihin, FFI-rajoihin ja data-asettelun rajoihin.

Jos Rust-komponentin täytyy siirtyä C++-vaihtosovittimeen, puhua natiivijonolle, luovuttaa tiedot strategiamoottorille tiukoilla layout-olettamuksilla tai ylläpitää determinististä käyttäytymistä rajasiirtymien yli, todellinen suunnittelutyö ei ole "käytimme Rust". Todellinen työ on se, kuinka huolellisesti sauma määriteltiin ja tarkistettiin. Epäturvallista toimintaa voi silti esiintyä ABI-epävastaavuuden, omistajuuden hämmennyksen, piilokopioiden, jonotusvirheiden tai ajoitusyllätysten vuoksi. Kieli ei yksin ole hallintomallisi. Raja on.

Tästä syystä kypsät tiimit puhuvat kapeasta kuumasta polusta ja kapeasta vaarallisesta pinnasta. He eivät luota iskulauseisiin, kuten "muistin turvallisuus oletusarvoisesti", ratkaistakseen pohjimmiltaan järjestelmän suunnitteluongelman. Hyvät tiimit kysyvät rumia ja siten hyödyllisempiä kysymyksiä. Missä kopiointi tapahtuu? Missä on jonohyppy? Kumpi puoli omistaa puskurin? Mikä polku jakaa? Mitä tapahtuu vastapaineen aikana? Mikä on toistettavissa? Mitä voidaan verrata erillään ja mitä on verrattava päästä päähän, koska paikallisilla voitoilla on pitkä perinne muuttua maailmanlaajuisiksi pettymyksiksi?

Rajojen selkeyden voitto ei ole vain suorituskyky. Se on organisatorista järkeä. Kun saumat ovat selkeitä, tiimit voivat jakaa vastuunsa menettämättä vastuuta. Suorituskykyinsinöörit tietävät, mitä mitataan. Alustan ihmiset tietävät, mihin ei saa koskea rennosti. Turvallisuus- ja riskitiimit voivat perustella vikapintoja. Ostajat ja johtajuus saavat teknisen luennon, joka estää huoneen riitelemästä piireissä. Hyvä raja ei pelkästään auta kääntäjää. Se auttaa yritystä.

Tämä on yksi syy HFT-arkkitehtuuri hyötyy yhteistyöhaluisesta, ekosysteemilähtöisestä asennosta sankariasennon sijaan. Parhaita järjestelmiä ei yleensä rakenna yksi puhtautta osoittava henkilö. Ne on rakennettu ryhmässä, joka sopi rajapinnoista, mittauksista ja vikojen omistajuudesta niin perusteellisesti, että järjestelmä pysyy selitettävissä, vaikka markkinat lakkaavat olemasta ystävällisiä.

Käytännön tapaukset, jotka kannattaa ratkaista ensin

Älykkäin ensimmäinen projekti on harvoin "kirjoita kuuma polku uudelleen". Se on tekninen vastine taloon astumiselle ja päättämiselle, että ensimmäinen hyödyllinen teko on vaihtaa koko luuranko ennen kuin tarkistetaan, mikä putki jo tulvii keittiöön.

Parempi ensimmäinen projekti on yksi näistä:

Rehunkäsittelijän todisteet toimivat

Jos ryhmä kiistää siitä, onko jäsentäminen, normalisointi, jonottaminen tai yhteysvastuun vaihto todellakin latenssiongelma, luo ensin todisteiden polku. Kaappaa edustavaa liikennettä, toista se deterministisesti ja pakota järjestelmä tunnustamaan, missä aika ja tärinä todella tulevat ketjuun. Useimmat HFT-järjestelmät eivät tarvitse lisää ideologiaa tähän. He tarvitsevat paremman valheenpaljastimen.

Todistuspolun tulisi olla riittävän hyvä, jotta suorituskykyiset ihmiset, kehittäjät ja johtajat voivat käyttää samaa jäljitystä, kun tarvitaan kovaa priorisointikutsua. Kun ajoitustarina on jaettu, puolet poliittisesta kitkasta katoaa, koska huone ei enää neuvottele huhujen kanssa.

Yhdyskäytävän ja riskirajojen puhdistus

Ydinstrategialogiikka ei pilaa monia pinoja. Ne ovat pilalla riskin, yhdyskäytävän logiikan ja toiminnan koordinoinnin välisen rajahuimauksen vuoksi. Huolellinen uudelleenkirjoitus tai uudelleenjärjestely noissa saumoissa voi parantaa luotettavuutta ja diagnosoitavuutta ilman kaupallista riskiä koskettaa ehdottomasti kuuminta silmukkaa ensin.

Täällä myös vahvemmat kielitakuut voivat luoda todellista taloudellista arvoa. Jos tilauksen vahvistaminen, kuristaminen ja riskiviestintä helpottuvat, koko järjestelmä rauhoittuu. Rauhalliset järjestelmät ovat nopeampia muuttaa ja halvempia hallita.

Hybridiohjaustason puhdistus

Jos operaattorityökalut, käyttöönottoapuohjelmat, palautustyökalut tai toistotyökalut ovat hauraita, Rust voi olla siinä vahva ehdokas. Nämä komponentit muokkaavat usein koko organisaation terveyttä, vaikka ne eivät olekaan nopeimmalla mikrosekunnin polulla. Puhtaammat työkalut voivat tehdä kuumasta järjestelmästä rauhallisemman teeskentelemättä, että kaikki kiinteistön binaarit ansaitsevat saman kielen.

Piilotettu voitto tässä on terveys. Paremmat työkalut vähentävät aamukahden arkeologian määrää, jonka tiimin on suoritettava vain vastatakseen perustoiminnallisiin kysymyksiin. Tämä tarkoittaa vähemmän hätärituaaleja, vähemmän hauraita yhden henkilön järjestelmiä ja parempaa pitkän aikavälin teknistä yhteistyötä. Kypsissä insinööriorganisaatioissa sillä on enemmän merkitystä kuin ihmiset sanovat ääneen.

Hands-On Lab: Rakenna pieni sekvenssivälin ilmaisin ja tee siitä rehellinen

Pidetään laboratorio pienenä ja hyödyllisenä. HFT-järjestelmät elävät ja kuolevat sekvenssikurin mukaan kauan ennen kuin ne saavuttavat lumoavan strategialogiikan. Tämä leluohjelma toistaa syötemäisen streamin ja raportoi aukoista.

Harjoituksen tarkoitus ei ole se, että otat käyttöön juuri tämän koodin. Tarkoituksena on opettaa tapa säilyttää deterministinen tila paineen alaisena. Sekvenssikuri on yksi ensimmäisistä paikoista, joissa kaupankäyntijärjestelmä joko osoittaa kunnioittavansa todisteita tai osoittaa, että se edelleen bluffaa.

main.cpp

#include <cstdint>
#include <iostream>
#include <string>
#include <vector>

struct Packet {
    std::uint64_t seq;
    std::string payload;
};

struct Gap {
    std::uint64_t expected;
    std::uint64_t received;
};

class GapDetector {
public:
    void on_packet(const Packet& packet) {
        if (!started_) {
            expected_ = packet.seq + 1;
            started_ = true;
            return;
        }

        if (packet.seq != expected_) {
            gaps_.push_back({expected_, packet.seq});
        }

        expected_ = packet.seq + 1;
    }

    const std::vector<Gap>& gaps() const {
        return gaps_;
    }

private:
    bool started_ = false;
    std::uint64_t expected_ = 0;
    std::vector<Gap> gaps_;
};

int main() {
    std::vector<Packet> replay{
        {1001, "AAPL bid"},
        {1002, "AAPL ask"},
        {1003, "MSFT bid"},
        {1007, "MSFT ask"},
        {1008, "NVDA bid"},
        {1011, "NVDA ask"}
    };

    GapDetector detector;
    for (const auto& packet : replay) {
        detector.on_packet(packet);
    }

    if (detector.gaps().empty()) {
        std::cout << "no gaps\n";
        return 0;
    }

    for (const auto& gap : detector.gaps()) {
        std::cout << "gap expected=" << gap.expected
                  << " received=" << gap.received << "\n";
    }
}

Rakentaa

Linux tai macOS:

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

Windows:

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

Odotettu tulos:

gap expected=1004 received=1007
gap expected=1009 received=1011

Miksi tällä pienellä harjoituksella on merkitystä

Koska se pakottaa oikeanlaisen ajattelun:

• deterministinen tilapäivitys
• rehellinen sekvensointi
• toista ennen teoriaa
• rajallinen, mitattavissa oleva käyttäytyminen

Se on jo enemmän HFT kuin yllättävä määrä konferenssidioja.

Jos haluat tehdä harjoituksesta realistisemman, lisää aikaleimat, myöhässä saapuvat paketit ja paikkakohtaiset istunnon nollaukset. Tärkeintä ei ole tehdä koodista teatraalisempaa. Tärkeää on rakentaa refleksi, jonka mukaan jokaisen tiedonkulkua koskevan väitteen tulee olla testattavissa, toistettavissa ja tarpeeksi pieni selitettäviksi.

Testitehtävät harrastajille

1. Yhdistä sama ilmaisin Rust:iin ja vertaa rajojen selkeyttä, riippuvuuskitkaa ja sitä, kuinka helposti kukin versio sopii olemassa oleviin työkaluihisi.
2. Laajenna toistoa niin, että puuttuvat paketit voivat myöhemmin saapua epäkunnossa, ja päätä sitten, pitäisikö ilmaisimen puskuroida, hylätä vai merkitä ne.
3. Lisää ajoitus ja mittaa ero vektori- ja rengaspuskurituetun toiston välillä.
4. Ota käyttöön yksi tarpeeton jako kuumalle polulle ja mittaa kuinka nopeasti "pieni" päätös alkaa saastuttaa tulosta.
5. Lisää hakkuuhaara koodin on_packet sisään ja katso kuinka nopeasti havainnointi muuttuu sabotaasiksi, kun se asetetaan huolimattomasti.

Yhteenveto

The real C++ and Rust conversation in HFT is not about which language deserves the nicer mythology. Kyse on siitä, mitkä järjestelmän osat tarvitsevat suoraa ohjausta, mitkä osat hyötyvät vahvemmista oletusarvoista ja mitkä rajat voidaan tehdä tarpeeksi rehellisiksi tukemaan hybridisuunnittelua ilman harhaa.

C++ hallitsee edelleen kuumimpia HFT polkuja, koska verkkotunnus palkitsee muistin asettelun, jonotuksen, johtojen käyttäytymisen, profiloinnin, toiston ja integroinnin kypsän matalan latenssin ekosysteemin kanssa. Rust on hyödyllinen silloin, kun oikeellisuus, selkeys ja ylläpidettävyys luovat enemmän arvoa kuin ylimääräiset ekosysteemin kitkakustannukset. Molemmat voivat kuulua vakavaan pinoon. Aikuisten tehtävä on päättää missä ja antaa todisteiden säilyttää arvosanan kielen fanimin sijaan.

Joukkueet, jotka ymmärtävät tämän oikein, tekevät jotain erittäin epähohtoista ja erittäin tehokasta. He lakkaavat kysymästä, mikä kieli pelastaa heidät, ja alkavat kysyä, mikä raja ansaitsee minkälaisen kurin. Tuo muutos kuulostaa vaatimattomalta, mutta se on ero arkkitehtuurin brändäyksenä ja arkkitehtuurin toiminnallisena totuutena. HFT:ssä totuus yleensä vanhenee paremmin.

Viitteet

1. NASDAQ TotalView-ITCH: ITCH
2. FIX Kaupankäynnin yhteisön standardit: FIX
3. DPDK-dokumentaatio: https://doc.dpdk.org/guides/
4. Linux aikaleimadokumentaatio: Linux
5. Brendan Gregg Flame Graphsista: https://www.brendangregg.com/flamegraphs.html
6. Rust Performance Book: Rust