Mas estou aqui para convencê-lo da noção oposta, contra-intuitiva, quase herética: quando se trata de obter baixa latência em sistemas de software, Java é melhor.

Como desenvolvedores, todos nós sabemos que existem duas maneiras de fazer as coisas: a maneira manual, lenta, chata e complicada, e a maneira automatizada, rápida e ainda mais complicada. 

Eu poderia, por exemplo, continuar a escrever este artigo sobre por que você deve usar Java em vez de C ++ para sistemas de baixa latência. Eu poderia começar a treinar IA para escrever para mim. A última abordagem, eventualmente, me pouparia muito tempo escrevendo artigos - poderia gerar milhares por segundo -, mas meu editor provavelmente não ficará feliz em saber que o primeiro artigo vai levar dois anos.

Existe uma situação análoga quando se trata de desenvolver sistemas de software de baixa latência. O que se sabe é que você seria louco se usasse qualquer coisa que não fosse C ++ porque qualquer outra coisa tem uma latência muito alta. Mas estou aqui para convencê-lo da noção oposta, contra-intuitiva, quase herética: quando se trata de obter baixa latência em sistemas de software, Java é melhor.

[Mergulhe fundo no mundo da tecnologia e cadastre-se no Avance Network a verdadeira comunidade criptografada]

Neste artigo, quero dar um exemplo específico de software para o qual a baixa latência é valorizada; sistemas de negociação. No entanto, os argumentos que apresento aqui podem ser aplicados a quase todas as circunstâncias em que a baixa latência é necessária ou desejada. Só que é mais fácil discutir isso em relação a uma área de desenvolvimento na qual tenho experiência. E a verdade é que a latência pode ser uma coisa complicada de medir.

Tudo se resume à sua definição de "baixa latência". Deixe-me explicar…

A sabedoria recebida

Vamos começar examinando os motivos pelos quais você deve preferir C ++ para construir sistemas de alta velocidade e baixa latência. 

Como C ++ está muito mais próximo do metal, a maioria dos desenvolvedores dirá a você, há uma vantagem de velocidade inerente à codificação na linguagem. Em situações de baixa latência, como negociação em alta velocidade, em que microssegundos podem fazer a diferença entre um software viável e um desperdício de espaço em disco obsoleto, C ++ é considerado o padrão ouro.

Ou pelo menos era, uma vez. A realidade é que, atualmente, muitos bancos e corretoras de grande porte usam sistemas escritos em Java. E quero dizer escrito em Java - não escrito em Java e depois interpretado em C ++ em busca de uma latência mais baixa. Esses sistemas estão se tornando padrão, mesmo para bancos de investimento de Nível 1, apesar de serem (supostamente) mais lentos.

Então o que está acontecendo? 

Bem, C ++ pode ser de “baixa latência” quando se trata de execução de código, mas definitivamente não é baixa latência quando se trata de lançar novos recursos ou mesmo encontrar desenvolvedores que possam escrevê-lo. 

As diferenças (reais) entre Java e C ++

Essa questão de tempo de desenvolvimento é, no entanto, apenas o começo quando se trata das diferenças reais entre Java e C ++ em sistemas do mundo real. Então, para entender o verdadeiro valor de cada linguagem neste contexto, vamos descompactá-los um pouco.

Primeiro, é importante lembrar a razão real pela qual C ++ é mais rápido que Java na maioria das situações: um ponteiro C ++ é o endereço de uma variável na memória. Isso significa que o software pode acessar diretamente variáveis ​​individuais e não precisa passar por tabelas caras de computação para localizá-las. Ou pelo menos pode, se for informado onde eles estão - porque com C ++, você frequentemente terá que gerenciar explicitamente o tempo de vida e a propriedade de objetos. 

O resultado disso é que, a menos que você seja muito, muito bom em escrevê-lo (uma habilidade que pode levar décadas para ser dominada), C ++ exigirá horas (ou semanas) de depuração. E, como qualquer pessoa que já tentou depurar um mecanismo de Monte Carlo ou um solucionador de PDE lhe dirá, tentar depurar o acesso à memória em um nível fundamental pode ser extremamente demorado. Um ponteiro quebrado sozinho pode travar facilmente um sistema inteiro, portanto, enviar uma nova versão escrita em C ++ pode ser verdadeiramente assustador.

Esta não é toda a história, é claro. Pessoas que gostam de programar em C ++ (todos os três) apontarão que o coletor de lixo (GC) em Java sofre de picos de latência não linear . Este é particularmente o caso ao trabalhar com sistemas legados e, portanto, enviar atualizações para o código Java, embora não danifique os sistemas de seus clientes, pode torná-los tão lentos que se tornam inutilizáveis.

Em resposta, gostaria de salientar que muito trabalho foi feito para reduzir a latência gerada pelo Java GC na última década. LMAX Disruptor, por exemplo, é uma plataforma de negociação de baixa latência escrita em Java, mas também construída como uma estrutura que tem “simpatia mecânica” pelo hardware em que está sendo executado e que não tem travamento. 

Os problemas podem ser ainda mais atenuados se você estiver construindo um sistema que usa um processo de integração e entrega contínua (CI / CD), porque o CI / CD permite a implantação automatizada de alterações de código testadas. Isso ocorre porque o CI / CD permite uma abordagem iterativa para melhorar as latências de GC, em que Java pode ser progressivamente aprimorado e adaptado para ambientes de hardware específicos, sem o processo intensivo de recursos de preparação de código para diferentes especificações de hardware antes de enviá-lo. 

Como o suporte IDE para Java é muito mais avançado do que para C ++, a maioria dos ambientes (Eclipse, IntelliJ, IDEA) será capaz de refatorar Java. Isso significa que a maioria dos IDEs permitirá que você otimize o código para ser executado com baixa latência, um recurso que ainda é limitado ao trabalhar com C ++. 

