C++, Rust e negociação de alta frequência: onde a latência determinística decide o argumento

Introdução

Os debates sobre linguagens de programação são geralmente tolerados porque a maioria dos sistemas pode permitir um pouco de teatro. Um serviço é um pouco ineficiente, uma fila fica maior do que deveria, uma política de novas tentativas faz algo moralmente questionável e todos continuam em movimento porque o produto ainda funciona, a receita ainda chega e o gráfico de latência é feio de uma forma que permite sobreviver. As equipes podem passar semanas discutindo sobre pureza porque o próprio sistema é educado o suficiente para não esbofeteá-los imediatamente.

A negociação de alta frequência é menos sentimental. Não importa qual idioma ganhou a Internet neste trimestre, qual palestra da conferência teve os slides mais limpos ou qual iniciativa de reescrita fez as pessoas sentirem que o futuro finalmente havia chegado. Importa se os dados de mercado se tornam um estado, se o estado se torna uma decisão e se a decisão se torna uma ordem antes que a janela se feche. Nesse tipo de ambiente, opiniões elegantes que não conseguem sobreviver à medição são assaltadas rapidamente e geralmente sem aviso prévio.

É por isso que a questão de C++ e Rust em HFT é interessante. HFT é um dos raros domínios que força todo o argumento a se concretizar no comportamento real do sistema. O caminho quente mantém sua forma sob pressão ou não. A latência da cauda permanece disciplinada ou não. A repetição diz a verdade ou não. A arquitetura não é um teste de personalidade ali. É uma fatura com relógio anexado.

E HFT é extraordinariamente honesto sobre a origem da conta. Os custos começam antes e depois da janela de correspondência ou execução. Eles se acumulam na análise de feeds, manutenção de livros, serialização, comunicação entre núcleos, instabilidade sob carga e todas as pequenas decisões “provavelmente boas” que se tornam uma humilhação pública quando o sistema é submetido ao tráfego real do local. O mercado tem um dom cruel para converter linguagem vaga de engenharia em perdas exatas.

É também por isso que a resposta não é "C++ para sempre" ou "reescrever tudo em Rust porque a segurança é boa e o medo é um modelo de negócios". A resposta mais honesta é mais restrita e, portanto, mais útil. C++ ainda domina os caminhos mais quentes HFT porque o mundo circundante de ferramentas, manipulação de alimentação, controle de memória, criação de perfil e práticas adjacentes de hardware permanece extremamente moldado. Rust é genuinamente útil em torno desse núcleo e, às vezes, dentro de partes cuidadosamente escolhidas dele, mas não apaga o fato básico de que a negociação de baixa latência pune erros de abstração mais rápido do que a maioria das equipes consegue renomear a iniciativa.

Portanto, a conversa certa não é sobre identidade. Trata-se de limites do sistema. Quais partes da pilha precisam de controle brutal sobre memória, layout, filas, afinidade e comportamento de ligação? Quais partes se beneficiam mais de restrições de correção mais fortes e de padrões mais seguros? Quais partes merecem tratamento híbrido em vez de pureza tribal? Essas questões são muito menos glamorosas do que os sermões linguísticos, mas são também as questões que sobrevivem ao contacto com a produção e as questões que permitem às equipas cooperar em torno de evidências em vez de slogans.

Por que HFT faz com que a filosofia técnica ruim pareça cara

HFT é excepcionalmente bom em expor uma mentira familiar da engenharia: a mentira de que o comportamento médio é suficiente. Em muitos produtos comuns, um sistema pode permanecer respeitável enquanto esconde o caos ocasional por trás do rendimento, das novas tentativas ou da paciência do usuário. Em HFT, a latência média é interessante, mas o comportamento da cauda costuma ser a parte que realmente humilha você. Um sistema que parece rápido até se contorcer na hora errada não é um sistema rápido em nenhum sentido comercialmente significativo. É um truque de confiança com um benchmark anexado.

