Modèles C++ pour les applications à faible latence, y compris le trading à haute fréquence

 (arxiv.org)
1 points par GN⁺ 2024-07-09 | 1 commentaires | Partager sur WhatsApp

Modèles de conception pour les applications C++ à faible latence

  • Auteurs : Paul Bilokon, Burak Gunduz
  • Date de soumission : 8 septembre 2023
  • Sujet : optimisation du code à faible latence, avec un accent particulier sur les systèmes de trading à haute fréquence (HFT)

Contributions principales

  • Création d'un dépôt de programmation à faible latence : guide pratique incluant un benchmarking statistique rigoureux
  • Optimisation d'une stratégie d'arbitrage statistique market neutral : améliorations significatives en vitesse et en rentabilité
  • Implémentation en C++ du modèle Disruptor : meilleures performances que les méthodes de mise en file d'attente traditionnelles

Métriques d'évaluation

  • vitesse
  • utilisation du cache
  • significativité statistique, etc.

Technologies clés

  • Cache warming : réduction de la latence grâce à l'initialisation du cache
  • Constexpr : amélioration des performances grâce à l'évaluation des constantes à la compilation

Orientations futures

  • extension du dépôt
  • test des algorithmes de trading optimisés dans un environnement de trading en temps réel
  • intégration du modèle Disruptor et des algorithmes de trading pour un benchmarking système complet

Public visé

  • praticiens du monde académique et de l'industrie

Le résumé de GN⁺

Cet article traite de modèles de conception destinés à améliorer les performances des applications à faible latence, en particulier des systèmes de trading à haute fréquence. Le dépôt de programmation à faible latence et l'implémentation du modèle Disruptor constituent des guides utiles pour les praticiens. Des techniques comme le cache warming et constexpr contribuent fortement à réduire la latence. Cet article sera très utile à celles et ceux qui s'intéressent à l'optimisation des performances.

À lire aussi

1 commentaires

 
GN⁺ 2024-07-09
Commentaire Hacker News

  • Il s’agit d’une brève introduction au sujet

  • Les étudiants de premier cycle connaissent déjà les éléments de base de l’optimisation des performances

    • Ils apprennent les concepts fondamentaux comme la prédiction de branchement, la cohérence du cache et le cache d’instructions

  • Il est surprenant que la dégradation des performances due au false sharing ne soit pas abordée

  • Il est également surprenant que les attributs d’indication d’optimisation ([[likely]], [[unlikely]]) ne soient pas évoqués

  • Les aspects avancés de l’optimisation des performances ne sont pas traités

    • API d’E/S spécifiques, primitives de synchronisation, mécanismes d’IPC, fonctions intrinsèques du compilateur, etc.

  • Ce dont un programmeur bas niveau a besoin, c’est d’une vigilance constante face aux allocations, copies et autres opérations inutiles

    • Il faut prendre l’habitude d’identifier les sources de dégradation des performances à l’aide de benchmarks

  • En écrivant un serveur à faible latence, on se rend compte que les opérations d’E/S vectorielles sont plus lentes que la copie de petits objets dans un buffer contigu

    • Cela souligne qu’il n’existe pas de copie « gratuite »

  • Les résultats de test fournissent une statistique t et une valeur p

    • La statistique t représente le résultat du test de racine unitaire des résidus
    • La valeur p donne la probabilité que l’hypothèse nulle du test soit vraie

  • Cette partie semble avoir été rédigée à l’aide d’un LLM

  • L’exemple consistant à analyser cinq ans de cours de clôture quotidiens et à calculer un spread avec une latence de 65 microsecondes paraît étrange

    • Les statistiques ne sont pas calculées dans la boucle interne
    • 65 microsecondes, c’est trop lent pour une boucle interne
    • Cela ressemble à un exemple destiné à s’exercer aux techniques d’optimisation

  • Partage d’une implémentation de bourse écrite en C++

    • Elle utilise le pattern LMAX Disruptor
    • L’auteur prévoit de la réécrire en Rust
    • En Rust, la gestion mémoire et les dépendances sont plus simples

  • Écriture d’une bibliothèque de logging en C++

    • Semblable à LMAX Disruptor
    • Utilisée dans la communauté HFT
    • Elle permet un logging détaillé sans dégradation des performances
    • Elle résout le problème des collègues qui n’enregistrent pas des informations importantes par crainte d’un impact sur les performances

  • L’efficacité du dispatch à la compilation vient du fait que la décision d’appel de fonction est prise à l’étape de compilation

    • Si le compilateur peut déterminer statiquement quelle fonction sera appelée, il peut directement inliner le code de cette fonction
    • Cela supprime tout l’overhead des appels de fonction et permet des optimisations supplémentaires

  • Partage d’une présentation de la CppCon 2017

    • Sur le thème : quand les microsecondes semblent une éternité
    • Pour un développeur professionnel, il vaut la peine de regarder l’ensemble du contenu

  • Certains s’interrogent sur la raison d’être du trading à haute fréquence

    • On se plaint que le bitcoin gaspille de l’énergie, mais le trading à haute fréquence a un impact purement négatif sur la société