Pourquoi Java est plus adapté que C++ aux systèmes de trading haute fréquence
Selon une idée reçue, la construction d’un système de trading haute fréquence vous amènera sans doute à coder en C++ plutôt qu’en Java : il est plus proche du langage machine et donc plus rapide, avec une plus faible latence. Pourtant, certains grands noms du domaine ne sont pas de cet avis.
Peter Lawrey, CEO de Chronicle Software, connaît plutôt bien la programmation à faible latence. Ancien ingénieur performance trading chez Barclays et développeur/chercheur du hedge fund Millenium Management (entre autres), il a fondé Chronicle en 2013 pour travailler sur les systèmes de trading haute fréquence. La société compte parmi ses clients dix banques d’investissement Tier one et de nombreux hedge funds d’envergure.
A l’origine, Chronicle proposait des prestations de conseil à des clients cherchant à construire des systèmes de trading à faible latence. Plus récemment pourtant, elle s’est repositionnée sur le conseil et ce qu’elle décrit comme un package d’« infrastructure [de trading] générique customisable » itérable. Et ce package est codé en Java.
« Si vous disposez de temps et de ressources illimités, la meilleure solution en termes de rapidité sera codée en FPGA, » indique Peter Lawrey, faisant référence au langage qui code directement les circuits logiques programmables. « S’il vous reste encore beaucoup de temps et de ressources, et que vous voulez créer de multiples adaptateurs d’échange, vous opterez pour C++. Mais si vous voulez aller au-delà de 20, accéder rapidement au marché et mettre en œuvre une optimisation continue des performances, vous choisirez Java. »
Le problème de C++ tient à sa faillibilité, précise Peter Lawrey. « Sauf à être un très bon développeur C++, vous risquez de vous tirer une balle dans le pied et de faire capoter un projet dans son intégralité. » A titre d’exemple, il cite le cas d’un système utilisé en banque d’investissement. Il était codé en C++ et aurait dû être rapide, mais au lieu de se focaliser sur ce point, l’équipe de développeurs de la banque a passé le plus clair de son temps à examiner les crash reports et essayer d’anticiper ce qui ne fonctionnait pas en C++. Pour cette raison, dit-il, les éléments du système tournant sous Java étaient beaucoup plus rapides. « Ils ajoutaient des métriques à Java pour voir comment le système en C++ réagirait. C’est l’une des pires âneries que j’ai vue dans ma carrière. »
Ce qui ne veut pas dire pour autant que tout le code Java est rapide. Le système de Chronicle est construit en ce Peter Lawrey décrit comme du « Java de type C » et c’est cette forme qu’il préconise pour coder les systèmes à faible latence.
« La façon dont nous codons est plus proche de C++ que de Java, » explique-t-il. En principe, nous utilisons une forme artificielle de Java qui évite toutes les constructions affectant la rapidité. Nous n’utilisons que les constructions rapides et efficaces, et nous évitons tous les objets inutiles. » Peter Lawrey explique qu’en simplifiant Java et en passant sur du code de très bas niveau, il est possible d’augmenter sensiblement la rapidité. Cela ne tient parfois qu’à une amélioration du diagnostic : « par un simple changement de la configuration du code, nous avons pu réduire la latence au 99,9è percentile selon un facteur de 25. »
Seul problème d’un Java à faible latence : les programmeurs Java les plus expérimentés ont du mal avec le nouveau paradigme. « Beaucoup de gens qui programment en Java ont l’habitude de travailler dans un environnement où la latence n’est pas déterminante, » poursuit Peter Lawrey. « Même avec 15 ou 20 ans d’expérience, ils ne comprennent pas le code de bas niveau, ni comment penser seulement en termes de critères essentiels à remplir. »
Chronicle accompagne les développeurs de ses clients sur cette forme de Java de bas niveau. Elle emploie aussi dix développeurs spécialistes de Java et cherchera à poursuivre son expansion à mesure du déploiement mondial de sa plateforme. Peter Lawrey concède que ce focus sur le Java de type C peut compliquer le recrutement. « Nous avons d’abord engagé des gens issus des salles de marché, mais les derniers arrivés sont plutôt des étudiants de master et doctorat », ajoute-t-il.
Toutefois, bon nombre de candidats qui postulent chez Chronicle ne sont pas faits pour ce type de job. « La plupart des développeurs sont en fait des développeurs web, habitués à modéliser des choses qu’ils peuvent visualiser, » poursuit Peter Lawrey. « Mais dans un système de trading, vous prenez en compte des latences invisibles, qui ne correspondent même pas aux latences habituelles – même une milliseconde peut avoir un impact. Le travail est très théorique et abstrait, et il est difficile d’avoir une intuition visuelle de ce qui se passe réellement. »
Have a confidential story, tip, or comment you’d like to share? Contact: sbutcher@efinancialcareers.com in the first instance. Whatsapp/Signal/Telegram also available. Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)