É por isso que os engenheiros da HFT se tornam alérgicos a abstrações imprecisas. Eles aprendem que uma alocação extra no caminho ativo não é “apenas uma alocação”. É uma possível fonte de jitter. Um salto de fila não é “apenas um salto de fila”. É outro lugar onde o tempo fica armazenado, a coordenação se expande e a visibilidade piora. Uma estrutura hostil ao cache torna-se um imposto contínuo sobre cada evento de mercado que passa pelo sistema. Multiplique isso pelo volume real de feed e, de repente, uma escolha de design em uma apresentação de slides se torna um item de linha recorrente no orçamento para decepção.

A crueldade do domínio é que ele também pune explicações parciais. Uma equipe pode identificar uma fonte óbvia de latência e ainda assim não perceber o verdadeiro infrator porque a cadeia é cumulativa. Uma decisão de layout de memória amplia o perfil de falta de cache. Isso amplia a janela de filas. Isso muda a forma como o sistema se comporta sob tráfego intermitente. Isso altera a ordem em que o comportamento "raro" do branch aparece. Então alguém entra na autópsia e diz que o problema era “ruído de rede”, que é um código de engenharia para “ainda não terminamos de dizer a verdade”.

Rust entra nesta conversa com força legítima porque a segurança da memória é importante, a correção da simultaneidade é importante e o código do sistema merece padrões melhores do que "por favor, tenha cuidado ao fazer malabarismos com facas em um buraco". Essa parte é verdade. Mas HFT não recompensa a verdade isoladamente. Recompensa a verdade combinada. A segurança é importante, sim. O mesmo acontece com manipuladores de feed maduros, limites ABI estáveis, ferramentas de repetição, iteração orientada por perfil, cultura madura de integração de troca e a capacidade de inspecionar exatamente o que a máquina está fazendo quando o mercado está indelicado. C++ ainda chega com mais infraestrutura circundante na maioria dos ambientes HFT.

Esta é uma das razões pelas quais os compradores e líderes de engenharia devem resistir às narrativas de pureza. Uma linguagem pode ser excelente em uma dimensão restrita e ainda assim ser o padrão errado para a parte mais sensível ao tempo de uma pilha se o ecossistema circundante, as ferramentas e a experiência da equipe não suportarem o caminho de entrega real. HFT é onde as lindas verdades locais vão para aprender que todo o caminho ainda é mais importante. A pilha não se importa com o fato de uma afirmação ser moralmente elegante se o sistema resultante for operacionalmente incoerente.

É também onde a ecologia da equipe é mais importante do que as pessoas admitem. Uma equipe cooperativa com um sistema de replay disciplinado, um vocabulário de latência compartilhado e bons hábitos de criação de perfil geralmente superará uma equipe mais elegante que mantém o gosto confuso por evidências. HFT recompensa a cultura técnica forte de forma mais confiável do que recompensa a energia de migração da moda.

A pilha não é uma coisa, então a escolha do idioma não deve fingir o contrário

Um dos erros mais estúpidos no trabalho sério de sistemas é falar sobre "a pilha HFT" como se fosse um único organismo técnico com uma linguagem preferida. Ele falha nesse teste. É uma coleção de caminhos com pressões e custos de falha muito diferentes.

O caminho de ingestão de dados de mercado tem um temperamento. O caminho de atualização da carteira de pedidos tem outro. A lógica estratégica pode ser numericamente densa, mas estruturalmente estreita. As verificações de risco costumam ser sensíveis à latência, mas também sensíveis à correção, de uma forma enfadonha, adulta e com consequências jurídicas. A infraestrutura de simulação e reprodução pode valorizar o determinismo e a introspecção em detrimento da vaidade bruta de nanossegundos. As ferramentas do plano de controle, os auxiliares de implantação e as superfícies do operador se preocupam muito mais com a confiabilidade, a capacidade de manutenção e a higiene da integração do que com a redução de cinco microssegundos de um caminho que nenhum cliente jamais verá.

Existem também diferenças humanos-operacionais entre essas camadas. Alguns caminhos são modificados diariamente por uma equipe mais ampla. Alguns são tocados raramente e apenas sob supervisão. Alguns componentes precisam de rastreabilidade agressiva porque a conformidade ou a auditoria acabarão por fazer perguntas difíceis. Alguns precisam apenas de desempenho restrito e excelente repetição. Tratá-los como uma decisão é a forma como as organizações acabam modernizando excessivamente os componentes calmos ou subgovernando os perigosos.

