Uma interface conversacional para a arquitetura, dicionários de mensagens, perfis de venue e suite de benchmarks do NexusFIX. 182 perguntas respondidas por especialistas indexadas e ancoradas na base de código ao vivo. E uma thread ao vivo quando a resposta enlatada não basta.
Olá, sou o especialista NexusFIX, ancorado no código fonte público, CSVs de benchmark e nas 182 respostas selecionadas indexadas nesta página.
Escolha uma thread à direita, ou pergunte qualquer coisa abaixo. Se a resposta não estiver no código, vou dizer.
Como o NexusFIX consegue zero alocações de heap?
Três substituições, todas no caminho quente:
1. Vistas std::span<const char> no buffer original substituem cópias de std::string. O span ocupa 16 bytes na pilha. Sem heap, sem cópia, sem destrutor.
2. Um array pré-indexado substitui std::map para busca de campos. O acesso ao campo torna-se um único mov indexado pelo número de tag FIX.
3. std::pmr::monotonic_buffer_resource fornece alocação arena para o que realmente precisa de um slot. O arena é pré-dimensionado e reutilizado por sessão.
O resultado: 0 chamadas malloc no caminho quente, verificado por meio de um alocador personalizado que instrumenta cada alloc/free e faz o teste falhar se algum disparar.
As oito perguntas que aparecem em quase toda conversa. Clique para expandir. Ou traga-a de volta para a thread ao vivo acima.
O QuickFIX foi desenhado no início dos anos 2000 em torno de idiomas C++98/03: dispatch virtual, alocação de heap por mensagem, armazenamento de campo baseado em strings. Estes padrões são fundamentalmente incompatíveis com latência sub-microssegundo.
Começámos pelos primeiros princípios usando capacidades C++23 que não existiam quando o QuickFIX foi desenhado. Std::span, std::expected, std::pmr, conceitos e consteval. E perguntámos: como seria um motor FIX se não se carregassem vinte anos de decisões de alocador?
Empresas de trading quantitativo e equipas de infraestrutura que precisam de processamento de mensagens FIX determinístico e sub-microssegundo.
Especificamente: empresas que executam estratégias co-localizadas, equipas que constroem gateways de trading personalizados, e engenheiros C++ que estudam técnicas modernas de desempenho num codebase real e público.
Vistas std::span
O resultado: zero chamadas malloc no caminho quente, verificado por meio de um arnês de instrumentação de alocador personalizado que corre em cada build de CI.
std::expected para tratamento de erros (sem exceções no caminho quente), std::span para vistas de dados zero-copy, conceitos para validação de interface em tempo de compilação, consteval para computação em tempo de compilação, e hints de branch [[likely]]/[[unlikely]].
Cada uma destas teria requerido uma implementação personalizada na era do QuickFIX.
As instruções AVX2 carregam 32 bytes de cada vez e usam comparação vectorizada para encontrar delimitadores SOH (\x01) em paralelo. Isto é ~13× mais rápido do que scan byte a byte.
A técnica é inspirada no simdjson mas adaptada à semântica do protocolo FIX. Ou seja, a estrutura tag=value=SOH significa que podemos localizar cada fronteira de campo numa única passagem vectorizada e depois construir a tabela de offsets.
FIX 4.4 tem suporte completo e é a mais comum em produção. FIX 5.0 + FIXT 1.1 também tem suporte completo com apenas 2% de overhead em relação ao 4.4.
O índice estrutural é agnóstico à versão. O scan de campos funciona de forma idêntica entre versões FIX. Os overlays de dialecto personalizados tratam tags específicos do venue no bind da sessão.
O NexusFIX está em desenvolvimento activo e ainda não foi implantado em ambientes de trading produtivos. Os benchmarks vêm de ambientes controlados com pinning de CPU e aquecimento de cache.
Endurecimento de produção. Testes de soak, cobertura de modos de falha, certificação contra gateways de venues específicos. É um esforço de engenharia separado. Se está a considerá-lo para prod, fale connosco primeiro.
O Fix8 (C++11) usa pools de objectos e técnicas zero-copy, e é um dos motores FIX open source mais sofisticados.
O NexusFIX difere ao aproveitar funcionalidades da biblioteca padrão C++23 (PMR, std::span, std::expected) em vez de implementações personalizadas. Menos peças móveis para auditar. E ao adicionar parsing acelerado por SIMD, que o Fix8 não tem.
Faça-a na thread ao vivo acima. Ou abra uma issue no GitHub. Cada pergunta com uma resposta com fontes e útil entra no conjunto indexado na próxima versão.