Développement Du Système Commercial C ++

Meilleur langage de programmation pour les systèmes de trading algorithmique Une des questions les plus fréquentes que je reçois dans le mailbag QS est quel est le meilleur langage de programmation pour le trading algorithmique. La réponse courte est qu'il n'y a pas de meilleure langue. Les paramètres de la stratégie, la performance, la modularité, le développement, la résilience et le coût doivent tous être pris en considération. Cet article décrira les composantes nécessaires d'une architecture de système de négociation algorithmique et comment les décisions concernant la mise en œuvre affectent le choix du langage. Tout d'abord, les principales composantes d'un système d'échange algorithmique seront considérées, comme les outils de recherche, l'optimiseur de portefeuille, le gestionnaire de risques et le moteur d'exécution. Par la suite, différentes stratégies de négociation seront examinées et leur incidence sur la conception du système. En particulier, la fréquence de négociation et le volume de négociation probable seront tous deux discutés. Une fois la stratégie de négociation sélectionnée, il est nécessaire d'architecturer l'ensemble du système. Cela inclut le choix du matériel, du (des) système (s) d'exploitation et de la résilience du système contre des événements rares et potentiellement catastrophiques. Bien que l'architecture soit envisagée, il faut tenir dûment compte de la performance - tant pour les outils de recherche que pour l'environnement d'exécution en direct. Qu'est-ce que le système de négociation essayant de faire Avant de décider sur la meilleure langue avec laquelle écrire un système automatisé de négociation, il est nécessaire de définir les exigences. Le système va-t-il être purement exécuté? Le système exigera-t-il un module de gestion des risques ou de construction de portefeuille? Le système exigera-t-il un backtestter performant? Pour la plupart des stratégies, le système commercial peut être divisé en deux catégories. La recherche porte sur l'évaluation de la performance d'une stratégie par rapport aux données historiques. Le processus d'évaluation d'une stratégie commerciale sur des données de marché antérieures est connu sous le nom de backtesting. La taille des données et la complexité algorithmique auront un impact important sur l'intensité de calcul du backtest. La vitesse et la simultanéité du processeur sont souvent les facteurs limitant l'optimisation de la vitesse d'exécution de la recherche. La génération de signaux concerne la génération d'un ensemble de signaux commerciaux à partir d'un algorithme et l'envoi de tels ordres au marché, généralement via un courtage. Pour certaines stratégies, un niveau de performance élevé est nécessaire. Les problèmes d'E / S tels que la bande passante du réseau et la latence sont souvent le facteur limitant dans l'optimisation des systèmes d'exécution. Ainsi, le choix des langues pour chaque composant de votre système entier peut être très différent. Type, fréquence et volume de la stratégie Le type de stratégie algorithmique utilisée aura un impact important sur la conception du système. Il faudra tenir compte des marchés négociés, de la connectivité avec les fournisseurs de données externes, de la fréquence et du volume de la stratégie, du compromis entre la facilité de développement et l'optimisation des performances, ainsi que tout matériel personnalisé, Serveurs, GPU ou FPGAs qui pourraient être nécessaires. Les choix technologiques pour une stratégie d'actions américaines à faible fréquence seront très différents de ceux d'une stratégie d'arbitrage statistique à haute fréquence négociée sur le marché à terme. Avant le choix de la langue de nombreux fournisseurs de données doivent être évalués qui se rapportent à une stratégie à portée de main. Il faudra tenir compte de la connectivité avec le fournisseur, de la structure de toutes les API, de l'actualité des données, des exigences de stockage et de la résilience face à un fournisseur qui se met hors connexion. Il est également sage de posséder un accès rapide à de multiples fournisseurs. Divers instruments ont tous leurs propres caprices de stockage, dont des exemples incluent des symboles multiples pour les actions et des dates d'expiration pour les futures (sans parler des données OTC spécifiques). Cela doit être pris en compte dans la conception de la plate-forme. La fréquence de la stratégie est probablement l'un des principaux moteurs de la définition de la pile technologique. Les stratégies employant des données plus fréquemment que des barres minutieuses ou secondaires exigent une considération importante en ce qui concerne la performance. Une stratégie dépassant deuxièmement les barres (c'est-à-dire les données de tique) conduit à une conception entraînée par la performance comme principale exigence. Pour les stratégies à haute fréquence, une quantité importante de données de marché devra être stockée et évaluée. Des logiciels tels que HDF5 ou kdb sont couramment utilisés pour ces rôles. Afin de traiter les volumes importants de données nécessaires pour les applications HFT, un backtester et un système d'exécution largement optimisés doivent être utilisés. CC (éventuellement avec quelques assembler) est susceptible de la langue la plus forte candidat. Les stratégies à très haute fréquence nécessiteront presque certainement des matériels personnalisés tels que les FPGA, l'échange de co-implantation et l'optimisation de l'interface kernalnetwork. Systèmes de recherche Les systèmes de recherche comportent généralement un mélange de développement interactif et de scripts automatisés. Le premier a souvent lieu dans un IDE tel que Visual Studio, MatLab ou R Studio. Cette dernière implique de nombreux calculs numériques sur de nombreux paramètres et points de données. Cela conduit à un choix de langue fournissant un environnement simple pour tester le code, mais fournit également des performances suffisantes pour évaluer des stratégies sur plusieurs dimensions de paramètre. Les IDE typiques dans cet espace incluent Microsoft Visual CC, qui contient des utilités de débogage étendues, des capacités de complétion de code (via Intellisense) et des aperçus simples de toute la pile de projet (via la base de données ORM, LINQ) MatLab. Qui est conçu pour l'algèbre linéaire numérique étendue et les opérations vectorisées, mais dans une console interactive R Studio. Qui enveloppe la console de langage statistique R dans un IDE IDE Eclipse complet pour Linux Java et C et des IDE semi-propriétaires tels que Enthought Canopy pour Python, qui comprennent des bibliothèques d'analyse de données telles que NumPy. SciPy. Scikit-learn et pandas dans un seul environnement interactif (console). Pour le backtesting numérique, toutes les langues ci-dessus sont appropriées, bien qu'il ne soit pas nécessaire d'utiliser une GUIIDE car le code sera exécuté en arrière-plan. La principale considération à ce stade est celle de la vitesse d'exécution. Un langage compilé (tel que C) est souvent utile si les dimensions du paramètre backtesting sont importantes. N'oubliez pas qu'il est nécessaire de se méfier de tels systèmes, si c'est le cas. Les langages interprétés tels que Python utilisent souvent des bibliothèques performantes telles que NumPypandas pour l'étape de backtesting, afin de maintenir un degré raisonnable de compétitivité avec des équivalents compilés. En fin de compte, la langue choisie pour le backtesting sera déterminée par des besoins algorithmiques spécifiques ainsi que la gamme de bibliothèques disponibles dans la langue (plus sur cela ci-dessous). Cependant, la langue utilisée pour les environnements de backtest et de recherche peut être complètement indépendante de celles utilisées dans la construction du portefeuille, la gestion des risques et les composantes d'exécution, comme on le verra. Construction du portefeuille et gestion des risques Les composantes de la construction du portefeuille et de la gestion des risques sont souvent négligées par les négociants algorithmiques de détail. C'est presque toujours une erreur. Ces outils fournissent le mécanisme par lequel le capital sera préservé. Ils tentent non seulement d'atténuer le nombre de paris risqués, mais aussi de minimiser le désabonnement des métiers eux-mêmes, ce qui réduit les coûts de transaction. Des versions sophistiquées de ces composants peuvent avoir un effet significatif sur la qualité et la cohérence de la rentabilité. Il est facile de créer des stratégies stables car le mécanisme de construction du portefeuille et le gestionnaire des risques peuvent facilement être modifiés pour gérer plusieurs systèmes. Ils doivent donc être considérés comme des composantes essentielles dès le début de la conception d'un système de négociation algorithmique. Le travail du système de construction de portefeuille est de prendre un ensemble de métiers souhaités et de produire l'ensemble des métiers réels qui minimisent le désabonnement, de maintenir l'exposition à divers facteurs (tels que les secteurs, les classes d'actifs, la volatilité, etc) et d'optimiser l'allocation de capital à divers Stratégies dans un portefeuille. La construction du portefeuille se réduit souvent à un problème d'algèbre linéaire (comme une factorisation matricielle) et donc la performance dépend fortement de l'efficacité de l'implantation de l'algèbre linéaire numérique disponible. Les bibliothèques communes comprennent uBLAS. LAPACK et NAG pour C. MatLab possède également des opérations matricielles largement optimisées. Python utilise NumPySciPy pour de tels calculs. Un portefeuille fréquemment rééquilibré nécessitera une bibliothèque matricielle compilée (et bien optimisée) pour réaliser cette étape, afin de ne pas gouler le système commercial. La gestion des risques est une autre partie extrêmement importante d'un système de négociation algorithmique. Le risque peut provenir de plusieurs façons: une volatilité accrue (bien que cela puisse être jugé souhaitable pour certaines stratégies), des corrélations accrues entre les classes d'actifs, le défaut de contrepartie, les interruptions de serveurs, les événements de cygne noir et les bugs non détectés dans le code de négociation peu. Les composantes de la gestion des risques essaient d'anticiper les effets d'une volatilité excessive et de la corrélation entre les catégories d'actifs et leurs effets ultérieurs sur le capital commercial. Souvent, cela se réduit à un ensemble de calculs statistiques tels que les tests de stress Monte Carlo. Ceci est très similaire aux besoins de calcul d'un moteur de détermination des dérivés et, en tant que tel, sera lié au processeur. Ces simulations sont hautement parallèles (voir ci-dessous) et, dans une certaine mesure, il est possible de jeter le matériel au problème. Systèmes d'exécution Le travail du système d'exécution est de recevoir des signaux commerciaux filtrés des composants de construction de portefeuille et de gestion des risques et les envoyer à une maison de courtage ou à d'autres moyens d'accès au marché. Pour la majorité des stratégies de trading algorithmique de détail, cela implique une connexion API ou FIX à un courtage comme Interactive Brokers. Les principales considérations lors de la prise de décision sur un langage comprennent la qualité de l'API, la disponibilité de l'enveloppe de langage pour une API, la fréquence d'exécution et le glissement attendu. La qualité de l'API se réfère à la façon dont elle est bien documentée, quel type de performance qu'elle fournit, si elle a besoin d'un logiciel autonome d'être consulté ou si une passerelle peut être établie de façon décontractée (c'est-à-dire pas d'interface graphique). Dans le cas des Interactive Brokers, l'outil Trader WorkStation doit fonctionner dans un environnement graphique afin d'accéder à leur API. J'ai dû installer une édition Desktop Ubuntu sur un serveur Amazon Cloud afin d'accéder à Interactive Brokers à distance, uniquement pour cette raison. La plupart des API fourniront une interface C ou Java. Il appartient habituellement à la communauté de développer des enveloppes spécifiques au langage pour C, Python, R, Excel et MatLab. Notez qu'avec chaque plugin supplémentaire utilisé (en particulier les wrappers API), il est possible que des bugs pénètrent dans le système. Testez toujours les plugins de ce type et assurez-vous qu'ils sont activement maintenus. Un indicateur utile est de voir combien de nouvelles mises à jour d'un codebase ont été effectuées au cours des derniers mois. La fréquence d'exécution est de la plus haute importance dans l'algorithme d'exécution. Notez que des centaines de commandes peuvent être envoyées à chaque minute et que cette performance est critique. Des dérapages seront occasionnés par un système d'exécution mal exécuté et cela aura un impact dramatique sur la rentabilité. Les langages statiquement typés (voir ci-dessous) tels que CJava sont généralement optimales pour l'exécution mais il ya un compromis dans le temps de développement, les tests et la facilité d'entretien. Les langages à typage dynamique, tels que Python et Perl, sont maintenant généralement assez rapides. Assurez-vous toujours que les composants sont conçus de manière modulaire (voir ci-dessous) afin qu'ils puissent être échangés à mesure que le système se balance. Processus de planification et de développement architecturale Les composantes d'un système commercial, ses exigences en matière de fréquence et de volume ont été examinées ci-dessus, mais l'infrastructure du système n'a pas encore été traitée. Ceux qui agissent comme un commerçant au détail ou travaillent dans un petit fonds sera probablement porter beaucoup de chapeaux. Il sera nécessaire de couvrir le modèle alpha, la gestion des risques et les paramètres d'exécution, ainsi que la mise en œuvre finale du système. Avant de s'intéresser à des langages spécifiques, la conception d'une architecture de système optimale sera discutée. Séparation des préoccupations Une des décisions les plus importantes qui doivent être prises au départ est de savoir comment séparer les préoccupations d'un système commercial. Dans le développement de logiciels, cela signifie essentiellement comment briser les différents aspects du système commercial en composants modulaires séparés. En exposant des interfaces à chacun des composants, il est facile d'échanger des parties du système pour d'autres versions qui aident à la performance, la fiabilité ou la maintenance, sans modifier aucun code de dépendance externe. C'est la meilleure pratique pour de tels systèmes. Pour les stratégies à basse fréquence, ces pratiques sont conseillées. Pour la négociation ultra haute fréquence, le règlement peut être ignoré au détriment de la modification du système pour obtenir encore plus de performances. Un système plus serré peut être souhaitable. La création d'une carte de composants d'un système de négociation algorithmique vaut un article en soi. Cependant, une approche optimale consiste à s'assurer qu'il existe des composants distincts pour les entrées de données historiques et en temps réel, le stockage de données, l'API d'accès aux données, le backtest, les paramètres de stratégie, la construction de portefeuille, la gestion des risques et les systèmes d'exécution automatisés. Par exemple, si le magasin de données en cours d'exécution est actuellement sous-performant, même à des niveaux significatifs d'optimisation, il peut être échangé avec des réécritures minimales à l'ingestion de données ou l'API d'accès aux données. En ce qui concerne le backtest et les composantes suivantes, il n'y a pas de différence. Un autre avantage des composants séparés est qu'il permet une variété de langages de programmation à utiliser dans le système global. Il n'est pas nécessaire de se limiter à une seule langue si la méthode de communication des composants est indépendante du langage. Ce sera le cas si elles communiquent via TCPIP, ZeroMQ ou un autre protocole indépendant de la langue. A titre d'exemple concret, considérons le cas d'un système de backtesting écrit en C pour la performance de crunching de numéros, tandis que le gestionnaire de portefeuille et les systèmes d'exécution sont écrits en Python en utilisant SciPy et IBPy. Considérations relatives au rendement Le rendement est une considération importante pour la plupart des stratégies de négociation. Pour les stratégies de fréquence plus élevée, c'est le facteur le plus important. La performance couvre un large éventail de problèmes, tels que la vitesse d'exécution algorithmique, la latence du réseau, la bande passante, les E / S de données, le parallélisme concurrentiel et la mise à l'échelle. Chacun de ces domaines sont couverts individuellement par de grands manuels, de sorte que cet article ne fera que gratter la surface de chaque sujet. L'architecture et le choix de la langue seront maintenant discutés en fonction de leurs effets sur la performance. La sagesse qui prévaut comme indiqué par Donald Knuth. L'un des pères de l'informatique, est que l'optimisation prématurée est la racine de tout mal. Pour ceux qui s'intéressent aux stratégies de fréquence inférieure, une approche commune consiste à construire un système de la manière la plus simple possible et à n'optimiser que lorsque des goulots d'étranglement commencent à apparaître. Les outils de profilage sont utilisés pour déterminer les goulots d'étranglement. Des profils peuvent être établis pour tous les facteurs énumérés ci-dessus, soit dans un environnement MS Windows ou Linux. Il existe de nombreux outils de système d'exploitation et de langue disponibles pour le faire, ainsi que des utilitaires tiers. Le choix de la langue sera maintenant discuté dans le contexte de la performance. C, Java, Python, R et MatLab contiennent tous des bibliothèques de haute performance (soit en standard ou externe) pour la structure de données de base et le travail algorithmique. C est livré avec la bibliothèque de modèles standard, tandis que Python contient NumPySciPy. Des tâches mathématiques courantes se trouvent dans ces bibliothèques et il est rarement bénéfique d'écrire une nouvelle implémentation. Une exception est si une architecture matérielle hautement personnalisée est requise et qu'un algorithme utilise largement des extensions propriétaires (telles que des caches personnalisés). Cependant, souvent la réinvention de la roue gaspille le temps qui pourrait être mieux dépensé développer et optimiser d'autres parties de l'infrastructure commerciale. Le temps de développement est extrêmement précieux, surtout dans le contexte des développeurs exclusifs. La latence est souvent une question du système d'exécution car les outils de recherche sont habituellement situés sur la même machine. Pour le premier, la latence peut se produire à plusieurs points le long du chemin d'exécution. Les bases de données doivent être consultées (latence disknetwork), les signaux doivent être générés (système d'exploitation, kernal messaging latency), les signaux commerciaux envoyés (latence NIC) et les commandes traitées (latence interne des systèmes d'échange). Pour les opérations à fréquence plus élevée, il est nécessaire de se familiariser avec l'optimisation kernale et l'optimisation de la transmission réseau. Il s'agit d'une zone profonde et est largement au-delà de la portée de l'article, mais si un algorithme UHFT est souhaité alors être conscient de la profondeur des connaissances requises Caching est très utile dans la trousse d'un développeur de négociation quantitative. La mise en cache fait référence au concept de stockage des données fréquemment consultées de manière à permettre un accès plus performant, au détriment de l'indisponibilité potentielle des données. Un cas d'utilisation courante se produit dans le développement web lors de la prise de données à partir d'une base de données relationnelle supportée par disque et de mise en mémoire. Toute demande ultérieure de données ne doit pas frapper la base de données et donc les gains de performance peuvent être importants. Pour les situations de trading cache peut être extrêmement bénéfique. Par exemple, l'état actuel d'un portefeuille de stratégies peut être stocké dans un cache jusqu'à ce qu'il soit rééquilibré, de sorte que la liste n'a pas besoin d'être régénérée sur chaque boucle de l'algorithme de négociation. Une telle régénération est susceptible d'être une opération de CPU ou d'E / S de disque élevée. Toutefois, la mise en cache n'est pas sans ses propres problèmes. La régénération des données de cache à la fois, en raison de la volatilité du stockage en cache, peut poser une demande importante sur l'infrastructure. Un autre problème est l'accumulation de chiens. Où plusieurs générations d'une nouvelle copie de cache sont exécutées sous une charge extrêmement élevée, ce qui entraîne une défaillance en cascade. L'allocation de mémoire dynamique est une opération coûteuse dans l'exécution du logiciel. Il est donc impératif que les applications de négociation de performance supérieure soient bien conscientes de la façon dont la mémoire est allouée et désaffectée pendant le flux du programme. Les normes linguistiques plus récentes, telles que Java, C et Python, permettent toutes une collecte automatique des ordures. Qui se réfère à la désallocation de mémoire allouée dynamiquement lorsque les objets sortent de la portée. La collecte des ordures est extrêmement utile pendant le développement car elle réduit les erreurs et facilite la lisibilité. Cependant, elle est souvent sous-optimale pour certaines stratégies de négociation à haute fréquence. La collecte des ordures personnalisée est souvent souhaitée pour ces cas. En Java, par exemple, en réglant la configuration du collecteur d'ordures et du tas, il est possible d'obtenir des performances élevées pour les stratégies HFT. C ne fournit pas un récupérateur de morceaux natif et il est donc nécessaire de traiter tous attribution allocationde mémoire dans le cadre d'une implémentation d'objets. Bien que potentiellement propice aux erreurs (potentiellement menant à des pointeurs pendants), il est extrêmement utile d'avoir un contrôle précis de la façon dont les objets apparaissent sur le tas pour certaines applications. Lors du choix d'une langue, assurez-vous d'étudier comment fonctionne le collecteur d'ordures et si elle peut être modifiée pour optimiser pour un cas d'utilisation particulier. De nombreuses opérations dans les systèmes de négociation algorithmique sont susceptibles de parallélisation. Il s'agit du concept de réalisation simultanée de plusieurs opérations de programmation, c'est-à-dire en parallèle. Les algorithmes dits embarassement parallèles incluent des étapes qui peuvent être calculées en toute indépendance d'autres étapes. Certaines opérations statistiques, telles que les simulations de Monte Carlo, sont un bon exemple d'algorithmes embarassement parallèles car chaque tracé aléatoire et opération de chemin ultérieur peuvent être calculés sans connaissance d'autres chemins. D'autres algorithmes ne sont que partiellement parallèles. Les simulations de dynamique de fluide sont un tel exemple, où le domaine de calcul peut être subdivisé, mais finalement ces domaines doivent communiquer entre eux et donc les opérations sont partiellement séquentielles. Les algorithmes parallélisables sont soumis à la loi Amdahls. Qui fournit une limite supérieure théorique à l'augmentation de la performance d'un algorithme parallélisé lorsqu'il est soumis à N processus séparés (par exemple sur un noyau d'unité centrale ou un thread). La parallélisation est devenue de plus en plus importante en tant qu'outil d'optimisation puisque les vitesses d'horloge du processeur ont stagné, car les processeurs plus récents contiennent de nombreux noyaux avec lesquels effectuer des calculs parallèles. La montée du matériel graphique grand public (principalement pour les jeux vidéo) a conduit au développement d'unités de traitement graphique (GPU), qui contiennent des centaines de cœurs pour des opérations très concurrentes. Ces GPU sont maintenant très abordables. Des cadres de haut niveau, comme Nvidias CUDA, ont conduit à une adoption généralisée dans les milieux universitaires et financiers. De tels matériels GPU ne sont généralement adaptés qu'à l'aspect de recherche de la finance quantitative, tandis que d'autres matériels plus spécialisés (y compris les tableaux de portes programmables sur site - FPGA) sont utilisés pour (U) HFT. De nos jours, la plupart des langages modernes prennent en charge un degré de simultanéité. Il est donc facile d'optimiser un backtester, puisque tous les calculs sont généralement indépendants des autres. La mise à l'échelle dans l'ingénierie logicielle et les opérations se réfère à la capacité du système à gérer de façon constante des charges croissantes sous la forme de demandes plus importantes, d'une utilisation accrue du processeur et d'une plus grande allocation de mémoire. Dans le trading algorithmique, une stratégie est capable d'évoluer si elle peut accepter de plus grandes quantités de capital et produire encore des rendements cohérents. La technologie de négociation empile si elle peut supporter des volumes commerciaux plus importants et une latence accrue, sans goulot d'étranglement. Alors que les systèmes doivent être conçus à l'échelle, il est souvent difficile de prévoir au préalable où un goulot d'étranglement va se produire. L'exploitation forestière, les essais, le profilage et la surveillance rigoureux aideront grandement à permettre l'étalement d'un système. Les langues elles-mêmes sont souvent décrites comme ne pouvant pas être évaluées. C'est généralement le résultat de la désinformation, plutôt que des faits durs. C'est la pile de technologie totale qui doit être déterminée pour l'évolutivité, pas la langue. Il est clair que certaines langues ont des performances supérieures à celles d'autres cas d'utilisation particuliers, mais une langue n'est jamais meilleure qu'une autre dans tous les sens. Un moyen de gérer l'échelle est de séparer les préoccupations, comme indiqué ci-dessus. Afin d'introduire davantage la capacité de manipuler des pointes dans le système (c'est-à-dire une volatilité soudaine qui déclenche un train de métiers), il est utile de créer une architecture de mise en file d'attente de messages. Cela signifie simplement placer un système de file d'attente de messages entre les composants afin que les commandes soient empilées si un certain composant est incapable de traiter de nombreuses requêtes. Plutôt que les demandes qui sont perdues, elles sont simplement conservées dans une pile jusqu'à ce que le message soit traité. Cela est particulièrement utile pour envoyer des transactions vers un moteur d'exécution. Si le moteur souffre de lourde latence, il sera de sauvegarder les métiers. Une file d'attente entre le générateur de signaux commerciaux et l'API d'exécution permettra d'atténuer ce problème aux dépens d'un éventuel glissement commercial. RabbitMQ est un courtier de files d'attente open source bien respecté. Matériel et systèmes d'exploitation Le matériel exécutant votre stratégie peut avoir un impact significatif sur la rentabilité de votre algorithme. Ce n'est pas un problème restreint aux commerçants de haute fréquence non plus. Un mauvais choix dans le matériel et le système d'exploitation peut conduire à un accident de la machine ou de redémarrer au moment le plus inopportun. Il est donc nécessaire de déterminer l'endroit où réside votre demande. Le choix se fait généralement entre une machine de bureau personnelle, un serveur distant, un fournisseur de nuages ​​ou un serveur d'échange co-localisé. Les machines de bureau sont simples à installer et à administrer, en particulier avec des systèmes d'exploitation conviviaux plus récents tels que Windows 78, Mac OSX et Ubuntu. Toutefois, les systèmes de bureau présentent certains inconvénients importants. Le premier est que les versions des systèmes d'exploitation conçus pour les ordinateurs de bureau sont susceptibles d'exiger rebootspatching (et souvent au pire des temps). Ils utilisent également plus de ressources informatiques en vertu de l'exigence d'une interface utilisateur graphique (GUI). L'utilisation du matériel dans un environnement domestique (ou local) peut entraîner des problèmes de connectivité Internet et de disponibilité de l'alimentation. Le principal avantage d'un système de bureau est que des puissances calculatrices significatives peuvent être achetées pour la fraction du coût d'un serveur dédié dédié (ou système basé sur le nuage) de vitesse comparable. Un serveur dédié ou une machine basée sur le cloud, bien que souvent plus coûteuse qu'une option de bureau, permet une infrastructure de redondance plus importante, comme des sauvegardes de données automatisées, la possibilité d'assurer plus facilement la disponibilité et la surveillance à distance. Ils sont plus difficiles à administrer car ils nécessitent la possibilité d'utiliser les capacités de connexion à distance du système d'exploitation. Dans Windows, c'est généralement via le GUI Remote Desktop Protocol (RDP). Dans les systèmes Unix, la ligne de commande Secure SHell (SSH) est utilisée. L'infrastructure de serveur basée sur Unix est presque toujours basée sur la ligne de commande qui rend immédiatement inutilisables les outils de programmation basés sur GUI (tels que MatLab ou Excel). Un serveur co-situé, comme l'expression est utilisée dans les marchés des capitaux, est tout simplement un serveur dédié qui réside dans un échange afin de réduire la latence de l'algorithme de négociation. Cela est absolument nécessaire pour certaines stratégies de négociation haute fréquence, qui reposent sur une faible latence afin de générer alpha. Le dernier aspect du choix de matériel et le choix du langage de programmation est l'indépendance de la plate-forme. Le code doit-il être exécuté sur plusieurs systèmes d'exploitation différents? Le code est-il conçu pour être exécuté sur un type particulier d'architecture de processeur, comme Intel x86x64 ou sera-t-il possible d'exécuter sur des processeurs RISC tels que ceux fabriqués par ARM Ces questions dépendront fortement de la fréquence et du type de stratégie mise en œuvre. Résilience et de test Une des meilleures façons de perdre beaucoup d'argent sur le trading algorithmique est de créer un système sans résilience. Il s'agit de la durabilité du système lorsqu'il est sujet à des événements rares, tels que les faillites de courtage, la volatilité excessive soudaine, le temps d'arrêt à l'échelle de la région pour un fournisseur de serveur en nuage ou la suppression accidentelle d'une base de données de négociation complète. Années de profits peuvent être éliminés en quelques secondes avec une architecture mal conçue. Il est absolument essentiel d'envisager des problèmes tels que le débogage, les tests, l'enregistrement, les sauvegardes, la haute disponibilité et la surveillance en tant que composants de base de votre système. Il est probable que, dans toute application commerciale quantitativement personnalisée raisonnablement complexe, au moins 50 de temps de développement seront consacrés au débogage, au test et à la maintenance. Presque tous les langages de programmation sont livrés avec un débogueur associé ou possèdent des solutions tierces bien respectées. Essentiellement, un débogueur permet l'exécution d'un programme avec l'insertion de points de rupture arbitraires dans le chemin de code, qui arrêtent temporairement l'exécution afin d'étudier l'état du système. Le principal avantage du débogage est qu'il est possible d'étudier le comportement du code avant un point de collision connu. Le débogage est un composant essentiel de la boîte à outils pour analyser les erreurs de programmation. Cependant, ils sont plus largement utilisés dans les langages compilés tels que C ou Java, comme les langues interprétées comme Python sont souvent plus faciles à déboguer en raison de moins de LOC et moins d'énoncés détaillés. Malgré cette tendance, Python est livré avec le pdb. Qui est un outil de débogage sophistiqué. Le Microsoft Visual C IDE possède de vastes utilitaires de débogage GUI, tandis que pour le programmeur linux C de ligne de commande, le débogueur gdb existe. Les tests en développement logiciel se réfèrent au processus d'application de paramètres et de résultats connus à des fonctions, des méthodes et des objets spécifiques dans un codebase, afin de simuler le comportement et d'évaluer plusieurs chemins de code, ce qui permet de s'assurer que le système se comporte comme il se doit. Un paradigme plus récent est connu sous le nom Test Driven Development (TDD), où le code de test est développé contre une interface spécifiée sans implémentation. Avant l'achèvement de la base de code réelle, tous les tests échoueront. Comme le code est écrit pour remplir les blancs, les tests finiront par tous passer, au point où le développement devrait cesser. TDD nécessite une vaste conception de spécifications initiales ainsi que d'un degré sain de discipline afin de mener à bien avec succès. En C, Boost fournit un cadre de test unitaire. En Java, la bibliothèque JUnit existe pour atteindre le même objectif. Python possède également le module unittest dans le cadre de la bibliothèque standard. Beaucoup d'autres langues possèdent des cadres de test d'unité et souvent il ya plusieurs options. Dans un environnement de production, une exploitation forestière sophistiquée est absolument essentielle. Logging désigne le processus de sortie de messages, avec divers degrés de gravité, concernant le comportement d'exécution d'un système vers un fichier plat ou une base de données. Les journaux sont une première ligne d'attaque lors de la recherche d'un comportement d'exécution de programme inattendu. Malheureusement, les lacunes d'un système d'exploitation forestière ont tendance à être découvertes après coup. Comme pour les sauvegardes décrites ci-dessous, un système d'exploitation forestière devrait être dûment pris en compte AVANT qu'un système soit conçu. Microsoft Windows et Linux possèdent une capacité de journalisation système étendue et les langages de programmation ont tendance à être livrés avec des bibliothèques de journalisation standard couvrant la plupart des cas d'utilisation. Il est souvent judicieux de centraliser les informations de journalisation afin de les analyser ultérieurement, car cela peut souvent conduire à des idées sur l'amélioration des performances ou la réduction des erreurs, ce qui aura certainement un impact positif sur vos rendements. Alors que l'enregistrement d'un système fournira des informations sur ce qui a transpiré dans le passé, le suivi d'une application permettra de comprendre ce qui se passe en ce moment. Tous les aspects du système devraient être pris en compte pour le suivi. Des statistiques de niveau système telles que l'utilisation du disque, la mémoire disponible, la bande passante du réseau et l'utilisation du processeur fournissent des informations de chargement de base. Les mesures de négociation telles que le volume de prix anormal, les prélèvements brusques rapides et l'exposition du compte pour différents secteurs devraient également être surveillées en permanence. En outre, un système de seuil doit être instigé qui fournit une notification lorsque certaines métriques sont violées, en élevant la méthode de notification (e-mail, SMS, appel téléphonique automatisé) en fonction de la gravité de la métrique. La surveillance du système est souvent le domaine de l'administrateur système ou du gestionnaire d'opérations. Toutefois, en tant que développeur commercial unique, ces mesures doivent être établies dans le cadre de la conception plus large. Il existe de nombreuses solutions de surveillance: propriétaire, hébergé et open source, qui permettent une personnalisation étendue des paramètres pour un cas d'utilisation particulier. Les sauvegardes et la haute disponibilité devraient être les principales préoccupations d'un système commercial. Consider the following two questions: 1) If an entire production database of market data and trading history was deleted (without backups) how would the research and execution algorithm be affected 2) If the trading system suffers an outage for an extended period (with open positions) how would account equity and ongoing profitability be affected The answers to both of these questions are often sobering It is imperative to put in place a system for backing up data and also for testing the restoration of such data. Many individuals do not test a restore strategy. If recovery from a crash has not been tested in a safe environment, what guarantees exist that restoration will be available at the worst possible moment Similarly, high availability needs to be baked in from the start. Redundant infrastructure (even at additional expense) must always be considered, as the cost of downtime is likely to far outweigh the ongoing maintenance cost of such systems. I wont delve too deeply into this topic as it is a large area, but make sure it is one of the first considerations given to your trading system. Choosing a Language Considerable detail has now been provided on the various factors that arise when developing a custom high-performance algorithmic trading system. The next stage is to discuss how programming languages are generally categorised. Type Systems When choosing a language for a trading stack it is necessary to consider the type system . The languages which are of interest for algorithmic trading are either statically - or dynamically-typed . A statically-typed language performs checks of the types (e. g. integers, floats, custom classes etc) during the compilation process. Such languages include C and Java. A dynamically-typed language performs the majority of its type-checking at runtime. Such languages include Python, Perl and JavaScript. For a highly numerical system such as an algorithmic trading engine, type-checking at compile time can be extremely beneficial, as it can eliminate many bugs that would otherwise lead to numerical errors. However, type-checking doesnt catch everything, and this is where exception handling comes in due to the necessity of having to handle unexpected operations. Dynamic languages (i. e. those that are dynamically-typed) can often lead to run-time errors that would otherwise be caught with a compilation-time type-check. For this reason, the concept of TDD (see above) and unit testing arose which, when carried out correctly, often provides more safety than compile-time checking alone. Another benefit of statically-typed languages is that the compiler is able to make many optimisations that are otherwise unavailable to the dynamically - typed language, simply because the type (and thus memory requirements) are known at compile-time. In fact, part of the inefficiency of many dynamically-typed languages stems from the fact that certain objects must be type-inspected at run-time and this carries a performance hit. Libraries for dynamic languages, such as NumPySciPy alleviate this issue due to enforcing a type within arrays. Open Source or Proprietary One of the biggest choices available to an algorithmic trading developer is whether to use proprietary (commercial) or open source technologies. There are advantages and disadvantages to both approaches. It is necessary to consider how well a language is supported, the activity of the community surrounding a language, ease of installation and maintenance, quality of the documentation and any licensingmaintenance costs. The Microsoft. NET stack (including Visual C, Visual C) and MathWorks MatLab are two of the larger proprietary choices for developing custom algorithmic trading software. Both tools have had significant battle testing in the financial space, with the former making up the predominant software stack for investment banking trading infrastructure and the latter being heavily used for quantitative trading research within investment funds. Microsoft and MathWorks both provide extensive high quality documentation for their products. Further, the communities surrounding each tool are very large with active web forums for both. The. NET software allows cohesive integration with multiple languages such as C, C and VB, as well as easy linkage to other Microsoft products such as the SQL Server database via LINQ. MatLab also has many pluginslibraries (some free, some commercial) for nearly any quantitative research domain. There are also drawbacks. With either piece of software the costs are not insignificant for a lone trader (although Microsoft does provide entry-level version of Visual Studio for free). Microsoft tools play well with each other, but integrate less well with external code. Visual Studio must also be executed on Microsoft Windows, which is arguably far less performant than an equivalent Linux server which is optimally tuned. MatLab also lacks a few key plugins such as a good wrapper around the Interactive Brokers API, one of the few brokers amenable to high-performance algorithmic trading. The main issue with proprietary products is the lack of availability of the source code. This means that if ultra performance is truly required, both of these tools will be far less attractive. Open source tools have been industry grade for sometime. Much of the alternative asset space makes extensive use of open-source Linux, MySQLPostgreSQL, Python, R, C and Java in high-performance production roles. However, they are far from restricted to this domain. Python and R, in particular, contain a wealth of extensive numerical libraries for performing nearly any type of data analysis imaginable, often at execution speeds comparable to compiled languages, with certain caveats. The main benefit of using interpreted languages is the speed of development time. Python and R require far fewer lines of code (LOC) to achieve similar functionality, principally due to the extensive libraries. Further, they often allow interactive console based development, rapidly reducing the iterative development process. Given that time as a developer is extremely valuable, and execution speed often less so (unless in the HFT space), it is worth giving extensive consideration to an open source technology stack. Python and R possess significant development communities and are extremely well supported, due to their popularity. Documentation is excellent and bugs (at least for core libraries) remain scarce. Open source tools often suffer from a lack of a dedicated commercial support contract and run optimally on systems with less-forgiving user interfaces. A typical Linux server (such as Ubuntu) will often be fully command-line oriented. In addition, Python and R can be slow for certain execution tasks. There are mechanisms for integrating with C in order to improve execution speeds, but it requires some experience in multi-language programming. While proprietary software is not immune from dependencyversioning issues it is far less common to have to deal with incorrect library versions in such environments. Open source operating systems such as Linux can be trickier to administer. I will venture my personal opinion here and state that I build all of my trading tools with open source technologies. In particular I use: Ubuntu, MySQL, Python, C and R. The maturity, community size, ability to dig deep if problems occur and lower total cost ownership (TCO) far outweigh the simplicity of proprietary GUIs and easier installations. Having said that, Microsoft Visual Studio (especially for C) is a fantastic Integrated Development Environment (IDE) which I would also highly recommend. Batteries Included The header of this section refers to the out of the box capabilities of the language - what libraries does it contain and how good are they This is where mature languages have an advantage over newer variants. C, Java and Python all now possess extensive libraries for network programming, HTTP, operating system interaction, GUIs, regular expressions (regex), iteration and basic algorithms. C is famed for its Standard Template Library (STL) which contains a wealth of high performance data structures and algorithms for free. Python is known for being able to communicate with nearly any other type of systemprotocol (especially the web), mostly through its own standard library. R has a wealth of statistical and econometric tools built in, while MatLab is extremely optimised for any numerical linear algebra code (which can be found in portfolio optimisation and derivatives pricing, for instance). Outside of the standard libraries, C makes use of the Boost library, which fills in the missing parts of the standard library. In fact, many parts of Boost made it into the TR1 standard and subsequently are available in the C11 spec, including native support for lambda expressions and concurrency. Python has the high performance NumPySciPyPandas data analysis library combination, which has gained widespread acceptance for algorithmic trading research. Further, high-performance plugins exist for access to the main relational databases, such as MySQL (MySQLC), JDBC (JavaMatLab), MySQLdb (MySQLPython) and psychopg2 (PostgreSQLPython). Python can even communicate with R via the RPy plugin An often overlooked aspect of a trading system while in the initial research and design stage is the connectivity to a broker API. Most APIs natively support C and Java, but some also support C and Python, either directly or with community-provided wrapper code to the C APIs. In particular, Interactive Brokers can be connected to via the IBPy plugin. If high-performance is required, brokerages will support the FIX protocol . Conclusion As is now evident, the choice of programming language(s) for an algorithmic trading system is not straightforward and requires deep thought. The main considerations are performance, ease of development, resiliency and testing, separation of concerns, familiarity, maintenance, source code availability, licensing costs and maturity of libraries. The benefit of a separated architecture is that it allows languages to be plugged in for different aspects of a trading stack, as and when requirements change. A trading system is an evolving tool and it is likely that any language choices will evolve along with it. How to develop a trading system It is also important that the edge is robust. A system is robust when it maintains positive expectancy. The system should be tested on an up, down and sideways move. Many trend following systems perform well when the instrument trends but don8217t do as well when the instrument is in a sideways whipsaw period. It is crucial that the period is taken into account during back testing. I recommend back-testing on at least 2000 bars. If you are backtesting a system on the daily charts I recommend using 10 years. On the intra-day charts I recommend back testing the systems as far back as your data vendor will allow. This is usually 6 months to a year. Back Testing Programs It is important to use professional level software with back-testing capabilities when developing your system. To name a few: One of the best back testing programs out there although programming may be difficult as it is in Pascal. There is no phone customer service for wealth-lab either. NCMfx offers programming services at competitive rates, and at tremendous discounts for its existing forex customers. Risk management Features System development wizard Professional level back-testing and analysis software. Metastock offers numerous trading systems and indicators. Metastock has its own language, it may be a bit easier than Wealth-Lab but far more limited. The customer service is good. And there are numerous add ons and plug ins that you can purchase to suite your style of trading. NCMfx offers programming services at competitive rates, and at tremendous discounts for its existing forex customers. Alexander Nekritin is a professional trader with over 8 years of experience. His specialties include risk management and system development. Alexander is the CEO of forexyourself. which is a forex introducing broker and education company that helps suite client8217s needs in forex trading. Alexander has a degree with a concentration in Investment Banking and derivative instruments from Babson College in Massachusetts. I have been programming for a few decades now, but also trading currencies, stocks and futures, using intensively technical analysis algorithms. I made the mistake a few years ago to take the HTML CSS JAVASCRIPT PHP MySQL road and program Internet sites from scratch, cookies, etc. BO-RING to death and new CMS pop out every day, pushing me swiftly out of the labor market. Getting old now (47 ), I would like to secure the future by closing the loop and learn C specifically for high frequency trading. Would you please give me advice about where I should start, about specific programming techniques within C I should focus on Thank you very much To answer your questions youll want to focus on Sockets, RSS feeds (double check that one), system security (IMHO either sand boxing or a ROM OS for something like this), encryption and authentication and the protocols specific to the exchange your choose. If you dont mind I had some questions of my own. What makes you think that there is any money what so ever in HFT This is a market manipulation tool, not an investment strategy. And to play that game you would need to have billions in the bank to begin with. People seem to have the impression that this is the technological evolution of short running a stock but it isnt. This is a technique used to rapidly respond to buyingselling trends with a large volume of transactions to shift the market in whatever direction would make the most money for the operator. Also, I dont know what country youre in but here in the US net neutrality is back on the chopping block. If that dies and you cant secure a connection to an exchange that pays whatever premium price to your service provider then the latency might make this functionally impossible. That may just be me being paranoid but its something you should consider. Last edited on Jun 26, 2014 at 5:29pm UTC Thank you VERY MUCH computergeek, your input is highly appreciated. It seems that you are already quite experienced in that market. I actually enjoy playing the middle man, sort of interfacing between traders minds and IT programmers minds. To do a god job, I must be good technically on both domains. I already now the trading side and the algorithm world quite well, I dont know s..t about C so I am forcing myself into it :-) That is what I did already for very largest corporations in Switzerland (not in HFT though), so yes, that is not my pocket money, and yes, we are talking about large trade amounts. A simple reason is you do not want your broker to be the only one doing money so indeed you need big bucks, negociate spreads and own a seat on the futures exchange for instance. Last edited on Jun 26, 2014 at 4:45pm UTC Computergeek01 I think OP means working as a C programmer, not starting a new firm philgib Define secure the future Anyway, you can start by looking at a few recent HF job ads to see what they are interested in For example, Ill pick two at random Sample 1. Required Skills: Bachelors or Masters in Computer Science or related field 10 years of hands on experience in all aspects of enterprise level C application development and management expertise in low level development and technologies (kernel tuningbypass, cpu pinning, hardware optimizations, network transport protocols including TCP and UDP) application performance profiling and tuning tool kits (VTune, Valgrind, PGO, etc), and various physical architectures x86 based systems Sample 2. Requirements: CC developer with 3 years of experience developing low latency real time trading systems (UnixLinux environment) Familiar with Execution Algos and understanding of CLOB trading and Exchange Protocols (FIX, ITCHOUCH etc) Experience designing multi-threaded applications Expert knowledge of networks and operating systems Strong analytical and problem solving skills Experience with FPGA andor VHDL programmingdesign is a plus, but not required