Isso é importante porque geralmente é onde começa uma conversa sensata entre C++ e Rust. C++ permanece mais forte quando o caminho é brutalmente quente, consciente do hardware, com muita integração e já cercado por anos de prática operacional nativa. Rust torna-se mais atraente quando o caminho ainda é importante, mas o valor económico de incumprimentos mais fortes, propriedade mais clara e exposição mais restrita ao risco de memória compensa o custo da fricção do ecossistema.

Na prática, isso muitas vezes leva a resultados híbridos. Os caminhos de gateway e manipulação de feed mais populares permanecem em C++. Ferramentas de repetição, validação de configuração, certos auxiliares de risco, utilitários de normalização de mensagens, ferramentas de auditoria ou componentes internos voltados para o operador podem ser excelentes candidatos Rust. Esta é a idade adulta arquitetônica. O sistema está sendo tratado como um conjunto de limites reais, e não como um fandom de linguagem com um datacenter.

E é aqui que muitas propostas de reescrita finalmente se tornam honestas. Depois que uma equipe mapeia a pilha caminho por caminho, a fantasia de uma única resposta universal tende a entrar em colapso. Esse colapso é saudável. Dá à organização permissão para otimizar evidências, capacidade de manutenção, confiança operacional e ritmo de entrega, em vez do conforto emocional de ter um slogan simples.

Onde C++ ainda possui os caminhos mais interessantes

C++ mantém seu lugar em HFT por razões que são menos místicas do que pessoas de fora às vezes imaginam. A primeira razão é o controle de memória e layout. HFT os caminhos quentes se preocupam com quais dados permanecem juntos, como as estruturas se comportam no cache, como a propriedade aparece sob carga e se o sistema pode permanecer disciplinado na alocação quando o mercado deixa de ser educado. C++ ainda oferece aos engenheiros um uso incomumente direto dessas escolhas, e faz isso dentro de um ecossistema que já passou décadas aprendendo quais custos “pequenos” são secretamente grandes.

A segunda razão é a densidade do ferramental. C++ em HFT não significa apenas uma linguagem. Isso significa compiladores, sanitizadores, gráficos em chamas, C++, VTune, chicotes de repetição, adaptadores de troca, folclore de filas, experiência em alocadores e um vasto corpo de histórias de guerra de desempenho acumuladas sob pressão financeira. As equipes não começam do zero aí. Eles herdam uma cultura operacional profunda, e essa cultura é importante porque HFT recompensa a iteração medida muito mais do que a limpeza retórica.

A terceira razão é a gravidade da integração. Exchanges, caminhos de rede nativos, ferramentas de captura de pacotes, otimização adjacente ao kernel, infraestrutura adjacente ao FPGA e todo o ecossistema de baixa latência ainda são muito confortáveis ​​em um mundo C e C++. Rust pode interagir com esse mundo, e às vezes de forma muito eficaz, mas "pode ​​interagir com" não é a mesma coisa que "é o caminho de menor atrito através de todo o sistema". Em FPGA sério], o atrito não é um inconveniente emocional. É uma possível taxa de latência, uma taxa de depuração e uma taxa de entrega ao mesmo tempo.

Há também uma razão mais sutil que é mais importante na era da IA: C++ simplesmente tem mais memória operacional disponível para este trabalho. Sistemas de codificação de IA, pesquisa de código, exemplos públicos, snippets de fornecedores, folclore de otimizador e trilhas de depuração são mais densos em torno de C++ em sistemas de baixa latência do que em torno de Rust. Isso não torna o C++ mais nobre. Isso torna mais fácil para humanos e ferramentas de IA colaborarem dentro de bases de código reais e feias, cujo charme expirou anos atrás.

Outra vantagem é que muitas equipes HFT já transformaram C++ em memória muscular institucional. Eles sabem como traçar o perfil sob pressão do local. Eles sabem como eliminar alocações de caminhos suspeitos. Eles sabem o que significa “rápido o suficiente no microbenchmark” quando está prestes a se tornar falso na produção. Esse conhecimento vivido é operacionalmente precioso. Uma equipe que já sabe como manter C++ honesto não deveria jogar isso fora levianamente só porque uma linguagem mais nova parece mais limpa isoladamente.

