Mejor Lenguaje De Programación De Sistemas De Trading Algorítmico

Mejor Lenguaje de Programación de Sistemas de trading 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 existe un lenguaje "mejor". 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 comercio algorítmico 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, como las herramientas de investigación, portafolio optimizador, gestor de riesgos y el motor de ejecución. Posteriormente, diferentes estrategias de negociación serán examinadas y cómo afectan al diseño del sistema. En particular, se discutirá la frecuencia de la negociación y el volumen de comercio probablemente ambos. 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óficos. Mientras se está considerando la arquitectura, la debida atención debe prestarse a los resultados - 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 hacer? Antes de decidir sobre la "mejor" lenguaje con el que escribir un sistema de comercio automatizado es necesario definir los requisitos. ¿El sistema va a estar basada puramente ejecución? ¿El sistema requiere un módulo de gestión de riesgos o construcción de la cartera? ¿El sistema requiere una backtester de alto rendimiento? Para la mayoría de las estrategias del sistema de comercio se puede dividir en dos categorías: la generación de la Investigación y de la señal. La investigación tiene que ver con la evaluación de un rendimiento de la estrategia 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 del 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 la señal tiene que ver con la generación de un conjunto de señales de operación de un algoritmo y el envío de dichas ó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 el ancho de banda y la latencia son a menudo el factor limitante en la optimización de los sistemas de ejecución. Así, la elección de las lenguas de cada componente de todo el sistema puede ser muy diferente. Tipo, frecuencia y volumen de Estrategia El tipo de estrategia de algorítmica empleado tendrá un impacto sustancial en el diseño del sistema. Será necesario tener en cuenta los mercados se negocian, la conectividad a los proveedores de datos externos, la frecuencia y el volumen de la estrategia, el trade-off entre la facilidad de desarrollo y optimización del rendimiento, así como cualquier hardware personalizado, incluyendo co-ubicada personalizada servidores, GPU o FPGAs que podrían ser necesarios. Las opciones de tecnología para una estrategia de renta variable de Estados Unidos baja frecuencia serán muy diferentes de las de una alta frecuencia de arbitraje estadístico estrategia de negociación en el mercado de futuros. Antes de la elección de idioma que muchos proveedores de datos deben ser evaluados que pertenecen a una estrategia que nos ocupa. Será necesario tener en cuenta la conectividad con el vendedor, la estructura de las APIs, la puntualidad de los datos, los requisitos de almacenamiento y capacidad de recuperación frente a un vendedor de ir fuera de línea. También es aconsejable poseer un rápido acceso a múltiples proveedores! Varios instrumentos 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 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 la pila de tecnología. Estrategias que emplean datos con más frecuencia que minuciosamente o en segundo bares requieren una consideración importante en cuanto a rendimiento. Una estrategia superior en segundo bares (es decir tick datos) conduce a un diseño basado en el rendimiento como el requisito primario. Para que 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 estos roles. Para procesar los amplios volúmenes de datos necesarios para las aplicaciones de HFT, se debe utilizar un sistema backtester y ejecución ampliamente optimizado. C / C ++ (posiblemente con algún ensamblador) es probable que el más fuerte candidato idioma. Estrategias de ultra-alta frecuencia es casi seguro que requieren hardware personalizado como FPGAs, cambio de ubicación conjunta y puesta a punto interfaz kernal / red. Sistemas de Investigación Los sistemas de investigación implican típicamente una mezcla de desarrollo interactivo y scripting automatizado. El ex menudo se lleva a cabo dentro de un IDE como Visual Studio, MatLab o R Studio. Este último implica cálculos numéricos más extensas 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 un rendimiento suficiente para evaluar las estrategias más de múltiples dimensiones de parámetros. IDEs típicas en este espacio incluyen Microsoft Visual C ++ / C #, que contiene utilidades de depuración extensas capacidades de finalización de código (a través de "Intellisense") y descripciones sencillas de toda la pila de proyecto (a través de la base de datos de ORM, LINQ); MatLab. que está diseñado para una amplia álgebra lineal numérica y operaciones vectorizado, pero de una manera consola interactiva; R Studio. que envuelve la consola lenguaje estadístico R en un IDE de pleno derecho; Eclipse IDE para Linux Java y C ++; y IDEs semi-propietarios como Enthought Canopy para Python, que incluyen datos de las bibliotecas de análisis como NumPy. SciPy. scikit-learn y pandas en una sola (consola) entorno interactivo. Para backtesting numérica, todos los idiomas arriba expuestos son adecuados, aunque no es necesario utilizar una interfaz gráfica de usuario / IDE como se ejecutará el código "en el fondo". 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 los parámetros backtesting son grandes. Recuerde que es necesario tener cuidado con este tipo de sistemas, si ese es el caso! Los lenguajes interpretados 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 equivalentes compilados. En última instancia el idioma elegido para la backtesting será determinado por las necesidades algorítmicas específicas, 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á. Portafolio Construcción y Gestión de Riesgos Los componentes de la construcción de la cartera y de gestión de riesgos son a menudo pasados ​​por alto por los operadores algorítmicos minoristas. 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 "de riesgo", sino también minimizar la rotación de los oficios propios, 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 para crear un establo de estrategias como el mecanismo de construcción de la cartera y el 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 las exposiciones a diversos factores (como los sectores, clases de activos, volatilidad, etc.) y optimizar la asignación de capital para varios estrategias en una cartera. Construcción de la cartera a menudo reduce 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 matriz compilado (y bien optimizado!) Para llevar a cabo este paso, a fin de no cuello de botella del sistema de comercio. La gestión de riesgos es otra parte muy importante de un sistema de comercio algorítmico. El riesgo puede venir en 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 contraparte, caídas del servidor, los acontecimientos "cisne negro" y los errores detectados en el código de comercio, para nombrar unos pocos. Componentes de la gestión del riesgo tratar de anticipar los efectos de la excesiva volatilidad y correlación entre 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 Monte Carlo "pruebas de resistencia". Esto es muy similar a las necesidades computacionales de un derivado de fijación de precios de motores y como tal será CPU enlazado. Estas simulaciones son altamente parallelisable (ver abajo) y, hasta cierto punto, es posible "tirar de hardware en el problema". Sistemas de Ejecución El trabajo del sistema de ejecución es recibir señales de comercio filtrados de los componentes de la construcción y la gestión del riesgo de la cartera y enviarlos a una casa de valores o de otros medios de acceso a los mercados. Para la mayoría de las estrategias de venta al por menor de negociación algorítmica se trata de una conexión API o FIX de una casa de valores tales como Interactive Brokers. Las principales consideraciones al decidir sobre una lengua incluyen la calidad de la API, la disponibilidad de idiomas envoltorio para una API, la 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 rendimiento que proporciona, si necesita software independiente para acceder o si una puerta 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 gráfico con el fin de tener acceso a su API. Una vez tuve que instalar una edición de escritorio de Ubuntu en un servidor de nube de Amazon para acceder a Interactive Brokers remota, meramente por esta razón! La mayoría de las API proporcionarán un C ++ y / o interfaz Java. Por lo general, a la comunidad para desarrollar envoltorios específicos del lenguaje para C #, Python, R, Excel y MatLab. Tenga en cuenta que con cada plug-in adicional utilizada (especialmente envolturas API) existe la posibilidad de errores a la fluencia en el sistema. Siempre pruebe plugins de este tipo y asegurarse de 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 la mayor 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 desempeño y esto tendrá un impacto dramático en la rentabilidad. Lenguajes con tipos estáticos, (ver abajo) como C ++ / Java son generalmente óptimos para su ejecución, pero hay un trade-off en el tiempo de desarrollo, pruebas y facilidad de mantenimiento. Lenguajes dinámicamente escritos, tales como Python y Perl ahora son generalmente "lo suficientemente rápido". Asegúrese siempre de que los componentes están diseñados de forma modular (ver más abajo) para que puedan ser "cambiados" como las escalas del sistema. Planificación Arquitectónico y Proceso de Desarrollo 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úa como comerciante minorista o trabajar en un pequeño fondo es probable que se "lleva muchos sombreros". Será necesario estar cubriendo los parámetros del modelo alfa, gestión del riesgo y de ejecución, así como la implementación final del sistema. Antes de ahondar en idiomas específicos se discutirá el diseño de una arquitectura óptima del sistema. Separación de intereses Una de las decisiones más importantes que se deben hacer desde el principio es la forma de "separar las preocupaciones" de un sistema de comercio. En el desarrollo de software, esto significa esencialmente la forma de romper los diferentes aspectos del sistema de comercio en componentes modulares separadas. Al exponer las interfaces en cada uno de los componentes es fácil intercambiar las partes del sistema para otras versiones de que la ayuda de rendimiento, fiabilidad o de mantenimiento, sin necesidad de modificar cualquier código de dependencia externa. Esta es la "mejor práctica" para este tipo de sistemas. Para que las estrategias en las frecuencias más bajas se aconseja a tales prácticas. Para el comercio de ultra alta frecuencia podría tener el libro de reglas para ser ignorado a costa de ajustar el sistema para aún más el rendimiento. Un sistema más estrechamente acoplado 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 consiste en asegurarse de que no son componentes independientes para las entradas de datos de mercado históricos y en tiempo real, almacenamiento de datos, acceso a los datos de la API, backtester, parámetros de la estrategia, de la construcción de la cartera, 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 ser intercambiado con reescrituras mínimos a la ingestión de datos o acceso a los datos de la API. Como mucho, el como el backtester y los componentes subsiguientes se refiere, no hay ninguna diferencia. Otro beneficio de componentes separados es que permite una variedad de lenguajes de programación para ser utilizado en el sistema general. No hay necesidad de estar restringida 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 backtesting siendo escrito en C ++ para el rendimiento "crujido de número", mientras que los sistemas de gestor de la cartera y la ejecución están escritos en Python usando SciPy y IBPy. Consideraciones sobre el rendimiento El rendimiento es una consideración importante para la mayoría de las estrategias de negociación. Para que las estrategias de frecuencia más alta es el factor más importante. "Performance" abarca una amplia gama de cuestiones, como la velocidad de ejecución algorítmica, la latencia de red, ancho de banda, los datos de E / S, concurrencia / paralelismo y escalamiento. Cada una de estas áreas están cubiertas de forma individual por los grandes libros de texto, por lo que este artículo sólo se raye la superficie de cada tema. Arquitectura y elección de idioma ahora 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 Ciencias de la Computación, es que "la optimización prematura es la raíz de todos los males". Esto es casi siempre el caso - excepto cuando la construcción de 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. Herramientas de perfilado se utilizan para determinar dónde surgen los 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 del lenguaje disponibles para hacerlo, así como utilidades de terceros. Elección de idioma se discutirá ahora en el contexto de rendimiento. C ++, Java, Python, R y MatLab todos contienen bibliotecas de alto rendimiento (ya sea como parte de su estándar o externamente) para la estructura básica de datos y el trabajo algorítmico. C ++ se incluye con la Biblioteca de plantillas estándar, mientras que Python contiene NumPy / SciPy. Tareas matemáticas comunes se encuentran en estas bibliotecas y es raramente beneficioso para escribir una nueva aplicación. Una excepción es si se requiere arquitectura de hardware altamente personalizado y un algoritmo está haciendo un amplio uso de extensiones propietarias (como cachés personalizados). Sin embargo, a menudo "reinvención de la rueda" una pérdida de tiempo que podría ser mejor gastado en el desarrollo y optimización de otras partes de la infraestructura de comercio. El tiempo de desarrollo es extremadamente valioso, especialmente en el contexto de los desarrolladores individuales. Latencia menudo es un problema del sistema de ejecución como las herramientas de investigación se sitúan generalmente en la misma máquina. Para los primeros, 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 se deben generar (syste operativo, la latencia de mensajería kernal), señales comerciales enviados (latencia NIC) 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 luego ser conscientes de la profundidad de los conocimientos necesarios! El almacenamiento en caché es muy útil en el kit de herramientas de desarrollador de comercio cuantitativo. El almacenamiento en caché se refiere al concepto de almacenar datos de acceso frecuente de 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, respaldado por el disco y ponerlo en la memoria. Las solicitudes posteriores de los datos no tienen que "golpear a la base de datos", y así mejoras de rendimiento pueden ser significativos. Para situaciones de negociación de caché puede ser muy beneficioso. Por ejemplo, el estado actual de una cartera estrategia puede ser almacenado en una memoria caché hasta que se reequilibra, de tal manera que la lista no necesita ser regenerado sobre cada bucle del algoritmo de negociación. Tal regeneración es probable que sea una operación de alto CPU o disco I / O. Sin embargo, el almacenamiento en caché no está exento de sus propios problemas. Regeneración de datos de la caché a la vez, debido a la naturaleza volatilie de almacenamiento de memoria caché, puede poner una demanda significativa en la infraestructura. Otra cuestión es el perro-pilotes. donde varias generaciones de una nueva copia caché se realizan bajo extremadamente alta carga, lo que conduce a la cascada fracaso. Asignación dinámica de memoria es una operación costosa en la ejecución del software. Por lo tanto es imprescindible para las aplicaciones comerciales de rendimiento más altos para ser bien conscientes de cómo se está asignando memoria y desasigna durante el flujo del programa. Normas lingüísticas más recientes, como Java, C # y Python todos realizan la recolección de basura automática. que se refiere a desasignación de memoria asignada dinámicamente cuando los objetos salen de alcance. La recolección de basura es muy útil durante el desarrollo, ya que reduce los errores y ayudas legibilidad. Sin embargo, es a menudo sub-óptimo para ciertas estrategias de negociación de alta frecuencia. Recolección de basura personalizado a menudo se desea 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 ++ no proporciona un recolector de basura nativo y lo que es necesario para manejar toda la memoria de asignación / desasignación como parte de la implementación de un objeto. Aunque potencialmente propenso a errores (que puede conducir a los punteros colgantes) es extremadamente útil tener un control detallado de cómo 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 de uso particular. Muchas de las operaciones en los sistemas de negociación algorítmica son susceptibles de paralelización. Esto se refiere al concepto de llevar a cabo múltiples operaciones programáticas, al mismo tiempo, es decir, en "paralelo". Los llamados algoritmos "embarazosamente paralelos" son medidas que se pueden calcular totalmente independiente de otros pasos. Ciertas operaciones estadísticas, como las simulaciones de Monte Carlo, son un buen ejemplo de algoritmos embarazosamente paralelos como cada sorteo y operación trayectoria posterior se puede calcular sin conocimiento de otros caminos. Otros algoritmos son sólo parcialmente parallelisable. Dinámica de fluidos simulaciones son un ejemplo tal, donde el dominio de la computación se puede subdividir, pero en última instancia estos dominios deben comunicarse entre sí y por lo tanto las operaciones son parcialmente secuencial. Algoritmos Parallelisable están sujetos a la ley de Amdahl. que proporciona un límite superior teórico para el aumento de rendimiento de un algoritmo paralelizada cuando se someten a $ N $ procesos separados (por ejemplo, en una base de la CPU o de hilos). Paralelización se ha convertido cada vez más importante como medio de optimización desde el procesador velocidades de reloj se han estancado, ya que los nuevos procesadores contienen muchos núcleos con el que realizar cálculos paralelos. El auge 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. Estas GPUs ahora son muy asequibles. Marcos de alto nivel, tales como CUDA de Nvidia han conducido a la adopción generalizada en el mundo académico y las finanzas. Tal hardware GPU es generalmente sólo es adecuado para el aspecto de la investigación de las finanzas cuantitativas, mientras que otros equipos más especializados (incluyendo Field-Programmable Gate Arrays - FPGAs) se utilizan para la (U) HFT. Hoy en día, la mayoría de langauges modernos soportan un grado de concurrencia / multithreading. Por lo tanto, es fácil de optimizar un backtester, ya que todos los cálculos son generalmente independiente de los demás. Escalar en ingeniería de software y las operaciones se refiere a la capacidad del sistema para manejar el aumento constante de las cargas en forma de mayores solicitudes, mayor uso del procesador y más la asignación de memoria. En comercio algorítmico una estrategia es capaz de escalar si puede aceptar grandes cantidades de capital y todavía 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 perfil y el monitoreo serán de gran ayuda al permitir que un sistema a escala. Propios Idiomas se describen a menudo como "unscalable". Este suele ser el resultado de la desinformación, en lugar de hecho duro. Es la pila total de la tecnología que debe ser comprobado para la escalabilidad, no el lenguaje. Es evidente que algunas lenguas tienen un mayor rendimiento que otros en casos de uso particulares, sino un idioma nunca es "mejor" que otro en todos los sentidos. Un medio de la gestión de la escala es separar preocupaciones, como se ha dicho. Para introducir aún más la capacidad de manejar "picos" en el sistema (es decir, la volatilidad repentina que desencadena una serie de oficios), es útil para crear una "arquitectura de colas de mensajes". Esto simplemente significa que la colocación de un sistema de cola de mensajes entre los componentes de manera que los pedidos se "apilan" si un determinado componente es incapaz de procesar muchas solicitudes. En lugar de peticiones se pierden simplemente se mantienen 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 latencia pesada entonces será una copia de seguridad oficios. Una cola entre el generador de señales de comercio y la API de ejecución aliviará esta cuestión a expensas del potencial deslizamiento comercio. Un corredor de la cola de mensajes de código abierto muy respetado es RabbitMQ. Hardware y Sistemas Operativos El hardware que ejecuta su estrategia puede 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 de máquina o reiniciar el sistema en el momento más inoportuno. Por ello, es necesario tener en cuenta en su aplicación residirá. La elección es por lo general entre una máquina personal de sobremesa, un servidor remoto, un proveedor de "nube" o un servidor de intercambio de co-ubicada. Máquinas de escritorio son fáciles de instalar y administrar, sobre todo con los sistemas operativos amigables nuevos usuarios como Windows 7.8, Mac OS X y Ubuntu. Los sistemas de escritorio hacen poseer 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 muchas veces en el peor de los tiempos!). También utilizan más recursos computacionales por la virtud de requerir una interfaz gráfica de usuario (GUI). Utilizando el hardware en una casa (o en la oficina local) medio ambiente puede conducir a problemas de conectividad a internet y el tiempo de actividad de alimentación. La principal ventaja de un sistema de escritorio es que la potencia computacional significativa se puede comprar por la fracción del costo de un (o sistema basado en la nube) remota del servidor dedicado de velocidad comparable. Una máquina servidor dedicado o cloud-based, aunque a menudo más caros que una opción de escritorio, permite una infraestructura de redundancia más significativos, tales como copias de seguridad de datos automatizados, la capacidad de asegurar más directa el tiempo de actividad 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 del protocolo de escritorio remoto GUI (RDP). En los sistemas basados ​​en Unix de la línea de comandos Secure Shell (SSH) se utiliza. Infraestructura de servidores basados ​​en Unix es casi siempre de línea de comandos basada en que de inmediato renders herramientas de programación basadas en GUI (como MatLab o Excel) para ser inutilizable. Un servidor que comparte el edificio, ya que la frase se utiliza en los mercados de capital, no es más que 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 para generar alfa. El aspecto final de la elección del hardware y la elección del lenguaje de programación es la plataforma independentista. ¿Hay una necesidad de que el código se ejecute a través de múltiples sistemas operativos diferentes? ¿El código diseñado para ejecutarse 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 dependientes de la frecuencia y el tipo de estrategia que se implementó. Resiliencia y Pruebas Una de las mejores maneras de perder un montón 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 sujetos a eventos raros, como quiebras de corretaje, repentino exceso de volatilidad, el tiempo de inactividad en toda la región para un proveedor de servidor de la nube o el borrado accidental de una base de datos de comercio entero. Años de ganancias pueden ser eliminados en cuestión de segundos con una arquitectura mal diseñado. Es absolutamente esencial tener en cuenta cuestiones como la debuggng, las pruebas, la tala, las copias de seguridad, alta disponibilidad y monitoreo, como componentes esenciales de su sistema. Es probable que en cualquier aplicación comercial cuantitativa costumbre bastante complicada, al menos, el 50% del tiempo de desarrollo se destinará a la depuración, pruebas y mantenimiento. Casi todos los lenguajes de programación, ya sea nave 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 arbitrarias 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, están más ampliamente utilizados en lenguajes compilados como C ++ o Java, como lenguajes interpretados como Python suelen ser más fáciles de depurar debido a menos LOC y los estados menos detallados. A pesar de esta tendencia Python no se distribuye con el AP. que es una herramienta de depuración sofisticado. El Microsoft Visual C ++ IDE posee extensas utilidades GUI de depuración, mientras que para la línea de comandos del programador de Linux C ++, existe el depurador gdb. Las pruebas en el desarrollo de software se refiere al proceso de aplicar los parámetros y resultados con 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 códigos de senderos, ayudando a asegurar que un sistema se comporta como debería. Un paradigma más reciente se conoce como Test Driven Development (TDD), donde se desarrolla el código de prueba en contra de una interfaz especificada sin aplicación. Antes de la finalización de la base de código real de todas las pruebas fallarán. Como se escribe código para "llenar los espacios en blanco", las pruebas con el tiempo todo pasa, en el que el desarrollo punto debe cesar. TDD requiere un amplio diseño de especificación por adelantado, 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, existe la biblioteca JUnit para cumplir el mismo propósito. Python también tiene el módulo de unittest como parte de la biblioteca estándar. Muchos otros idiomas poseen marcos de pruebas de unidad y, a menudo existen múltiples opciones. En un entorno de producción, registro sofisticada es absolutamente esencial. Inicio de sesión se refiere al proceso de emisión de mensajes, con diversos grados de severidad, con respecto al comportamiento de ejecución de un sistema en un archivo plano o base de datos. Los registros son una "primera línea de ataque" en la caza para el comportamiento en tiempo de ejecución del programa inesperado. Desafortunadamente las deficiencias de un sistema de registro tienden sólo para descubrir después de los hechos! Al igual que con las copias de seguridad se discuten a continuación, un sistema de registro se debe dar la debida consideración ANTES un sistema está 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 conveniente centralizar la información de registro con el fin de analizarlo en una fecha posterior, ya que a menudo puede conducir a ideas sobre la mejora de la reducción de rendimiento o de error, que es casi seguro que tendrá un impacto positivo en sus declaraciones de negociación. Mientras que el registro de un sistema proporcionará información acerca de lo que ha ocurrido en el pasado, el seguimiento de una aplicación proporcionará una idea de lo que está sucediendo en este momento. Todos los aspectos del sistema se deben considerar para el monitoreo. Indicadores de nivel de sistema, tales como el uso del disco, la memoria disponible, el ancho de banda de red y uso de la CPU proporcionan información básica de carga. Métricas de comercio, como los precios anormales / volumen, detracciones rápidos repentinos y cuenta la exposición de los diferentes sectores / mercados también serán observadas. Además, un sistema de umbral debe ser instigada que proporciona una notificación cuando ciertos parámetros no se cumplen, elevando el método de notificación (correo electrónico, SMS, llamada telefónica automatizada) dependiendo de la severidad de la métrica. Monitorización de la instalación es a menudo el dominio del gestor de administrador del sistema o las operaciones. Sin embargo, como un único desarrollador de comercio, estos indicadores deben establecerse como parte del diseño más grande. Existen muchas soluciones para monitoreo: fuente propietaria, organizado y abierto, lo que permite una amplia personalización de las métricas para un caso de uso particular. Las copias de seguridad y alta disponibilidad deben ser las preocupaciones principales de un sistema de comercio. Conclusión