Mesmo que não corresponda ao C ++ em desempenho bruto, a maioria dos desenvolvedores será capaz de alcançar um desempenho aceitável em Java muito mais facilmente do que em C ++. O verdadeiro assassino da latência vem entre ter uma ideia e enviar o código para ela.

O que queremos dizer com mais rápido?

Na verdade, há um bom motivo para questionar a ideia de que C ++ é genuinamente “mais rápido” ou tem uma “latência menor” do que Java. Estou ciente, neste ponto, que estou entrando em algumas águas muito turvas e que muitos desenvolvedores podem começar a questionar minha sanidade. Mas me escute.

Primeiro, há o ponto (um pouco absurdo) de que se você tiver dois desenvolvedores, um escrevendo em C ++ e outro em Java, e pedir a eles para escreverem uma plataforma para negociação de alta velocidade do zero, o desenvolvedor Java vai negociar por muito tempo antes do desenvolvedor C ++. Para desenvolvedores que não usam as duas linguagens, aqui está o motivo: Java tem muito menos instâncias de comportamento indefinido do que C ++. Para dar apenas um exemplo, indexar fora dos limites de uma matriz é um erro em Java e C ++. Se você acidentalmente fizer isso em C ++, você pode gerar um segfault ou (mais comumente) apenas receber de volta algum número aleatório que não significará nada, mesmo para desenvolvedores experientes. Em Java, a indexação fora dos limites sempre lança umArrayIndexOutOfBoundsException. Isso significa que a depuração é significativamente mais fácil em Java, porque os erros tendem a gerar erros imediatamente e a localização do bug é mais fácil de rastrear.  

Além disso, e pelo menos na minha experiência, Java (na maioria dos ambientes) é simplesmente melhor em reconhecer quais partes do código não precisam ser executadas e quais são essenciais para o funcionamento do seu software. É claro que você pode passar dias ajustando seu código C ++ para que ele não contenha absolutamente nenhum código estranho, mas no mundo real cada pedaço de software contém algum inchaço, e Java é melhor em reconhecê-lo automaticamente.

Isso significa que, no mundo real, Java geralmente é mais rápido que C ++, mesmo em medidas padrão de latência. E mesmo onde não está, a diferença de latência entre os idiomas é frequentemente sufocada por outros fatores, ou nem de longe grande o suficiente para fazer a diferença, mesmo em negociações de alta frequência. Muito se falou, por exemplo, da latência reduzida das redes 5G - até 1 ms, de acordo com alguns analistas - mas na programação de baixa latência isso ainda representa um custo de desempenho significativo.

As vantagens do Java para sistemas de baixa latência

Todos esses fatores, a meu ver, constituem um caso bastante inatacável para usar Java para escrever plataformas de negociação de alta velocidade (e, de fato, sistemas de baixa latência em geral, mais sobre isso em breve). 

No entanto, apenas para influenciar um pouco mais os entusiastas de C ++, vamos examinar uma série de razões adicionais para usar Java:

Em primeiro lugar, e como já vimos acima, qualquer latência em excesso que o Java introduz em seu software provavelmente será muito menor do que os coletores de latência existentes, como atrasos de comunicação de rede, em (pelo menos) um dos sistemas que as negociações devem ser antes de ser concluído. Isso significa que qualquer código Java (bem escrito) pode funcionar tão bem quanto o C ++ na maioria das situações de negociação.

O menor tempo de desenvolvimento de Java também significa que, no mundo real, o software escrito em Java pode ser mais rapidamente adaptado a mudanças de hardware (ou mesmo novas estratégias de negociação) do que C ++.

Leve essa ideia ainda mais longe e você verá que até mesmo otimizar o software Java pode ser mais rápido - se analisado em todo um software - do que a tarefa equivalente em C ++. Como Peter Lawrey, um consultor Java interessado em baixa latência e alta em todos os sistemas, disse à InfoQ recentemente, “se seu aplicativo gasta 90% do tempo em 10% do seu código, Java torna a otimização 10% mais difícil, mas escrevendo e mantendo 90 % do seu código mais fácil; especialmente para equipes de habilidade mista. ”

Em outras palavras, é possível escrever Java, do nível da máquina para cima, para baixa latência. Você só precisa escrever como C ++, com o gerenciamento de memória em mente em cada estágio de desenvolvimento. A vantagem de não escrever em C ++ é que a depuração, o desenvolvimento ágil e a adaptação a vários ambientes são simplesmente mais fáceis e rápidos em Java.

E daí?

Se você chegou até aqui e não está desenvolvendo sistemas de negociação de baixa latência, provavelmente deve estar se perguntando se alguma das opções acima se aplica a você. A resposta - com muito poucas exceções - é sim. 

O debate sobre como alcançar baixa latência não é novo e não é exclusivo do mundo das finanças. Por esse motivo, é possível aprender lições valiosas sobre outras situações com ele. Em particular, o argumento acima - que Java é “melhor” porque é mais flexível, mais resiliente e, em última análise, mais rápido de desenvolver e manter - pode ser aplicado a muitas áreas de desenvolvimento de software.

As razões pelas quais eu (pessoalmente) prefiro escrever sistemas de baixa latência em Java são as mesmas que tornaram a linguagem um sucesso nos últimos 25 anos . Java é fácil de escrever, compilar, depurar e aprender, e isso significa que você pode gastar menos tempo escrevendo código e mais tempo otimizando-o para latência. Em última análise, no mundo real, isso resulta em sistemas de negociação mais rápidos e confiáveis. E, para negociações de alta velocidade, isso é tudo o que importa.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.