É por isso que C++ permanece mais forte como um sistema artesanal envolvente, não apenas como sintaxe. Depois de adicionar bibliotecas internas, equipamentos de teste, ferramentas de captura, hábitos de afinidade de thread, liberação de força e fluxos de trabalho de diagnóstico, você não estará mais comparando uma linguagem com outra no vácuo. Você está comparando todo um ecossistema de entrega com outro. Em HFT, os ecossistemas muitas vezes superam os ideais.

Onde Rust realmente ajuda em vez de praticar a moralidade

Rust ajuda mais quando está resolvendo um problema real, em vez de atuar como um acessório de personalidade para diagramas de arquitetura. Em HFT, os casos de uso mais fortes de Rust geralmente aparecem ao redor do núcleo quente, e não no centro absoluto dele.

Rust é útil para componentes onde as falhas de correção são caras, mas o orçamento de latência não está sendo medido com um microscópio. Camadas de validação de mensagens, ferramentas de configuração e implantação, certos caminhos de normalização de protocolo, serviços de controle, utilitários administrativos, analisadores offline e ferramentas de operadores internos podem se beneficiar da tendência da linguagem para a explicitação. A questão não é parecer moderno. O objetivo é reduzir a classe de erros estúpidos, repetitivos e estruturalmente evitáveis ​​que desviam a atenção de trabalhos mais importantes.

Rust também pode ajudar na escolha cuidadosa de componentes quase quentes quando a equipe tem o conhecimento certo e o limite é honesto. Um analisador de baixa latência, uma máquina de estado limitada ou uma peça de infraestrutura determinística pode ser um candidato sólido Rust se a equipe puder manter o FFI e a história de alocação sob controle e se a carga do ecossistema circundante for compreendida antecipadamente, em vez de descoberta às 2h40 da manhã, durante uma implementação que ninguém queria.

Muitas vezes também é útil no trabalho em torno do trabalho. Processadores de captura, reprodutores de livros off-line, auxiliares de auditoria, validação de implantação ou infraestrutura adjacente à estratégia se beneficiam de propriedade mais rigorosa e interfaces mais claras, mesmo quando não são o campo de batalha absoluto de nanossegundos. Essas peças são importantes porque determinam a rapidez com que a equipe pode diagnosticar incidentes, reproduzir anomalias e passar com segurança da suspeita ao entendimento verificado.

Mas é exatamente aqui que as equipes precisam de disciplina. Rust não tem valor quando é colocado no meio de uma pilha de negociação nativa como uma renovação baseada na fé. É valioso quando o limite é limpo, o caminho de medição é óbvio e o custo operacional da integração é menor do que o ganho de segurança ou de manutenção que ele cria. Caso contrário, o projeto se tornará um belo estudo de caso sobre como gastar muito tempo de engenharia movendo a incerteza para os lados.

O verdadeiro antipadrão é usar Rust para disfarçar a ausência de clareza arquitetônica. Se a equipe não conseguir explicar onde começa a propriedade, onde a latência é medida, onde os buffers cruzam e onde a recuperação ocorre sob estresse, alterar o idioma não salvará o design. Isso apenas tornará o fracasso mais bilíngue.

O limite é mais importante que o sermão

Um erro comum nas discussões C++ versus Rust é presumir que o uso de Rust remove automaticamente o perigo. Isso não acontece. Isso muda onde está o perigo. Em HFT, essa questão de limite é especialmente importante porque os caminhos quentes raramente terminam na linha da linguagem. Eles terminam em limites de rede, limites de fila, limites de agendamento, FFI limites e limites de layout de dados.

Se um componente Rust precisar cruzar para um adaptador de troca C++, falar com uma fila nativa, entregar dados para um mecanismo de estratégia com suposições de layout rígidas ou manter um comportamento determinístico através de transições de limites, então o verdadeiro trabalho de engenharia não é "usamos Rust". O verdadeiro trabalho é o cuidado com que a costura foi definida e verificada. O comportamento inseguro ainda pode ocorrer por meio de incompatibilidade, confusão de propriedade, cópias ocultas, erros de fila ou surpresas de tempo. A linguagem por si só não é o seu modelo de governança. O limite é.

