El mejor lenguaje de programación para sistemas de comercio algorítmico Por Michael Salas-Moore el 26 de julio 2013 Una de las preguntas más frecuentes que recibo en la carpeta de correo QS es ¿Cuál es el mejor lenguaje de programación para el comercio algorítmico. La respuesta corta es que no hay mejor lenguaje. parámetros de la estrategia, el rendimiento, modularidad, el desarrollo, la capacidad de recuperación y el costo de todo deben ser considerados. Este artículo se describen los componentes necesarios de una arquitectura de sistema de negociación algorítmica y cómo las decisiones relativas a la aplicación afectará a la elección de la lengua. En primer lugar, se tendrán en cuenta los principales componentes de un sistema de comercio algorítmico, tales como las herramientas de investigación, optimizador de la cartera, gestor de riesgos y el motor de ejecución. Posteriormente, se examinarán diferentes estrategias de negociación y cómo afectan al diseño del sistema. En particular, será tanto se discutirá la frecuencia de la negociación y el volumen de operaciones probable. Una vez que la estrategia de negociación ha sido seleccionado, es necesario arquitecto todo el sistema. Esto incluye elección del hardware, el sistema operativo (s) y la resistencia del sistema contra eventos raros, potencialmente catastróficas. Mientras se está considerando la arquitectura, debe prestarse la debida atención a rendimiento - tanto a las herramientas de investigación, así como el entorno de ejecución en vivo. ¿Cuál es el sistema de comercio tratando de realizar antes de decidir sobre el mejor lenguaje para escribir un sistema de comercio automatizado es necesario definir los requisitos. Es el sistema va a ser puramente de ejecución basado ¿El sistema requiere la construcción de un módulo de gestión de riesgos o de la cartera ¿El sistema requiere una backtester de alto rendimiento para la mayoría de las estrategias del sistema de comercio se pueden dividir en dos categorías: Investigación y generación de señales. La investigación se refiere a la evaluación de una estrategia de actuación a través de datos históricos. El proceso de evaluación de una estrategia de negociación sobre los datos de mercado antes de que se conoce como backtesting. El tamaño de los datos y la complejidad algorítmica tendrán un gran impacto en la intensidad computacional de la backtester. velocidad de la CPU y la concurrencia a menudo son los factores limitantes en la optimización de la velocidad de ejecución de la investigación. La generación de señales se ocupa de generar un conjunto de señales de operación de un algoritmo y el envío de este tipo de órdenes al mercado, por lo general a través de una casa de valores. Para ciertas estrategias se requiere un alto nivel de rendimiento. E / S de cuestiones tales como ancho de banda y latencia son a menudo el factor limitante en la optimización de los sistemas de ejecución. Por lo tanto la elección de idiomas para cada componente de todo el sistema puede ser muy diferente. El tipo, frecuencia y volumen de Estrategia El tipo de estrategia algorítmica empleado tendrá un impacto sustancial en el diseño del sistema. Será necesario tener en cuenta los mercados se comercializan, la conectividad a los proveedores de datos externos, la frecuencia y el volumen de la estrategia, el equilibrio entre la facilidad de desarrollo y la optimización del rendimiento, así como cualquier hardware personalizado, incluida la costumbre de ubicación conjunta servidores, GPU o FPGAs que podrían ser necesarios. Las opciones de tecnología para una estrategia de renta variable de Estados Unidos de baja frecuencia serán muy diferentes de las de una alta frecuencia de arbitraje estadístico de comercio estrategia en el mercado de futuros. Antes de la elección de la lengua muchos proveedores de datos deben ser evaluados que pertenecen a una estrategia de la que nos ocupa. Será necesario tener en cuenta la conectividad con el proveedor, la estructura de cualquier API, la puntualidad de los datos, los requisitos de almacenamiento y capacidad de recuperación en la cara de un proveedor de desconectarse. También es aconsejable poseer un acceso rápido a múltiples proveedores diversos instrumentos, todos tienen sus propias peculiaridades de almacenamiento, ejemplos de los cuales incluyen múltiples símbolos de cotización de las acciones y las fechas de vencimiento de futuros (por no hablar de todos los datos específicos de venta libre). Esto debe tenerse en cuenta en el diseño de la plataforma. Frecuencia de la estrategia es probable que sea uno de los mayores impulsores de la forma en que se define el conjunto de tecnología. Las estrategias que emplean datos con mayor frecuencia que las barras minúsculas o en segundo lugar requieren una consideración importante en cuanto a rendimiento. Una estrategia superior en segundo bares (es decir, los datos tick) conduce a un diseño basado en el rendimiento como la exigencia principal. Para las estrategias de alta frecuencia tendrá que ser almacenado y evaluado una cantidad sustancial de datos de mercado. Software como HDF5 o kdb se utilizan comúnmente para estas funciones. Con el fin de procesar los amplios volúmenes de datos necesarios para las aplicaciones de HFT, se debe utilizar un sistema de backtester y ejecución ampliamente optimizado. C / C (posiblemente con algún ensamblador) es probable que el candidato lenguaje más fuerte. estrategias de ultra-alta frecuencia es casi seguro que requieren hardware personalizado tales como FPGAs, cambio de ubicación conjunta y puesta a punto de interfaz de kernel / red. Sistemas de investigación de los sistemas de investigación suelen incluir una mezcla de desarrollo interactivo y secuencias de comandos automatizadas. La primera a menudo se lleva a cabo dentro de un entorno de desarrollo como Visual Studio, MatLab o R Studio. Este último implica extensos cálculos numéricos más numerosos parámetros y puntos de datos. Esto lleva a una elección de idioma proporcionar un entorno fácil de código de prueba, sino que también proporciona suficiente rendimiento para evaluar las estrategias más de múltiples dimensiones de parámetros. IDE típicas en este espacio incluyen Microsoft Visual descripciones sencillas de toda la pila de proyecto (a través del ORM base de datos, LINQ) MatLab C / C, que contiene utilidades de depuración extensa, las capacidades de finalización de código (a través de Intellisense) y. los cuales está diseñado para una amplia álgebra lineal numérica y operaciones vectorizados, pero de una manera interactiva consola de R-Studio. que envuelve la consola lenguaje estadístico R en una de pleno derecho IDE Eclipse IDE para Linux Java y C y entornos de desarrollo semi-propietarios como Enthought Toldo para Python, que incluyen bibliotecas de análisis de datos, tales como NumPy. SciPy. scikit-learn y pandas en un único entorno interactivo (consola). Para backtesting numérica, todos los idiomas antes mencionados son adecuados, aunque no es necesario utilizar una interfaz gráfica de usuario / IDE como el código se ejecuta en segundo plano. La consideración principal en esta etapa es la de la velocidad de ejecución. Un lenguaje compilado (como C) es a menudo útil si las dimensiones de parámetros backtesting son grandes. Recuerde que es necesario tener cuidado con este tipo de sistemas si ese es el idioma de caso interpretado como Python a menudo hacen uso de las bibliotecas de alto rendimiento, tales como NumPy / pandas para la etapa de backtesting, con el fin de mantener un grado razonable de competitividad con el compilado equivalentes. En última instancia el idioma elegido para la backtesting será determinado por las necesidades de algoritmos específicos, así como la gama de bibliotecas disponibles en el idioma (más sobre esto más adelante). Sin embargo, el idioma utilizado en los entornos Backtester y de investigación puede ser completamente independientes de los utilizados en los componentes de la construcción de la cartera, gestión de riesgos y de ejecución, como se verá. Cartera de construcción y gestión de riesgo Los componentes de la construcción de la cartera y de gestión de riesgos son a menudo pasados por alto por los comerciantes minoristas algorítmicos. Esto es casi siempre un error. Estas herramientas proporcionan el mecanismo por el cual se conservará capital. No sólo intentan aliviar el número de apuestas arriesgadas, sino también minimizar la rotación de los oficios a sí mismos, lo que reduce los costos de transacción. versiones sofisticadas de estos componentes pueden tener un efecto significativo en la calidad y consistentcy de la rentabilidad. Es sencillo crear un establo de estrategias como el mecanismo de construcción de la cartera y gestor de riesgos puede ser fácilmente modificado para manejar múltiples sistemas. Por lo tanto deben ser considerados componentes esenciales desde el principio del diseño de un sistema de comercio algorítmico. El trabajo del sistema de construcción de la cartera es tomar un conjunto de operaciones deseadas y producir el conjunto de las operaciones reales que reduzcan al mínimo la rotación, mantener la exposición a diversos factores (por ejemplo, sectores, clases de activos, volatilidad, etc.) y optimizar la asignación de capital para varios estrategias en una cartera. construcción de la cartera reduce a menudo a un problema de álgebra lineal (tal como una matriz de factorización) y por lo tanto el rendimiento es altamente dependiente de la eficacia de la aplicación de álgebra lineal numérica disponible. bibliotecas comunes incluyen uBLAS. LAPACK y NAG para C. MatLab también posee operaciones de la matriz ampliamente optimizadas. Python utiliza NumPy / SciPy para tales cálculos. Una cartera reequilibrado con frecuencia requerirá una biblioteca compilada matriz (y bien optimizado) para llevar a cabo este paso, a fin de no cuello de botella en el sistema de comercio. La gestión de riesgos es otra parte muy importante de un sistema de comercio algorítmico. El riesgo puede ser de muchas formas: aumento de la volatilidad (aunque esto puede ser visto como deseable para ciertas estrategias), el aumento de las correlaciones entre las clases de activos, por defecto de contraparte, las interrupciones del servidor, eventos cisne negro y errores no detectados en el código de comercio, por nombrar pocos. Componentes de la gestión del riesgo Trata de anticipar los efectos de la excesiva volatilidad y correlación entre las clases de activos y su posterior efecto (s) en la capital comercial. A menudo, esto se reduce a un conjunto de cálculos estadísticos, como las pruebas de tensión de Monte Carlo. Esto es muy similar a las necesidades computacionales de un derivado de motor de precios y como tal será CPU-bound. Estas simulaciones son altamente parallelisable (ver abajo) y, en cierta medida, es posible tirar de hardware en el problema. Sistemas de Ejecución El trabajo del sistema de ejecución es para recibir las señales de comercio filtrados a partir de los componentes de la construcción de la cartera y de gestión de riesgos y enviarlos a una casa de valores u otros medios de acceso a los mercados. Para la mayoría de las estrategias de negociación algorítmica minoristas esto implica una conexión API o FIX para una casa de valores tales como Interactive Brokers. Las principales consideraciones al decidir sobre un lenguaje incluyen la calidad de la API, la disponibilidad de idiomas-envoltura para un API, frecuencia de ejecución y el deslizamiento esperado. La calidad de la API se refiere a qué tan bien documentado que es, qué tipo de prestaciones que ofrece, si se necesita software independiente que se acceda o si una puerta de entrada se puede establecer de una manera sin cabeza (es decir, sin interfaz gráfica de usuario). En el caso de Interactive Brokers, la herramienta de Trader Workstation debe estar en ejecución en un entorno de interfaz gráfica de usuario con el fin de tener acceso a su API. Una vez tuve que instalar una edición de escritorio Ubuntu en un servidor de la nube de Amazon para acceder de forma remota Interactive Brokers, puramente por esta razón mayoría de las API proporcionarán una C y / o interfaz Java. Por lo general, corresponde a la comunidad para desarrollar envoltorios específicos del idioma para C, Python, R, Excel y MATLAB. Tenga en cuenta que con cada plug-in adicional utilizada (especialmente las envolturas de la API) existe la posibilidad de errores se deslicen en el sistema. Pruebe siempre los plugins de este tipo y garantizar que se mantienen de forma activa. Un indicador de que vale la pena es ver cómo se han hecho muchos nuevos cambios a una base de código en los últimos meses. frecuencia de ejecución es de suma importancia en el algoritmo de ejecución. Tenga en cuenta que cientos de órdenes se pueden enviar cada minuto y, como tal, el rendimiento es crítico. El deslizamiento se haya incurrido a través de un sistema de ejecución de mal rendimiento y esto tendrá un impacto dramático en la rentabilidad. lenguajes de tipo estático (véase más adelante), tales como C / Java son generalmente óptimos para su ejecución, pero hay una compensación en tiempo de desarrollo, prueba y facilidad de mantenimiento. lenguajes de tipo dinámico, como Python y Perl son ahora generalmente lo suficientemente rápido. Siempre que los componentes están diseñados de forma modular (véase más adelante) de manera que se pueden intercambiar como las escalas del sistema. Planificación y Desarrollo Arquitectónico de proceso Los componentes de un sistema de comercio, sus requisitos de frecuencia y volumen se han discutido anteriormente, pero la infraestructura del sistema aún no se ha cubierto. Aquellos que actúan como un comerciante minorista o trabajar en un pequeño fondo probablemente serán diferentes papeles. Será necesario estar cubriendo los parámetros del modelo alfa, gestión del riesgo y de ejecución, así como la aplicación final del sistema. Antes de ahondar en los lenguajes específicos se discutirá el diseño de una arquitectura óptima del sistema. La separación de preocupaciones Una de las decisiones más importantes que se deben hacer al principio es cómo separar las preocupaciones de un sistema de comercio. En el desarrollo de software, esto significa esencialmente cómo dividir los diferentes aspectos del sistema de comercio en componentes modulares independientes. Al exponer las interfaces en cada uno de los componentes es fácil de intercambiar partes del sistema para otras versiones de que la ayuda de rendimiento, fiabilidad y mantenimiento, sin modificar ningún código dependencia externa. Esta es la mejor práctica para este tipo de sistemas. Para que las estrategias a frecuencias más bajas se aconsejará a tales prácticas. Para la negociación de alta frecuencia ultra el libro de reglas podría tener que ser ignorado a expensas de ajustar el sistema para un rendimiento aún más. Un sistema acoplado con más fuerza puede ser deseable. Crear un mapa componente de un sistema de comercio algorítmico vale un artículo en sí mismo. Sin embargo, un enfoque óptimo es para asegurarse de que son componentes separados para las entradas de datos de mercado históricos y en tiempo real, almacenamiento de datos, la API de acceso a datos, Backtester, parámetros de la estrategia, la construcción de carteras, gestión de riesgos y sistemas de ejecución automatizados. Por ejemplo, si el almacén de datos que se utiliza actualmente es de bajo rendimiento, incluso a niveles significativos de optimización, puede cambiarse por reescrituras mínimos en la ingestión de datos o acceso a los datos API. En la medida de la que la backtester y los componentes posteriores se refiere, no hay diferencia. Otro de los beneficios de los componentes separados es que permite que una variedad de lenguajes de programación para ser utilizado en el sistema general. No hay necesidad de limitarse a un solo idioma, si el método de comunicación de los componentes es independiente del lenguaje. Este será el caso si se están comunicando a través de TCP / IP, ZeroMQ o algún otro protocolo independiente del lenguaje. Como ejemplo concreto, consideremos el caso de un sistema de pruebas retrospectivas siendo escrito en C para procesamiento de números de rendimiento, mientras que los sistemas y gestor de la cartera de ejecución están escritos en Python usando SciPy y IBPy. Consideraciones de rendimiento El rendimiento es una consideración importante para la mayoría de las estrategias de negociación. Para las estrategias de frecuencia más alta es el factor más importante. Rendimiento cubre una amplia gama de temas, tales como la velocidad de ejecución algorítmica, la latencia de red, ancho de banda, los datos de E / S, la concurrencia / paralelismo y escalamiento. Cada uno de estos elementos se encuentran en forma individual por los grandes libros de texto, por lo que este artículo sólo pueden rayar la superficie de cada tema. Arquitectura y la elección de idioma seleccionado, se discuten en términos de sus efectos sobre el rendimiento. La idea predominante según lo declarado por Donald Knuth. uno de los padres de la informática, es que la optimización prematura es la raíz de todos los males. Esto es casi siempre el caso -, excepto cuando se construye un algoritmo de negociación de alta frecuencia Para aquellos que están interesados en las estrategias de frecuencias más bajas, un enfoque común es la construcción de un sistema de la manera más simple posible y sólo optimizar los cuellos de botella que comienzan a aparecer. Herramienta básica se utilizan para determinar dónde surgen cuellos de botella. Los perfiles pueden ser hechas para todos los factores mencionados anteriormente, ya sea en un entorno MS Windows o Linux. Hay muchas herramientas del sistema operativo y de idioma disponibles para hacerlo, así como utilidades de terceros. la elección del idioma se discutirá ahora en el contexto de rendimiento. C, Java, Python, R y MATLAB contiene todas las bibliotecas de alto rendimiento (ya sea como parte de su norma o externamente) para la estructura de datos básica y la algorítmica. barcos C con la Biblioteca de plantillas estándar, mientras que Python contiene NumPy / SciPy. tareas matemáticas comunes se encuentran en estas bibliotecas y rara vez es beneficioso para escribir una nueva aplicación. Una excepción es si se requiere una arquitectura de hardware altamente personalizado y un algoritmo está haciendo un amplio uso de extensiones propietarias (como cachés personalizados). Sin embargo, a menudo la reinvención de la rueda que pierde el tiempo podría ser mejor gastado desarrollo y optimización de otras partes de la infraestructura de negociación. El tiempo de desarrollo es extremadamente valioso, especialmente en el contexto de los desarrolladores individuales. Latencia a menudo es un problema del sistema de ejecución como las herramientas de investigación, generalmente situados en la misma máquina. En el primer caso, la latencia puede ocurrir en varios puntos a lo largo de la ruta de ejecución. Las bases de datos deben ser consultados (latencia de disco / red), las señales deben ser generados (syste operativo, la latencia de mensajes de kernel), las señales enviadas comerciales (NIC) de latencia y las órdenes procesadas (sistemas de intercambio de latencia interna). Para las operaciones de mayor frecuencia es necesario estar íntimamente familiarizado con la optimización kernal así como la optimización de transmisión de la red. Esta es una zona profunda y es significativamente más allá del alcance de este artículo, pero si se desea un algoritmo UHFT a continuación, ser consciente de la profundidad de los conocimientos necesarios de caché es muy útil en el kit de herramientas de desarrollador de comercio cuantitativo. El almacenamiento en caché se refiere al concepto de almacenamiento de datos de acceso frecuente en una manera que permite el acceso de mayor rendimiento, a expensas de potencial estancamiento de los datos. Un caso de uso común se produce en el desarrollo web al tomar datos de una base de datos relacional de disco con respaldo y ponerlo en la memoria. Toda solicitud posterior de los datos no tienen que golpear la base de datos y así mejoras de rendimiento pueden ser significativos. Para situaciones comerciales de almacenamiento en caché puede ser muy beneficioso. Por ejemplo, el estado actual de una cartera estrategia se puede almacenar en una memoria caché hasta que se reequilibra, de manera que la lista doesn t necesita ser regenerado en cada bucle del algoritmo de negociación. Dicha regeneración es probable que sea una operación de la CPU o el disco I / O. Sin embargo, el almacenamiento en caché no es sin sus propios problemas. La regeneración de datos de la caché a la vez, debido a la naturaleza volatilie de almacenamiento de memoria caché, puede colocar una demanda significativa en la infraestructura. Otra cuestión es el perro con pilotes. donde varias generaciones de una nueva copia caché se realizan bajo carga extremadamente alta, lo que conduce a la cascada fracaso. Asignación dinámica de memoria es una operación costosa en la ejecución de software. Por lo tanto, es imperativo para las aplicaciones comerciales de mayor rendimiento para estar bien conscientes de cómo se asigna y desasigna durante el desarrollo del programa de memoria. normas lingüísticas más recientes, como Java, C y Python todos realizan la recolección de basura automático. lo que se refiere a la cancelación de asignación de memoria asignada dinámicamente cuando los objetos salen de su alcance. La recolección de basura es extremadamente útil durante el desarrollo, ya que reduce los errores y las ayudas para mejorar la legibilidad. Sin embargo, con frecuencia es subóptima para ciertas estrategias de negociación de alta frecuencia. A menudo se desea la recogida de basura a medida para estos casos. En Java, por ejemplo, sintonizando el recolector de basura y la configuración del montón, es posible obtener un alto rendimiento para las estrategias de HFT. C doesn t proporcionar un recolector de basura nativa y por lo que es necesario para manejar toda la asignación de memoria / cancelación de asignación como parte de la implementación de un objeto s. Mientras que potencialmente propenso a errores (que puede conducir a la referencia colgante) es extremadamente útil tener un control detallado de la forma en que los objetos aparecen en el montón para ciertas aplicaciones. Al elegir un idioma asegúrese de estudiar cómo funciona el recolector de basura y si puede ser modificado para optimizar para un caso en particular. Muchas operaciones en los sistemas de negociación algorítmica son susceptibles de paralelización. Esto se refiere al concepto de la realización de múltiples operaciones de programación al mismo tiempo, es decir en paralelo. Los llamados algoritmos embarazosamente paralelos incluyen pasos que se pueden calcular de forma totalmente independiente de otras medidas. Ciertas operaciones estadísticas, tales como simulaciones de Monte Carlo, son un buen ejemplo de algoritmos embarazosamente paralelos como cada sorteo y posterior operación de trazado se puede calcular sin el conocimiento de otros caminos. Otros algoritmos son sólo parcialmente parallelisable. dinámica de fluidos simulaciones son un ejemplo tal, en el que el dominio de cálculo se puede subdividir, pero en última instancia, estos dominios deben comunicarse entre sí y por lo tanto las operaciones son parcialmente secuencial. Parallelisable algoritmos están sujetos a la Ley de Amdahl s. que proporciona un límite superior teórico para el aumento de rendimiento de un algoritmo paralelizada cuando se somete a N procesos separados (por ejemplo, sobre un núcleo de CPU o hilo). Paralelización se ha vuelto cada vez más importante como medio de optimización desde el procesador velocidades de reloj se han estancado, como nuevos procesadores contienen muchos núcleos con el que realizar cálculos paralelos. El ascenso de hardware de gráficos de consumo (predominantemente para videojuegos) ha dado lugar al desarrollo de unidades de procesamiento gráfico (GPU), que contienen cientos de núcleos para las operaciones altamente concurrentes. Tales GPU son ahora muy asequible. marcos de alto nivel, tales como CUDA de Nvidia s han conducido a la adopción generalizada en el mundo académico y las finanzas. Tal hardware de la GPU es por lo general sólo es adecuado para el aspecto de la investigación de las finanzas cuantitativas, mientras que el otro hardware más especializado (incluyendo campo-matrices de puertas programables - FPGAs) se utilizan para (U) HFT. Hoy en día, la mayoría de langauges actuales son compatibles con un grado de concurrencia / multihilo. Por lo tanto, es sencillo para optimizar un backtester, ya que todos los cálculos son generalmente independientes de los otros. Incrustaciones en ingeniería de software y las operaciones se refiere a la capacidad del sistema para manejar cargas crecientes constantemente en forma de mayores solicitudes, el uso del procesador mayor y más asignación de memoria. En el comercio algorítmico es una estrategia capaz de escalar si se puede aceptar grandes cantidades de capital y aún producir retornos consistentes. La pila de tecnología de operaciones escalas si puede soportar volúmenes comerciales más grandes y mayor latencia, sin cuellos de botella. Mientras que los sistemas deben ser diseñados a escala, a menudo es difícil predecir de antemano dónde se producirá un cuello de botella. registro riguroso, las pruebas, el perfilado y el seguimiento serán de gran ayuda en un sistema que permite a escala. lenguas mismas se describen a menudo como no escalable. Este suele ser el resultado de la información falsa, en lugar de hecho duro. Es la tecnología de pila total que debería determinarse para la escalabilidad, no el lenguaje. Está claro que ciertas lenguas tienen un mayor rendimiento que otros en determinados casos de uso, pero un idioma nunca es mejor que otro en todos los sentidos. Una medida de gestión de escala es separar preocupaciones, como se ha indicado anteriormente. Con el fin de introducir aún más la capacidad de manejar picos en el sistema (es decir, la volatilidad repentina que desencadena una serie de operaciones), es útil para crear una arquitectura de colas de mensajes. Esto simplemente significa la colocación de un sistema de cola de mensajes entre los componentes de modo que los pedidos se apilan si un determinado componente no puede procesar muchos pedidos. En lugar de las solicitudes están perdiendo simplemente son mantenidos en una pila hasta que se maneja el mensaje. Esto es particularmente útil para el envío de los oficios a un motor de ejecución. Si el motor está sufriendo bajo la latencia pesada a continuación, se copia de seguridad de las operaciones. Una cola entre el generador de señal de comercio y la API de ejecución será de aliviar este problema, a expensas de deslizamiento potencial comercial. Un corredor de cola de mensajes de código abierto es muy respetado RabbitMQ. Hardware y Sistemas Operativos El hardware que ejecuta su estrategia pueden tener un impacto significativo en la rentabilidad de su algoritmo. Este no es un problema restringido a los operadores de alta frecuencia tampoco. Una mala elección en el hardware y el sistema operativo puede conducir a un accidente o reiniciar la máquina en el momento más inoportuno. Por lo tanto, es necesario tener en cuenta en la aplicación va a residir. La elección es por lo general entre una máquina personal de escritorio, un servidor remoto, un proveedor de nube o un servidor de intercambio de co-localizado. ordenadores de mesa son fáciles de instalar y administrar, en especial con los sistemas operativos amigables nuevos usuarios como Windows 7/8, Mac OS X y Ubuntu. Los sistemas de escritorio sí poseen algunos inconvenientes importantes, sin embargo. El más importante es que las versiones de los sistemas operativos diseñados para máquinas de escritorio es probable que requieran reinicios / parches (y, a menudo en el peor de los tiempos). También utilizan más recursos computacionales por la virtud de que requiere una interfaz gráfica de usuario (GUI). Utilizando el hardware en una casa (o la oficina local) medio ambiente puede conducir a problemas de conectividad de Internet y el tiempo de actividad de potencia. La principal ventaja de un sistema de escritorio es tan significativo poder de cómputo se pueden comprar por una fracción del costo de un servidor dedicado (o un sistema basado en la nube) remota de velocidad comparable. Una máquina servidor dedicado o cloud-based, aunque a menudo más caro que una opción de escritorio, permite la redundancia de la infraestructura más importantes, tales como copias de seguridad de datos automatizados, la capacidad de garantizar el tiempo de actividad más directa y la monitorización remota. Son más difíciles de administrar ya que requieren la capacidad de utilizar las capacidades de acceso remoto del sistema operativo. En Windows esto es generalmente a través de la interfaz gráfica de usuario de Remote Desktop Protocol (RDP). En los sistemas basados en Unix la línea de comandos se utiliza Secure Shell (SSH). infraestructura de servidores basados en Unix es casi siempre de línea de comandos basada en lo que hace inmediatamente herramientas de programación basadas en GUI (como Matlab o Excel) para ser inutilizable. Un servidor de co-situado, como la frase se utiliza en los mercados de capitales, es simplemente un servidor dedicado que reside dentro de un intercambio con el fin de reducir la latencia del algoritmo de negociación. Esto es absolutamente necesario para ciertas estrategias de negociación de alta frecuencia, que dependen de baja latencia con el fin de generar alfa. El último aspecto a elección del hardware y la elección del lenguaje de programación es independencia de la plataforma. ¿Hay una necesidad de que el código se ejecute a través de múltiples sistemas operativos diferentes es el código diseñado para ser ejecutado en un determinado tipo de arquitectura del procesador, como el Intel x86 / x64 o será posible ejecutar en procesadores RISC, tales como los fabricados por ARM Estas cuestiones serán altamente dependiente de la frecuencia y el tipo de estrategia que se implementa. La resiliencia y pruebas Una de las mejores maneras de perder una gran cantidad de dinero en el comercio algorítmico es crear un sistema sin capacidad de recuperación. Esto se refiere a la durabilidad del Inglés cuando están sujetos a eventos raros, tales como la quiebra repentina de bolsa, el exceso de volatilidad, el tiempo de inactividad en toda la región por un proveedor de servidor de la nube o la eliminación accidental de una base de datos de comercio entero. Años de beneficios pueden ser eliminados en cuestión de segundos con una arquitectura mal diseñada. Es absolutamente esencial tener en cuenta cuestiones como la debuggng, las pruebas, la explotación forestal, las copias de seguridad, alta disponibilidad y monitoreo, como componentes fundamentales de su sistema. Es probable que en cualquier aplicación de comercio cuantitativa encargo razonablemente complicada al menos 50 de tiempo de desarrollo se destinarán a la depuración, pruebas y mantenimiento. Casi todos los lenguajes de programación, ya sea buque con un depurador asociado o poseer alternativas de terceros respetados. En esencia, un depurador permite la ejecución de un programa con la inserción de puntos de ruptura arbitrario en la ruta de código, que detener temporalmente la ejecución con el fin de investigar el estado del sistema. El principal beneficio de la depuración es que es posible investigar el comportamiento del código antes de un punto de choque conocido. La depuración es un componente esencial en la caja de herramientas para el análisis de los errores de programación. Sin embargo, ellos son los más utilizados en los lenguajes compilados como C o Java, como lenguajes interpretados como Python suelen ser más fáciles de depurar debido al menor número COL y declaraciones menos detallados. A pesar de esta tendencia Python no se incluyen con el AP. que es una herramienta de depuración sofisticado. El IDE de Microsoft Visual C posee extensas utilidades GUI de depuración, mientras que para la línea de comandos de Linux programador de C, existe el depurador GDB. Las pruebas en el desarrollo de software se refiere al proceso de aplicar los parámetros y resultados a funciones específicas, métodos y objetos dentro de una base de código conocidos, con el fin de simular el comportamiento y evaluar múltiples caminos de códigos, ayudando a asegurar que un sistema se comporta como debería. Un paradigma más reciente se conoce como Test Driven Development (TDD), en donde se desarrolla el código de prueba en contra de una interfaz especificada sin aplicación. Antes de la terminación de la base de código actual todas las pruebas fallarán. Como código está escrito para llenar los espacios en blanco, las pruebas con el tiempo todos pasan, en el que el desarrollo punto debe cesar. TDD requiere una amplia especificación de diseño de antemano, así como un grado saludable de disciplina con el fin de llevar a cabo con éxito. En C, Boost proporciona un marco de pruebas unitarias. En Java, la biblioteca JUnit existe para cumplir el mismo propósito. Python también tiene el módulo de unittest como parte de la biblioteca estándar. Muchas otras lenguas poseen marcos de pruebas unitarias y, a menudo hay varias opciones. En un entorno de producción, la tala sofisticada es absolutamente esencial. El registro se refiere al proceso de emisión de mensajes, con diversos grados de gravedad, en relación con el comportamiento de ejecución de un sistema en un archivo plano o base de datos. Los registros son una primera línea de ataque cuando la caza de un comportamiento inesperado en tiempo de ejecución del programa. Por desgracia, las deficiencias de un sistema de registro sólo tienden a ser descubiertos después de los hechos Al igual que con las copias de seguridad mencionadas a continuación, un sistema de registro debe dar la debida consideración antes de que un sistema ha sido diseñado. Tanto Microsoft Windows y Linux vienen con una amplia capacidad de registro del sistema y los lenguajes de programación tienden a enviar con bibliotecas de registro estándar que cubren la mayoría de los casos de uso. A menudo es aconsejable para centralizar la información de registro con el fin de analizarlo en una fecha posterior, ya que a menudo puede conducir a ideas para mejorar el rendimiento o la reducción de errores, lo que es casi seguro que tendrá un impacto positivo en sus declaraciones de negociación. Mientras que la tala de un sistema proporcionará información acerca de lo que ha ocurrido en el pasado, el seguimiento de una aplicación va a dar una idea de lo que está sucediendo en este momento. Todos los aspectos del sistema deben ser considerados para el monitoreo. métricas de nivel de sistema, tales como el uso de disco, memoria disponible, el ancho de banda de la red y el uso de CPU proporcionan información sobre la carga básica. métricas comerciales tales como los precios anormales / volumen, descensos rápidos y repentinos en cuenta la exposición de los diferentes sectores / mercados también serán observadas. Además, un sistema de umbrales deben ponerse en marcha que proporciona una notificación cuando no se cumplen ciertas métricas, elevando el método de notificación (correo electrónico, SMS, llamada telefónica automatizada) dependiendo de la severidad de la métrica. La monitorización del sistema es a menudo el dominio del gestor o administrador de operaciones del sistema. Sin embargo, como un desarrollador de comercio único, estas métricas deben constituirse como parte del diseño más grande. Muchas soluciones de control existen: propietario, organizada y de código abierto, lo que permite una amplia personalización de las métricas para un caso en particular.
No comments:
Post a Comment