É por isso que equipes maduras falam sobre um caminho estreito e quente e uma superfície estreita e insegura. Eles não confiam em slogans como “segurança de memória por padrão” para resolver o que é fundamentalmente um problema de projeto de sistema. Boas equipes fazem perguntas mais feias e, portanto, mais úteis. Onde a cópia acontece? Onde está o salto da fila? Qual lado possui o buffer? Qual caminho aloca? O que acontece durante a contrapressão? O que é reproduzível? O que pode ser avaliado isoladamente e o que deve ser avaliado de ponta a ponta, porque as vitórias locais têm uma longa tradição de se tornarem decepções globais?

A clareza dos limites também cria sanidade organizacional. Uma vez que as costuras sejam explícitas, as equipes podem dividir a responsabilidade sem perder a responsabilidade. Os engenheiros de desempenho sabem o que medir. O pessoal da plataforma sabe o que não deve ser tocado casualmente. As equipes de segurança e risco podem raciocinar sobre superfícies de falha. Os compradores e a liderança recebem uma leitura técnica que impede a discussão em círculos. Um bom limite ajuda o compilador e a empresa.

Essa é uma das razões pelas quais a arquitetura HFT se beneficia de uma postura cooperativa e voltada para o ecossistema, em vez de uma postura de herói. Os melhores sistemas geralmente não são construídos por uma pessoa que comprove pureza. Eles são construídos por um grupo que concorda em interfaces, medições e propriedade de falhas de forma tão completa que o sistema permanece explicável mesmo quando o mercado deixa de ser amigável.

Casos práticos que valem a pena resolver primeiro

O primeiro projeto mais inteligente raramente é “reescrever o caminho quente”. Isso equivale tecnicamente a entrar numa casa e decidir que o primeiro ato útil é substituir todo o esqueleto antes de verificar qual cano já está inundando a cozinha.

O melhor primeiro projeto é um destes:

Trabalho de evidência do manipulador de alimentos

Se a equipe discutir se a análise, a normalização, o enfileiramento ou a transferência são realmente o problema da latência, construa primeiro o caminho da evidência. Capture o tráfego representativo, reproduza-o de forma determinística e force o sistema a confessar onde o tempo e a instabilidade estão realmente entrando na cadeia. A maioria dos sistemas HFT não precisa de mais ideologia aqui. Eles precisam de um detector de mentiras melhor.

Esse caminho de evidência deve ser bom o suficiente para que o mesmo rastreamento possa ser usado por pessoas de desempenho, desenvolvedores e liderança quando for necessária uma chamada de priorização rígida. Uma vez partilhada a história do timing, metade da fricção política desaparece porque a sala já não está a negociar com rumores.

Limpeza de gateway e limite de risco

Muitas pilhas não são arruinadas pela lógica estratégica central. Eles são arruinados pela negligência dos limites entre risco, lógica de gateway e coordenação operacional. Uma reescrita ou reestruturação cuidadosa nessas costuras pode melhorar a confiabilidade e a capacidade de diagnóstico sem o risco comercial de tocar primeiro no loop mais quente.

É também aqui que garantias linguísticas mais fortes podem criar valor económico real. Se a validação de pedidos, a limitação e as mensagens de risco se tornarem mais fáceis de raciocinar, todo o sistema ficará mais calmo. Sistemas calmos são mais rápidos de mudar e mais baratos de governar.

Limpeza do plano de controle híbrido

Se as ferramentas do operador, os auxiliares de implantação, os utilitários de recuperação ou as ferramentas de reprodução forem frágeis, Rust pode ser um forte candidato. Esses componentes muitas vezes moldam a saúde de toda a organização, mesmo quando não estão no caminho mais rápido de microssegundos. Ferramentas mais limpas podem tornar o sistema quente mais calmo, sem fingir que todos os binários da propriedade merecem a mesma linguagem.

A vitória oculta aqui é a saúde. Melhores ferramentas reduzem a quantidade de arqueologia às 2 da manhã que uma equipe deve realizar apenas para responder a questões operacionais básicas. Isso significa menos rituais de emergência, menos sistemas individuais frágeis e melhor cooperação técnica a longo prazo. Em organizações de engenharia maduras, isso é mais importante do que as pessoas dizem em voz alta.

Laboratório prático: construa um pequeno detector de lacunas de sequência e torne-o honesto

Vamos manter o laboratório pequeno e útil. Os sistemas HFT vivem e morrem pela disciplina de sequência muito antes de atingirem uma lógica estratégica glamorosa. Este programa de brinquedo reproduz um fluxo semelhante a um feed e informa onde apareceram lacunas.

O objetivo do exercício não é implantar exatamente esse código. O objetivo é ensinar o hábito de preservar o estado determinístico sob pressão. A disciplina de sequência é um dos primeiros lugares onde um sistema de negociação prova que respeita as evidências ou prova que ainda está blefando.

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";
    }
}

Construir

Em Linux ou macOS:

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

Em Windows:

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

Resultado esperado:

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

Por que este pequeno exercício é importante

Porque força o tipo certo de pensamento:

• atualização de estado determinística
• sequenciamento honesto
• replay antes da teoria
• comportamento limitado e mensurável

Isso já é mais HFT do que um número surpreendente de slides de conferências.

Se você quiser tornar o exercício mais realista, adicione carimbos de data/hora, pacotes que chegam atrasados ​​e redefinições de sessão específicas do local. O que importa não é tornar o código mais teatral. O que importa é construir o reflexo de que cada afirmação sobre o fluxo de dados deve ser testável, reproduzível e pequena o suficiente para ser explicada.

Tarefas de teste para entusiastas

1. Transfira o mesmo detector para Rust e compare a clareza dos limites, o atrito de dependência e o ajuste com suas ferramentas existentes.
2. Estenda a repetição para que os pacotes perdidos possam chegar fora de ordem posteriormente e, em seguida, decida se o detector deve armazená-los em buffer, rejeitá-los ou sinalizá-los.
3. Adicione tempo e meça a diferença entre um replay apoiado por vetor e um replay apoiado por buffer de anel.
4. Introduza uma alocação desnecessária no caminho quente e meça a rapidez com que uma “pequena” decisão começa a contaminar o resultado.
5. Adicione uma ramificação de registro dentro de on_packet e observe como a observabilidade se torna rapidamente uma sabotagem quando colocada de maneira descuidada.

Resumo

A verdadeira conversa entre C++ e Rust em HFT não é sobre qual linguagem merece uma mitologia melhor. Trata-se de saber quais as partes do sistema que necessitam de controlo directo, quais as partes que beneficiam de padrões mais fortes e quais os limites que podem ser tornados suficientemente honestos para apoiar a concepção híbrida sem ilusões.

C++ ainda domina os caminhos mais populares HFT porque o domínio recompensa o controle sobre layout de memória, enfileiramento, comportamento de conexão, criação de perfil, reprodução e integração com um ecossistema maduro de baixa latência. Rust é útil onde a correção, a clareza e a facilidade de manutenção criam mais valor do que os custos adicionais de fricção do ecossistema. Ambos podem pertencer a uma pilha séria. A ação dos adultos é decidir onde e deixar que as evidências, e não o fandom da linguagem, registrem a pontuação.

As equipes que acertam isso fazem algo pouco glamoroso e muito eficaz. Eles param de perguntar qual linguagem irá salvá-los e começam a perguntar qual fronteira merece que tipo de disciplina. Essa mudança parece modesta, mas é a diferença entre a arquitetura como marca e a arquitetura como verdade operacional. Em HFT, a verdade geralmente envelhece melhor.

Referências

1. Especificação NASDAQ TotalView-ITCH: ITCH
2. FIX Padrões da comunidade comercial: FIX
3. Documentação DPDK: https://doc.dpdk.org/guides/
4. Linux documentação de carimbo de data/hora: Linux
5. Brendan Gregg em gráficos em chamas: https://www.brendangregg.com/flamegraphs.html
6. O livro de desempenho do Rust: Rust